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

[Viktor Dukhovni <[e-mail]>]

On Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huque wrote:

> This work is proposed to happen in TLS, but we hope to get plenty
> of feedback from DNS/DANE folks. Here's a quick summary of the major
> changes in -02:
> 
> * Updated reference newly published DANE RFCs

Thanks.

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

> * 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/

       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/

       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).
    Furthermore, this mechanism is, at least for now, *definitely*
    (not just typically) restricted to carrying DANE TLSA records
    and their signatures.

       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", 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).

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.  To do otherwise invites
	sloppy implementations that don't correctly deal with
	replies that are unavoidably not strictly ordered.

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

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

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

	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.

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

       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!

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

    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.

       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.

-- 
	Viktor.