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

Shumon Huque <> Tue, 04 July 2017 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B75441324DE for <>; Tue, 4 Jul 2017 10:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B-nIw1wX0OT0 for <>; Tue, 4 Jul 2017 10:18:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60E4212ECB6 for <>; Tue, 4 Jul 2017 10:18:07 -0700 (PDT)
Received: by with SMTP id r126so114067068vkg.0 for <>; Tue, 04 Jul 2017 10:18:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mn2sm5zhJx3YiljdIYMcfr6E3gSLEuAOKFvPom18Svk=; b=F0Gy9f/upbSYrL1oM3hmLngdqr+dpWodhxOETAyFx2joWaJN2s/GVbhN8JErkXaXPy kq57jJ4QwZzSk9Wt2K12/9ngBYrNvVajf+ikGr0BKp2BmrJvEDrfSaxnmKaJ6fxUKtqG I2F5Uzw49qe0IGmuwFioWrhckVcW8dyvCMPv/IGdYt8dlU2t3hL/V6j0dpm1TwYMgEGI dNyCx7qjqbOaXHhAmLeziyAWcqWv/WQDSXHJUIJKWGEH0X3QFNWmyMf7RZCbCIQfabdg LgbLqc4/J+Oq2xYOd9Kt4veUFumiDQxYCyUiIqHCbUQvejUohmLOrbAsAh+2gvJjop4P O5yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mn2sm5zhJx3YiljdIYMcfr6E3gSLEuAOKFvPom18Svk=; b=fxkzDAmAyYr7zzBtFR3D2zA7DNPlMKXMjDIuVWiydQF8SefE762FiWtycsQrLDyMNF L9G09BLhyY7Oz9ZgSakkpQPbX+WkHVauVM4BxjC4SlYbCbshLwZZqhvs8LAImOcdjLlF bHsiW8L6RtemJWow0DNvu28TJec/2WmdxnyhXCInKqK2jd2sQ99lI2jAuGoJibkgt4GA J2SgmIPSl01wUIvJf8chEnlB+2sKE+zPykpCN+VzRU+ujwkp3VDvkO1GAkgO6oUFYrF6 codrcwdLDGX14AXT0lXRvtHzDNvq4lGLRBjJUSRVDnZUYhaxe0m7Jb7SfNfevFVYHzij OgPA==
X-Gm-Message-State: AKS2vOyeiwyRgAQMWocraJqwu1jYcPYWmXJoBHHa2Viv1kkJTFiBuJ43 BwimvKPVuvctEpM6SqrINpR6TdVPMA==
X-Received: by with SMTP id t22mr23157176vke.100.1499188686401; Tue, 04 Jul 2017 10:18:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 4 Jul 2017 10:18:05 -0700 (PDT)
In-Reply-To: <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII>
References: <> <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <> <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII>
From: Shumon Huque <>
Date: Tue, 4 Jul 2017 13:18:05 -0400
Message-ID: <>
To: Ilari Liusvaara <>
Cc: TLS WG <>
Content-Type: multipart/alternative; boundary="001a11415c3e1ab51a0553811116"
Archived-At: <>
Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jul 2017 17:18:41 -0000

On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara <>;

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


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

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