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

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Aug 2016 17:45:37 +1000

It seems like there are many similar sorts of approaches to this
general problem floating around.  If there is indeed interest in
deploying something, then I am encouraged.  However, I think that this
document requires a lot of work.

Meta:

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.

RFC 4387 isn't a great design.  I'd be quite surprised to learn of
independent, interoperable implementations given some of the omitted
details there.

The biggest problem with RFC 4387 is the use of fixed URL paths.  It
is excused because it predates RFC 7320 excuses it, but does not
excuse any document that chooses to rely on it.

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.  SRV is not a mechanism that is
well-integrated into HTTP stacks, so you would forcing implementations
to take on special resolver logic.

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

The document needs to be a lot clearer about where trust comes from.
Much of the text talks about the use of DNSSEC and HTTPS in various
ways, each of which might be relied upon to provide certain properties
(authentication, integrity, etc...), but I don't think that the intent
of this document is to rely on any of that stuff: 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).

Section 2:

The document never actually says how an implementation might choose
the domain name to attach the _tcp to.  That needs to be written down.
Maybe this can subsume Section 4.

Is the client expected to follow CNAME/DNAME when resolving this?

What value does DNSSEC provide here?  The implication is that
integrity is used for something, but from responses to questions on
this list, it's fairly clear that this isn't at all important.

This: "The certificate of the https server SHOULD be validated by a
DNSSEC signed TLSA record, and MAY also be validated by a certificate
authority." disagrees with established practice for authenticating
HTTPS servers.  DANE is - at best - aspirational.

More to the point, this needs to identify the name that will be used
when authenticating the server.  The introduction of SRV into the mix
means that you are creating a delegation, which has huge risks if you
pick the wrong answer.  The best advice I have is to not permit the
creation of delegations, because this reduces exposure to attacks on
the integrity of the DNS.

Section 3:

Is [email-masked] an email address?  The document needs to be more
precise about how you go from inputs to produce these URIs.  WebFinger
[RFC7033] is quite precise about its inputs and how they are
interpreted to form a URI.

You also need to be much more precise about what requests are made,
and the form of the responses.  RFC 4387 is remarkably woolly about
some of these important details, to the point that it might not be
interoperable.

Section 4:

This seems a bit odd way of approaching the problem.  You could just
say that if [email-masked] and [email-masked] are considered
equivalent by example.com then the same answer should be provided to
requests for both names.  And that you can use a redirect or the
Content-Location header field to identify a single location if that is
desirable.  RFC 4387 is selective about what parts of HTTP it likes,
but it is pretty big on the use of redirects, so no problem with using
3xx there.

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.  What is the point of these being TLSA records?  Is
the intent to produce the missing pieces of a certification path [RFC
5280] that a client might be able to make a decision about the
trustworthiness of the end-entity certificate that the certificate
store has?  Why would the certificate store not include that
information directly?

TLS includes multiple certificates from the certification path in its
Certificate message, maybe you can find some way for the store to
produce additional certificates.  If you use HTTPS to retrieve them,
then you don't have to stitch together more disparate protocols and
you avoid some of the confidentiality issues that arise from sticking
stuff in the DNS.

Section 7:

That last paragraph is unnecessary: if the trust in the certificate
that is provided is based on information that is acquired
independently of this protocol, then you don't need to say things like
that.  That sort of statement implies that there is some component of
trust being conveyed, which would mean an entirely different analysis
than what I've done here (which is of a direct acquisition protocol,
not a security protocol).

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

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2016 22:29:01 -0000

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.

>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.

>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,
[email-masked], 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.

>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.

> ...: this is just a way

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 [email-masked] an email address?

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

>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.

>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.

>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