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

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Nov 2015 04:53:34 +0000

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Nov 2015 19:35:24 +0000

>     server, likely not canonically ordered, and quite possibly with

An alternative, (given that the server is expected to cache the
extension and the server-side processing cost is presumably ammortized
over multiple requests) is to collapse all the relevant RRsets into
a single ("recompressed" by the server) DNS packet in which the
initial TLSA RRset (preceded by any CNAME/DNAME and related RRSIG
records that lead to this RRset) and its RRSIG appear in the "answer"
section, while all the other records, (relevant RRSIG, DNSKEY and
DS records of parent zones) are in the "additional" section.

This single DNS "jumbo" packet can be picked apart and processed
by a suitable DNS library that has existing code to process DNS
packets with multiple RRsets (in multiple sections), in this case,
as though the reply came from a root server, so that all the
additional records are "in bailiwick".

Of course the library might still need new code to support DANE
processing in this new way, but there's a chance it might "just
work", if all the RRsets are imported before any are verified.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 19 Nov 2015 06:39:07 -0500

> > of feedback from DNS/DANE folks. Here's a quick summary of the major

[ ... detailed comments omitted ... ]

Thanks for the detailed review and feedback Viktor, and sorry for my
belated reply. I just got back from vacation, and will read this in detail
and respond in the next few days.

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Mon, 23 Nov 2015 08:19:20 -0500

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

>     s/performing perform/having to perform/

Yup, will fix.

>        broken middlebox on the path between the endpoint and a DNS server.

Ok.

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

>     (not just typically) restricted to carrying DANE TLSA records

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

>     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

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.

>         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

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.

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

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

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

>         willing to attempt to produce a validated TLSA RRset.

Yes.

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

>     server, likely not canonically ordered, and quite possibly with

See previous remarks about ordering - a continuing discussion topic.

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

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

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Nov 2015 07:09:13 +0000

On Mon, Nov 23, 2015 at 08:19:20AM -0500, Shumon Huque wrote:

> Compression in the DNS protocol is currently defined in terms

The potential advantage of switching to DNS messages is that this
is presumably a format already understood by various libraries.

> (although technically it might be able to do that retrospectively).

Yes, I think we should be specific about what the TLS extension
carries, namely the TLSA records for (port, protocol, fqdn) triple
with any requisite CNAME expansion.

> using multiple sequences of ordered RRsets.

And therefore I think the ordering requirement is for the most part
needlessly restrictive.  The processing logic as I see it is:

    + Bring all the records into a transient empty cache (no external
      lookups for cache missses, the cache is the entire universe),
      not losing track of which was the first.

    + Starting at the first RRset, if it is a CNAME, validate the
      chain of CNAMES leading to the actual target TLSA RRset.

    + Validate the target RRset (often the first RRset absent CNAMEs).

All the RRsets other than the first are just cached, and so their
order is not significant, with one important exception: NSEC3
records that validate wildcard responses need arrive directly after
the wildcard response and be stored with that wildcard response.
Finding them is cumbersome after the fact.

Which brings us back to the message format, if it is just a stream
of RRsets (rather than a stream of DNS messages), what binds the
NSEC/NSEC3 records to the associated wildcard response?

	; ANSWER:
	; *._tcp.example.com IN CNAME _dane.example.com.
	_25._tcp.example.com. IN CNAME _dane.example.com.
	_dane.example.com. IN TLSA 3 1 1 ...
	; AUTHORITY
	; This, or equivalent NSEC3 record
	*._tcp.example.com. IN NSEC example.com. CNAME

In what order should these RRsets appear?  How are the NSEC (or
worse NSEC3) records to be associated with the wildcard (first)
answer in a stream of records that is not broken down into the
usual query/answer/authority/additional format if they are not
explicitly grouped with the packet in question?  (Broader search
for suitable NSEC3 records across all the returned RRsets?)

> wire messages they received.

See above, I think this deserves more thought...

> of the potential consumers of this.

What are these unstated requirements?  The discussion will probably
be more productive if they are made explicit.

> Certificate chains in TLS are ordered

Except that in practice (and formally in the TLS 1.3) draft the
certificates are not so ordered, and DNS resolution with CNAMEs
and wildcard records is not nearly so "linear".

> protocol that application developers won't implement, so I'm trying to

This protocol is not something "application developers" should even
for a moment consider implementing.  It goes into DNS libraries
that are enhanced to support this use case.  The application will
just shunt the records from the TLS server to the library, and get
back the validated TLSA RRset or a suitable error.

> this. Will re-open the discussion.

SNI is already required for DANE clients:

    https://tools.ietf.org/html/rfc7671#section-3

> carry both the server's name and port.

Except that SNI already carries the name, so I would not duplicate
that.

> might be worth considering though.

But complicated, because the client might not know which algorithms
are supported by its DNS library.  The library would have to provide
an interface to get that list.  If the list is optional, than an
empty list should mean that no algorithms can be dropped.  As you
note, with a bit of work some other redundancies can be eliminated.

> support this too. I'll start some discussion on this topic.

It would certainly be good to leverage this if the same format can
be used for both.  Much more likely to be implemented in DNS
libraries if it kills two birds with one stone.

Don't know how this works with non-linear results involving non-sibling
CNAMEs.

> there is of course room for discussion and refinement.

As I mentioned above, if you could be more explicit about these,
that might be helpful.

-- 
	Viktor.