On Thu, Dec 10, 2015 at 11:25 PM, <[email protected]> wrote: > > > On Dec 10, 2015, at 9:05 PM, Shumon Huque <[email protected]> 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. >
I wasn't confusing anything, rather considering ways to avoid the presence of NSEC records in the chain, as a possible simplification. Presumably the server operator knows what records are in their zone and can judge the risks for themselves, but I know it isn't ideal. Another option, also not ideal, would be to exclude wildcard TLSA records from using this mechanism. Anyway, let's see how the discussion about RRsets vs messages and the use of DNSSEC libraries goes. If we end up shunting everything to a full validation library this is all moot. Shumon.
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
