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