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

[Viktor Dukhovni <[e-mail]>]

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

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

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

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

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.

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

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


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

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

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

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

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

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

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

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.

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

SNI is already required for DANE clients:

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

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

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

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

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.

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

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.

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

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

-- 
	Viktor.