Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Ilari Liusvaara <[e-mail]>]

On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote:
> On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara <[e-mail]>
> 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