Re: [dispatch] Review of draft-bhjl-x509-srv-02

["John Levine" <[e-mail]>]

Thanks for the review.  

I can see this draft needs a lot more explanatory material for the
benefit of people who aren't familiar with all the ways that mail is
not like the web, or who don't understand the idea of a server that
returns certificates for e-mail addresses.

Specific points:

>The document never actually says how an implementation might choose
>the domain name to attach the _tcp to.  That needs to be written down.

It's the domain name in the e-mail address.  I thought that was obvious,
but I can try to make it clearer.

>This looks very similar to draft-miller-saag-key-discovery-00.  That
>uses webfinger.  I would encourage the authors to talk to Matt and
>Suhas to see if they have any input on these designs.

>That this is a service discovered via SRV alleviates some of the
>pressure on servers, but I think that a better approach would be to
>use .well-known URIs and avoid SRV. ...

Unfortunately, unless I seriously misunderstand webfinger, it is a
non-starter here.  If you want to do a webfinger lookup for, say,
[e-mail], you look up the A or AAAA record for example.com
and send an https request to a web server at that address.

Domains in e-mail addresses have MX records, not A records.  There are
many e-mail domains with MX records but no A or AAAA.  Even if there
is an A or AAAA, there's no reason to expect to find a server
listening on port 443, and if there is something listening, no reason
to expect that whoever runs that server has anything to do with the
mail system.  (I provide mail for a whole bunch of domains whose web
service is somewhere else and whose web managers I do not know and do
not want to know.)  RFC 7033 section 7 says that you can sort of get
the same effect of MX records by using web redirects, but of course
that only works if you have a web server in the first place, which we
don't.  

SRV records were invented exactly to provide MX-style redirection
for other services.  If you think that SRV is too hard (which I don't,
see below) the options are not great.  The STS effort to provide cert
pinning for mail servers has run into the same problem, and the least
awful alternative is fixed host name prefixes which gives stomache
aches to DNS types.

So the Miller draft couldn't be used without some serious surgery
to the discovery part, and if we need to do that, I'd rather use
an existing standards track spec.

>I don't see much information in the document about how this might be
>deployed.  Both SRV and DNSSEC have some deployment challenges.

I had a long talk with some people from Gmail at the Berlin IETF.
They didn't see any great problems.  This is not a design that's
likely to be implemented in web browsers; it's for mail clients
(Outlook, Apple Mail, etc.) and within the servers of webmail
providers.  MUAs already do all sorts of things that web browsers
don't, and I don't see a SRV lookup as a problem.

>The document needs to be a lot clearer about where trust comes from. 

> ...: this is just a way
>to find certificates and whether those certificates are trusted or not
>will be determined based solely on their contents and any configured
>trust anchors (or the equivalent of that for PGP).

Quite right.  For 20 years the trust models for PGP and S/MIME have
been vague and I don't see that changing.

>What value does DNSSEC provide here?

If you believe that DNSSEC provides a chain of trust from the domain
name to the SRV record to the TLSA for cert in the web server the SRV
points to, that's what if provides.  I am not wedded to it, which is
why there's no MUST for the DNSSEC stuff.

>Is [e-mail] an email address?

Um, yes.  This whole draft is about finding certs for e-mail addresses.

>Section 4:
>
>This seems a bit odd way of approaching the problem.  You could just
>say that if [e-mail] and [e-mail] are considered
>equivalent by example.com then the same answer should be provided to
>requests for both names.

There is no such thing as "equivalent" e-mail addresses.  RFC 5321 and
its predecessors are carefully written that way.  Only the mail server
that receives the mail gets to interpret the local part of an address,
and I'm trying hard not to change that.

>Section 5:
>
>   The domain MAY publish validation certificates using TLSA
>   records at the name _smimeca._tcp.
>
>This little throwaway line really needs its own section.  The two
>sentences in the doc aren't nearly enough detail to produce an
>implementation.  What do these certificates contain?  Not trust
>anchors, I hope.

Yes, they're trust anchors.  They sign the S/MIME certificates the
server returns, if your model is that the domain is authoritative for
its mail users' certs.  If that's not your model, you don't.

>What if a user wanted to only make their certificate available to a
>certain subset of requesters?  Is that possible?

I suppose if you wanted a private server, you could stick one of the
usual web login protocols in front of the requests.  But it's not
a problem this draft tries to solve.

R's,
John