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

[[e-mail]]

> On Dec 10, 2015, at 9:05 PM, Shumon Huque <[e-mail]> wrote:
> 
> > 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.

Doing incorrect validation of DNSSEC wildcards is not a good idea.
These are defaults, that are quite deliberately inapplicable in
the presence of real records.  If a user has a specific TLSA
record for port 443, and a different wildcard covering other ports,
attackers MUST NOT be able to substitute the wildcard TLSA RRset
for the more specific one for port 443.  Do not confuse these
with the X.509 wildcards.

The authority (NSEC/NSEC3) records that provide closest-encloser proofs
are not optional.

-- 
	Viktor.