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

[Shumon Huque <[e-mail]>]

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:
>
> >
> > Since the ordering is a SHOULD on the server side, the client has to
> check
> > and perform canonical re-ordering if necessary anyway, before computing
> and
> > validating the signature. If this were a MUST, a stronger case could be
> > made that this recommendation saves the client some work.
> >
> > Personally, I would be fine with taking out the recommendation for the
> > server to canonically order the records. DNSSEC validators (the client
> end)
> > are required to reconstruct the canonical form and ordering of the RRset
> > (see RFC 4035, Section 5.3) before validation, so unless there is a
> > compelling rationale for deviating from this, we shouldn't.
> >
> > Section 6 ("Verification") essentially says to do validation according to
> > RFC 4035, which covers all of this, and we were planning on leaving it at
> > that -- rather than replicating text that just restates DNSSEC validation
> > logic that is normatively defined elsewhere.
>
> I think either this should be strengthened or taken out entierely.
> Right now it is "the worst of both worlds".
>

My proposal is to remove the recommendation that the server SHOULD order
records in an RRset. And refer to the normative DNSSEC validation algorithm
for the client. That should take care of this.


>
> > (Perhaps RFC 5155 should also be mentioned now that this spec
> accommodates
> > negative proofs associated with wildcards and thus has to deal with
> NSEC3).
>
> Oh yes. AFAICT (since there is always data):
>
> - If the record is not a wildcard, then no NSEC nor NSEC3 records are
>   needed.
>

Correct.


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


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


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

The statement in the draft that the "_udp" label is for DTLS servers might
be too restrictive, and perhaps it should be expanded to include other
secure transports that run over UDP. The TLSA spec (RFC 6698) today only
defines 3 transport labels _tcp, _udp, and _sctp. I'm wondering whether
that needs to be expanded to include things like tls/dtls/quic, and whether
it needs an IANA maintained registry for extensibility.

-- 
Shumon Huque