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

[Shumon Huque <[e-mail]>]

On Sat, Nov 28, 2015 at 2:09 AM, Viktor Dukhovni <[e-mail]>
wrote:
> 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.

Yes, that's true.

There are also existing DNS library functions that can generate and consume
authentication chains composed of RRset sequences, however they wouldn't
understand a custom compression scheme (out of the box) if we cooked one up.

One of the possible constraints I've referred to is the desire from
some app developers not to link in a large DNS library into their
applications to process this extension.

I think both you and I (and maybe others) have made the point that
DNSSEC is sufficiently complex that it would be best if this function
can be shunted to a DNSSEC library that knows how to do it properly
including dealing with all the corner cases. But I think the concern
expressed about application bloat is a legitimate one that we need to
take into account. Perhaps a possible solution is to develop a new
streamlined DNSSEC library that doesn't contain extraneous code that
this function doesn't need (such as all the DNS transport related
code).

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

As I mentioned, I am personally okay with this approach. We need to
get input from the application folks who are looking at implementing
this. I'm discussing and asking them to chime in.

Also, if we're not imposing ordering, I don't think the wildcard NSEC
needs to appear after the wildcard. The client is reordering stuff anyway,
so it should be able to deal with it.

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

For the current 'ordered RRset' version of this spec, the wildcard
case is underspecified. The simplest thing would be to specify that
the NSEC/NSEC3 record (and associated RRSIG) appears right after the
wildcard TLSA record.

Note that there is a semantic mismatch between DNS wildcards and
wildcards in X.509 certificate DNS names - the X.509 wildcard
covers all possible names, whereas the DNS wildcard covers all names
except those explicitly named in the zone. Some one possible
simplification would be to say that for wildcard TLSA records this
TLS extension only supports the X.509 wildcard semantics, and
exclude the NSEC records. This would require 'tweaking' the DNSSEC
validation algorithm to not perform the 'no closer match' proof
for wildcard records. I might actually be leaning in this direction
now to keep things simple.

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

Yes, I'm aware of this .. I'm relaying discussion with others.

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

Yes, I generally agree, but see my earlier point ..

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

Ah, glad to hear that!

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

Right.

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

Yes.

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

I'm having discussions with my co-authors and collaborators this week,
and some of them should be chiming in soon on some of their requirements
and/or desires.

The ones I'm aware of so far are those already stated earlier in this
thread: ordered RRsets and desire to avoid linking in large DNS libraries.
There may be others. I'm hoping we can reach agreement on a way forward,
although I expect it will require several more rounds of discussion.

--
Shumon Huque