Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml

From: "John Levine" <[email-masked]>
Date: 3 Aug 2016 21:24:33 -0000

In article <[email-masked]> you write:
>The WG seemed OK with it.  After talking to people who plan to implement 
>it I updated the draft with some editing fixes and a longer security 
>section.
>
>This also seems appropriate for AD sponsored, please.

Hi again.  Martin Thompson said he'd review this, otherwise I
haven't heard anything.

Signed,
Fidgety

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Aug 2016 15:26:41 +0000

I find this interesting and would like to see something along these lines get published but I think there are a some area that probably need some dissolution....

Security model ... I'm a big confused by the use of HTTPS and DNSSEC. They both seem unneeded if the idea is a certificate is more or less self securing and public

The API. I'd like to see it clearly work for all types of URIs including email. It also seems that perhaps a parameter that directly indicated the returned type like x509, pgp, etc would be a better API design that using uri vs email to indicate if it was x509 or pgp. 

I don't get why the Name Matching parts happens. 

I think what you are really talking about here designing a HTTP REST based API for retrieval of certificates (and it happens to have an SRV entry). That seems to be an idea worth discussing. 

Cullen (in my individual contributor role)

> On Jul 22, 2016, at 4:54 AM, John R Levine <[email-masked]> wrote:
> 
> The WG seemed OK with it.  After talking to people who plan to implement it I updated the draft with some editing fixes and a longer security section.
> 
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "John R Levine" <[email-masked]>
Date: 20 Aug 2016 13:41:19 -0400

> Security model ... I'm a big confused by the use of HTTPS and DNSSEC. 
> They both seem unneeded if the idea is a certificate is more or less 
> self securing and public

1The security model is deliberately vague.  Some people believe that if a 
domain publishes S/MIME certificates for its mail users, that cert is 
authoritative.  If you do, the HTTPS and DNSSEC provide a chain of trust.

If we think that publishing a signed TLSA for the S/MIME signing cert is 
adequate, we can ditch the rest of the DNSSEC, although https is best 
practice these days for anti-snooping purposes.

> The API. I'd like to see it clearly work for all types of URIs including email.

Please, no, not death by overgeneralization.  We have at least one large
mail system that wants to publish certs for its mail users.

> It also seems that perhaps a parameter that directly indicated the 
> returned type like x509, pgp, etc would be a better API design that 
> using uri vs email to indicate if it was x509 or pgp.

This is essentially a profile of RFC 5280, which has been a standards 
track RFC for eight years.  Let's not invent any more new stuff than we 
have to.

> I don't get why the Name Matching parts happens.

Because email addresses are fuzzy.  On some systems bobsmith@example and 
bob.smith@example and/or bobsmith-ext@example are equivalent, while on 
others they aren't.  (A brief review of RFC 5321 will remind us that no, 
there is no such thing as a canonical version of a mail address.)  So this 
says the cert lookup should use the same fuzz that the mail system does.

> I think what you are really talking about here designing a HTTP REST 
> based API for retrieval of certificates (and it happens to have an SRV 
> entry). That seems to be an idea worth discussing.

No, once again, it's just a profile of RFC 5280.

R's,
John

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Aug 2016 19:58:45 +0000

> On Aug 20, 2016, at 11:41 AM, John R Levine <[email-masked]> wrote:
> 
>> 

I'm just not seeing this. Walk me thought how this is a profile of 5280. I don't even see what parts of 5280 this would profile.

---

From: "John R Levine" <[email-masked]>
Date: 20 Aug 2016 16:25:28 -0400

> I'm just not seeing this. Walk me thought how this is a profile of 5280. I don't even see what parts of 5280 this would profile.

Sorry, I can't read my own handwriting.  It's a profile of RFC 4387.

The SRVs come from section 3.2 and 3.5.1, the URL syntax comes from 
sections 2.2, 2.3, and 3.3, and the response format from section 2.5.4.

Regards,

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 20 Aug 2016 21:13:46 +0000

> On Aug 20, 2016, at 2:25 PM, John R Levine <[email-masked]> wrote:
> 
> The SRVs come from section 3.2 and 3.5.1, the URL syntax comes from sections 2.2, 2.3, and 3.3, and the r

Ah, that makes more sense. Let me have a read of 4387 time some time and see if this all makes more sense.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Aug 2016 06:25:43 -0700

Comments below:
OVERALL The trust model of this document seems confusing. Typically we
assume that certificates are self-authenticating, i.e., the
certificate can be provided to you by the attacker and you can
independently validate its acceptability. And graf 2 of section 5
implies this by talking about a signature from a CA.

However, in this protocol, you have the following additional
cryptographic protocols in play:

- A DNSSEC-signed SRV record
- A DNSSEC-signed TLSA record
- An HTTPS connection to the server
- A potentially WebPKI-valid server cert

This document should define precisely what combination of these
elements is sufficient for the client to accept the certificate. For
instance, if we have a DNSSEC-signed SRV that leads to a WebPKI valid
HTTPS server which serves a self-signed cert for the user, is that
acceptable? This reflects a completely different trust model from that
assumed by S/MIME traditionally. Another way to ask this question is:
is this an untrusted directory or is it a substitute for a PKI for
e-mail certificates.

This also goes to the question of whether this document should be in
the security or ART area.

DETAIL
S 2.
Your requirements for what cryptographic technology is used here are
all non-MUSTs, but how important they are depends entirely on the
trust model (see above). If the certs are self-authenticating and this
is just an untrusted directory, then this is largely an operational
question. However, if it is acting as a substitute CA, then actually
having a cryptographically valid chain of inference is imperative and
there need to be some MUSTs here.

It's somewhat odd to encourage TLSA records (at SHOULD level) but a
WebPKI valid certificate at MAY level. This is pretty much the
opposite of standard practice for HTTPS on the Internet today. It's
not like it's particularly onerous for someone running a Web server to
get WebPKI valid certs.

S 5.
This section also needs to be fleshed out. Questions include:

- You say "a blob of binary data". Do you mean that they are DER? That
  seems implied, but it could be compressed DER or something. This
  needs to be specified.

- What is the relationship between the multiple certificates that are
  provided? Are they alternatives? Are some of them intermediates that
  can be used to validate the EE certificate (this is commonly
  required)? If so, which one is the EE cert?

- Are there any requirements about the format of the various subject
  name fields? Say I ask for "[email-masked]" and get a cert for
  "[email-masked]". What do I do?

This section about how to publish domain-operated CA certificates kind
of seems like an add-on and needs to be fleshed out quite a bit
more. For instance, why aren't you defining the same mechanism for
PGP, as they seem analagous in this case. If you want to define TLSA
records for CA certs for e-mail that seems like it should probably be
the subject of a separate document.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 21 Aug 2016 12:39:13 -0400

> elements is sufficient for the client to accept the certificate.

If only.  Existing practice for PGP seems to be rather different from what 
the theory is ("if it doesn't look totally bogus, use it" vs "check and 
score WoT signatures against your private list") and for S/MIME it depends 
on what set of CAs are in your MUA, which in my experience is generally 
pretty stale.

Adding to the confusion, some people appear to believe that a domain is a 
reliable authority for certs for its email addresses.  (See for example 
the third paragraph in the introduction in RFC 7929 which makes no sense 
otherwise.)  Others of us don't, since the relationships between domain 
operators and mail users are incredibly variable.

If you are in the domain is authoritative camp, you can use 
DNSSEC->SRV->https as a chain of trust for the cert, or for S/MIME you can 
use DNSSEC->TLSA as a chain of trust for the signature.  If you aren't, 
you can do whatever you do now and the DNSSEC doesn't get you anything 
beyond the usual anti-spoofing.

If people agree these are the two plausible scenarios, I could easily add 
text describing them.  I don't see any chance of deciding on only one or 
the other.

> not like it's particularly onerous for someone running a Web server to

Good point, MUST for https seems obvious.

>  seems implied, but it could be compressed DER or something. This

That's supposed to be whatever RFC 4387 did.  Looking at it, it's not 
clear to me what encoding it expects, so I agree it could use some 
clarification.

>  required)? If so, which one is the EE cert?

Again, this is out of RFC 4387.  I was under the impression that the 
client could look at the certs and see what chained to what.

>  "[email-masked]". What do I do?

RFC 4387 again.

> the subject of a separate document.

I suppose I could wave my hands and say that the domain publishes an 
OPENPGPKEY record with postmaster@<domain>, but it's not clear to me 
whether anyone would care.  S/MIME signatures are (as I understand it) 
supposed to be deterministic, if you trust the signer, you trust the cert, 
while WoT is squishy.  As far as putting it in a separate document, I 
wouldn't object but it's not clear what the advantage would be.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Aug 2016 09:51:23 -0700

On Sun, Aug 21, 2016 at 9:39 AM, John R Levine <[email-masked]> wrote:

> reliable authority for certs for its email addresses.  (See for example the
> third paragraph in the introduction in RFC 7929 which makes no sense
> use DNSSEC->TLSA as a chain of trust for the signature.  If you aren't, you
> can do whatever you do now and the DNSSEC doesn't get you anything beyond
> the usual anti-spoofing.
>

Yeah, that seems like it might be OK in some sort of informational document
describing common practice, but this document is asking for Standards
Track, and in that situation it seems like actually specifying one class of
behavior is the superior direction.

> Good point, MUST for https seems obvious.

I don't just mean MUST for HTTP, but also encouraging the use of valid
certs.

> client could look at the certs and see what chained to what.

The text in 4387 is not maximally clear. It appears that perhaps the idea
is that this is just EE certs. If it's a mix of multiple EE and chain
certs, it's not reasonable to expect the RP to make sense of it. In any
case, this text should be clear.

>>  "[email-masked]". What do I do?

It seems like a citation to the relevant section would be in order here.

> wouldn't object but it's not clear what the advantage would be.

As usual, functional decomposition.

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 21 Aug 2016 17:51:45 -0000

>behavior is the superior direction.

Sure, if that were feasible.  I see no chance at all of getting a
sufficient agreement that domains are authorititative, or that they
aren't.  From what I've seen so far, few people have even thought
about it, and fewer still outside the context of whatever mail system
they personally are running.  People at gmail said they're interested
in this, so I can ask if they've thought about it in the context of
a very large public mail system.

>I don't just mean MUST for HTTP, but also encouraging the use of valid

OK.

>case, this text should be clear.

I am not a great pkix expert, so pointers and suggestions are welcone.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Aug 2016 11:13:33 -0700

> a very large public mail system.

This seems like a potential indicator that this technology is not yet ready
for standardization.

OK.

I think the high order bit here is that there are two basic kinds of certs
in play:

- EE certs (i.e., the ones that allegedly correspond to the user in
question)
- Intermediate CA certs that somehow could be used to construct a chain to
the EE.

It's pretty common, at least on the Web, to have situations where there is
1 or more
intermediate between the trust anchor and the EE cert (e.g., in the case
where CAs
are cross-signed), which is why you need the second bucket. Unfortunately,
sad
experience with the Web indicates that it's not really possible to
construct a chain
which is verifiable to all clients, so it's probably best to just have this
be a "you might
be interested in" class.

As I said previously, I kind of suspect that 4387 just meant that the certs
were all
alternative EEs, but then you probably want some other way to get the
intermediates
for the reason listed above, but in any case you shouldn't just have them
all in the
same bucket. So, what's probably best is to concretize this by saying that
this
bucket is just for EE and then define some other mechanism for getting
intermediates.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 21 Aug 2016 14:39:01 -0400

>> aren't. ...

> This seems like a potential indicator that this technology is not yet ready

Possibly, although since I talked in Berlin to people from one of the 
world's largest mail systems about implementing this, it seems we can try 
and figure out what we can standardize or we can stick our heads in the 
sand.

RFC 7929 and the forthcoming similar doc for S/MIME suggest that there is 
interest in domain authenticated certs.  But it may be that the interest 
is only in the DANE clique, in which case it would be easy enough to take 
out the domain authentication stuff and perhaps move it to a separate 
experimental draft.

> As I said previously, I kind of suspect that 4387 just meant that the 
> certs were all alternative EEs, but then you probably want some other 
> way to get the intermediates for the reason listed above, but in any 
> case you shouldn't just have them all in the same bucket. So, what's 
> probably best is to concretize this by saying that this bucket is just 
> for EE and then define some other mechanism for getting intermediates.

OK.  As I said, I'm not a great pkix expert, so whatever matches what 
S/MIME actually does would be great.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 Aug 2016 12:45:37 -0600

> On Aug 21, 2016, at 12:13 PM, Eric Rescorla <[email-masked]> wrote:
> 
>  People at gmail said they're interested

Can we get some of those people directly involved in the conversation here. Obviously I'd be very keen on doing something that ended up deployed at multiple major providers.

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2016 01:06:01 -0000

>>  People at gmail said they're interested in this, so I can ask if they've thought about it in the context of
>Can we get some of those people directly involved in the conversation here. Obviously I'd be very keen on
>doing something that ended up deployed at multiple major providers. 

Good thought.  I'll try and loop them in.

R's,
John