On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote: > On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote: > > > > > > - If the record is a wildcard, then one NSEC or NSEC3 record that > > denies the sibling of source that is the ancestor of the QNAME. > > > > The client first needs to determine that a wildcard DNS record was matched > - this can be deduced from the the label count field in the RRSIG record > being less than the label count in the QNAME. It then needs to authenticate > NSEC/NSEC3 records that prove the following facts: (1) that there is no > exact match of the QNAME and (2) that no closer wildcard could have > matched. Often the same NSEC/NSEC3 record can prove both facts.
When is one NSEC/NSEC3 record (covering the sibling of source that is the parent) together with the wildcard RRsig records not enough to prove correctness of wildcard expansion? (I know it takes 3 NSEC3 records to prove that something does not exist, but here only cases where something exists are interesting). > > > > Also, 'RRsig record' or 'RRsig records'? IIRC, if ZSK is being rolled > > > > (and for DNSKEY, if KSK is being rolled), there will be two RRsig > > > > records for one RRtype. > > > > > > > > > > Good catch. RRsig records (or maybe RRsig RRset). > > > > Maybe I'm just unfamilier with DNS, but I think RRsig RRset might be > > interpretted as set of RRsig records in some name (which is very much > > wrong interpretation here). > > > > An RRset is defined as the set of records that share the same name, type, > and class. So an RRsig RRset should cover signatures produced by different > keys for the same RRset. But if this sounds confusing, I'm okay with "RRsig > records". RRsig is special in that it is subtyped in RRdata. I don't know if concept of "RRset" is redefined for RRsig to take that into account. I.e., does RRsig RRset include RRsig's for any possible A records (which are very much not interesting here)? > > > 7) Section 4. Construction of Serialized Authentication Chains > > > > > > > > > The transport is "tcp" for TLS servers, and "udp" for DTLS servers. > > > > > The port number label is the left-most label, followed by the > > > > > transport, followed by the base domain name. > > > > > > > > So if this would be used with IETF-QUIC, the labels would be > > > > _443._tcp, which is the same as one used by HTTPS, right? > > > > > > > > > > I hadn't yet thought of this use case, but wouldn't it be _443._udp since > > > QUIC runs over UDP? Perhaps a server operator that supports both TLS and > > > QUIC, wants to have separate server credentials for each. And if not, > > they > > > could alias one of the TLSA records to the other. > > > > Yes, QUIC runs over UDP. However, IETF-QUIC will be TLS 1.3, not DTLS. > > > > You mean IETF QUIC will reuse the TLS 1.3 handshake mechanism right? But > it's still a distinct transport from TLS 1.3 I assume. (I'm a QUIC newbie - > feel free to correct me). Pretty much. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
