Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 04 July 2017 16:19 UTC
Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9088132268 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBrfHDTQv3_h for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 09:19:24 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF013225D for <tls@ietf.org>; Tue, 4 Jul 2017 09:19:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5B598339FE; Tue, 4 Jul 2017 19:19:21 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id DNA_STpLMpv9; Tue, 4 Jul 2017 19:19:20 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C9B3C21C; Tue, 4 Jul 2017 19:19:18 +0300 (EEST)
Date: Tue, 04 Jul 2017 19:19:18 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Shumon Huque <shuque@gmail.com>
Cc: TLS WG <tls@ietf.org>
Message-ID: <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII>
References: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com> <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <CAHPuVdWHaEjMQtjdRCS4cLVZW7iJ_urAcaE3DnWgWrwzC8d2Vw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAHPuVdWHaEjMQtjdRCS4cLVZW7iJ_urAcaE3DnWgWrwzC8d2Vw@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Jv9p1jqlKeeJ8XRM2souIqqta28>
Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jul 2017 16:19:27 -0000
On Tue, Jul 04, 2017 at 11:33:45AM -0400, Shumon Huque wrote: > On Sun, Jul 2, 2017 at 10:03 AM, Ilari Liusvaara <ilariliusvaara@welho.com> > wrote: > > > On Wed, Jun 28, 2017 at 02:15:45PM -0700, Joseph Salowey wrote: > > > This is the working group last call for > > > draft-ietf-tls-dnssec-chain-extension-04. > > > Please send you comments to the list by July 12, 2017. > > > > Some comments: > > 3) Section 3.4. DNSSEC Authentication Chain Data: > > > > > The resource records SHOULD be presented in the canonical form and > > > ordering as described in RFC 4034 [RFC4034]. > > > > What is the expected _receiver_ (i.e., client) behavior? Is the client > > supposed to run a canonicalization and sorting pass on the records? > > > > If the client does not do this, and the server sends noncanonical or > > unsorted RRset, the validation is going to fail. > > > > 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". > (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. But this might very well be wrong! > > 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). > 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. -Ilari
- [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension… Joseph Salowey
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Ilari Liusvaara
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Melinda Shore
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Shumon Huque
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Viktor Dukhovni
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Ilari Liusvaara
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Ilari Liusvaara
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Shumon Huque
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Shumon Huque
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Ilari Liusvaara
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Shumon Huque
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Benjamin Kaduk
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Shumon Huque
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Benjamin Kaduk
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Tom Ritter
- Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-exten… Shumon Huque