Re: [dane] New version of tls-dnssec-chain draft (-02)

[Shumon Huque <[e-mail]>]

On Sun, Nov 8, 2015 at 11:53 PM, Viktor Dukhovni <[e-mail]>
wrote:
> On Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huque wrote:
>
> > * An update to the chain data format. It now uses native DNS wire
> >   format resource records with no TLS presentation language wrapping.
> >   This makes it easier for implementations to work with existing
> >   DNS libraries to produce and consume the data. But we still describe
> >   the data format in sufficient detail that implementers not using DNS
> >   libraries can work with it.
>
> I still think this should support and use DNS compression.

We're still discussing this point and I'm interested in hearing opinions
from other folks too.

My original assertion was that I didn't think it was worth it given
that the size of the chain is going to be dominated by larger elements
like public keys (DNSKEY rdata) and signatures (RRSIG rdata). However,
I take your point that as deployment moves to smaller ECDSA objects,
this calculation could change.

Then the question is what form this compression should take, which
relates directly to your comment further down about DNS messages vs
RRsets. Compression in the DNS protocol is currently defined in terms
of DNS messages, so we'd have to define a new scheme. The simplest
would be to redefine (for the purpose of this TLS extension only) the
compression pointer in the label's 1st octet to refer to an offset from
the beginning of the chain data structure. Or, switch to DNS messages.

> > * Description of how CNAME and DNAMEs are accommodated
> >
> > * Reference to use of the X.509v3 TLS Feature Extension to mandate
> >   use of the extension by a server certificate.
> >
> > * Reference to the EDNS chain query option draft as a future easy
> >   way to obtain/produce the chain data.
> >
> > * Removed discussion of possible client caching of chain data
> >   components (could be difficult to get right and/or a premature
> >   optimization).
>
> Introduction:
>
>        The intent of this proposal is to
>        allow TLS clients to perform DANE authentication [RFC6698] of a TLS
>        server certificate without performing perform additional DNS record
>        lookups and incurring the associated latency penalty.
>
>     s/performing perform/having to perform/

Yup, will fix.

>        It also
>        provides the ability to avoid potential problems with TLS clients
>        being unable to look up DANE records because of an interfering or
>        broken middlebox on the path between the endpoint and a DNS server.
>
>     s/endpoint/client/

Ok.

>        And lastly, it allows a TLS client to validate DANE records
>        itself without needing access to a validating DNS resolver
>        to which it has a secure connection.  It will typically not
>        be used for general DNSSEC validation of endpoint names,
>        but is more appropriate for validation of DANE TLSA records.
>
>     Clients can already do independent validation (perhaps at higher
>     latency cost if they don't implement a *caching* stub resolver).

Yes, that's true. The term "validating DNS resolver" could technically
cover a local stub validator too, but I think we can add some wording
specifically on this point.

>     Furthermore, this mechanism is, at least for now, *definitely*
>     (not just typically) restricted to carrying DANE TLSA records
>     and their signatures.

Yes, it can carry other records (CNAME, DNAME, perhaps NSEC, etc). I think
the point being made in that sentence was that the goal was to validate
a servers TLSA record rather than say the servers address record mapping
(although technically it might be able to do that retrospectively).

>        This mechanism is useful for TLS applications that need to address
>        the problems described above, typically web browsers or VoIP and
XMPP
>        services.
>
>     Are "XMPP services" applications?  I would say "typically in
>     web browsers, VOIP or XMPP clients",

It might be best to say "applications" (rather than "clients") such
as Web, XMPP, VoIP. Both server and client sides of these applications
will have to implement the protocol.

>     but we still don't know
>     that web browsers are likely to adopt DANE however hard we try.
>     So we can't predict which applications will take the bait,
>     perhaps we should not try.  We might however indicate what
>     "types" of applications are in scope, and that is mobile clients
>     for which DNSSEC is not always available on random WiFi hotspots,
>     and latency-sensitive clients for which making multiple DNS
>     lookups to validate a DNSSEC response is not an option (and
>     no DNSSEC validating cache is available locally).

Well, we're talking to some web folks who are interested and involved.
So while I agree that we don't yet know if web browsers will adopt DANE,
I don't have a problem mentioning them as a possible consumer. Maybe
we can soften the wording here so as not to imply any predictions. Good
point about mobile clients being in scope.

I could be persuaded to remove that paragraph entirely if we don't
want to sway the discussion in the direction of any specific applications,
but I think mentioning possible applications helps the reader understand
more concretely what this solution is being designed for.

> Section 3.2
>
>        The AuthenticationChain structure is composed of a sequence of
>        uncompressed wire format DNS resource record sets (RRset) and
>        corresponding signatures (RRsig) records.  The record sets and
>        signatures are presented in validation order, starting at the
target
>        DANE record, followed by the DNSKEY and DS record sets for each
>        intervening DNS zone up to a trust anchor chosen by the server,
>        typically the DNS root.
>
>    Two issues here:
>
>       * Because validation order is not always possible (in presence
>         of DNAME/CNAME indirection), it is I think best to not
>         suggest that the records are so ordered, even in the case
>         when such ordering is possible.

I agree that CNAME/DNAME indirection makes this trickier. A later section
does describe how ordering is done for CNAME/DNAME chains, essentially
using multiple sequences of ordered RRsets.

>         To do otherwise invites
>         sloppy implementations that don't correctly deal with
>         replies that are unavoidably not strictly ordered.

The TLS server in this case would be required to order the RRsets
appropriately, regardless of what order they appeared in the DNS
wire messages they received.

In an ideal world, I agree that it would be better if we could leave
the ordering unspecified, but we're working with requirements from some
of the potential consumers of this. Certificate chains in TLS are ordered
(from EE cert towards trust anchor), and they'd like the DNS RRsets to be
similarly ordered, so that the client can authenticate the data in one
sequential pass through. That was our starting point.

We'll continue to have discussions on this topic (and I'd be happy to
rope you in), but I am a bit reluctant to expend energy to develop a
protocol that application developers won't implement, so I'm trying to
be flexible.

>       * On the other hand, the specification needs to clearly
>         identify what the server needs to use as the *first* RRset.
>
>         This can be tricky.  The point is that a DANE TLSA client
>         connects to and authenticates a what is essentially "transport
>         endpoint", except that the network address is replaced by
>         a DNS name.  On the other hand the accepting server might
>         be behind a NAT device of some sort, and may not even know
>         what port the client connected to!
>
>         The client's name for the service can be learned from the
>         SNI extension, which therefore MUST be used when the proposed
>         extension is used, and presumably the transport protocol
>         (TCP, or UDP) is known on the server end (the server will
>         be doing TLS or DTLS after all, and will know which).

I agree. Making the SNI extension mandatory seems necessary (and
also an easy requirement since this is a green field application),
but I wasn't able to get agreement from some of my co-authors on
this. Will re-open the discussion.

>         So it would seem that the client needs to communicate the
>         target port to the server, as the payload of the proposed
>         extension in the client HELLO (extension would no longer
>         be empty on the client side).

Hmm, I hadn't considered the case of servers behind NATs. But I guess
IPv4 depletion and CGNs might make this a more prevalent (and reasonable)
use case we should try to accommodate.

If we're populating the client side extension with data, it could
carry both the server's name and port.

>         The server's job is then to produce a set of DNS RRsets
>         whose first element is either:
>
>             _<port>._<protocol>.<SNI-FQDN> IN TLSA ...
>
>             or
>
>             _<port>._<protocol>.<SNI-FQDN> IN CNAME ...
>
>         in the latter case ultimately along with the TLSA records
>         for the target of the chain of CNAMEs.  Each CNAME will of
>         course require proof of the validity of that CNAME (which
>         may be based on proof of associated DNAME records).
>
>         This then brings us to the question of whether the server
>         should be willing to attempt to construct such a set of
>         records for an arbitrary SNI name the client happens to
>         send.  It seems that the answer should generally be "no".
>         This is because otherwise the client would be able to
>         trigger arbitrary DNS lookups on the server, which may
>         impose unacceptable resource costs (and facilitate DoS
>         attacks on the targets of such lookups).

Yes, this would have been obvious to me -- that the server should
only construct chains for its own name(s). But thanks for raising
it. We should make this requirement explicit in the draft.

>         Therefore, servers MUST be configured with a list of SNI
>         domains (or at perhaps domain suffixes) for which they are
>         willing to attempt to produce a validated TLSA RRset.

Yes.

>
>     A bit lower we have:
>
>        [TODO: mention that to reduce the size of the chain, the server can
>         deliver exactly one RRsig per RRset, namely the one used to
validate
>         the chain as it is built.]
>
>     This assumes that the server knows which algorithms the client's
>     library supports.  The server can definitely do some trimming
>     if multiple signatures are present for the same algorithm as
>     a side-effect of key rotation, but it cannot in general trim
>     the list down to one signature per RRset, unless the client's
>     extension also signals the supported algorithms (too complex
>     I think, and serves to help "fingerprint" the client).

Good point. Maybe it's simplest to remove this requirement, or only
trim obviously safe signatures due to key rotation or signatures that
aren't required (such as a ZSK signature over the DNSKEY RRset -
unnecessary but often seen in the wild).

Having the client indicate its supported algorithms in the extension
might be worth considering though.

>        Each RRset in the chain is composed of a sequence of wire format
DNS
>        resource records.  The format of the resource record is described
in
>        RFC 1035 [RFC1035], Section 3.2.1.  The resource records SHOULD be
>        presented in the canonical form and ordering as described in RFC
4034
>        [RFC4034].
>
>        RRs within the RRset are ordered canonically, by treating the RDATA
>        portion of each RR as a left-justified unsigned octet sequence in
>        which the absence of an octet sorts before a zero octet.
>
>     Here, I'd like to lift both the restriction on the order and
>     canonical form.  In which case, the server can return the
>     records in exactly the form it obtained them from its own DNS
>     server, likely not canonically ordered, and quite possibly with
>     compression!

See previous remarks about ordering - a continuing discussion topic.

>
>     The server may need to make multiple queries to obtain the full
>     set of records to return to the client.  In order to make it
>     possible to retain DNS compression, the response format needs
>     to consist of one or more wire-form DNS packets, each of which
>     contains one or more answer RRsets ("additional" and "authority"
>     records should be discarded at the server end, but with care,
>     in the unlikely case that compressed answers point into records
>     in the authority or additional sections.)

The Answer section precedes Authority and Additional, and compression
pointers can only reference prior occurences of names, so your last
concern is probably not a problem.

However, authority section data may not be discardable in some
cases, such as a wildcard record which would need an NSEC & RRSIG
from the authority section.

>     Thus I think the right structure for the reply is a sequence
>     of DNS packets, not a sequence of RRsets.  Compression is then
>     scoped to each individual packet.
>
>     Of course we could make the server "work harder" by consolidating
>     all the DNS packets it receives into a single sequence of RRsets
>     as suggested in the current draft.  This would typically require
>     "decompression" and "recompression" once the full set of RRsets
>     is assembled (if I think is best) we opt to minimize the network
>     footprint of this extension.

If we migrate to DNS messages, the best format would be the proposed
EDNS chain query message, which would remove a lot of the overhead:

    http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query

But we'd need to be to process regular messages for servers that don't
support this too. I'll start some discussion on this topic.

>
>        The first RRset in the chain MUST contain the DANE records being
>        presented.  The subsequent RRsets MUST be a sequence of DNSKEY and
DS
>        RRsets, starting with a DNSKEY RRset.  Each RRset MUST authenticate
>        the preceding RRset:
>
>     Except of course when it is a CNAME (perhaps a chain of such
>     CNAMEs).  Some nameservers return RRSIGs before the record they
>     signed.  Again, apart from the first RRset being either the
>     desired TLSA RRset, or a CNAME from its qname ultimately to a
>     TLSA RRset, the order of records after the first should not be
>     constrained.
>
>     The client should load them *all* into memory, then validate
>     the first (using all pertinent records in the resulting cache)
>     and recurse if that first record is a CNAME, (being mindful of
>     potential loops), until it ultimately validates a TLSA RRset,
>     which authenticates the server's certificate or bare public
>     key (RFC7250).
>
> I'll stop here for now, because if I'm in the rough on the above,
> further comments would likely fall afould of the same issues.

No, you're not in the rough and I very much appreciate the detailed
comments Viktor. As I mentioned, we're working with some constraints
and desires imposed by the likely consumers of this mechanism, but
there is of course room for discussion and refinement.

--
Shumon Huque