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

[Martin Thomson <[e-mail]>]

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 [e-mail] 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 [e-mail] and [e-mail] 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?