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

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 04 July 2017 20:50 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 DB0EA131A13 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 13:50:41 -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 XZE_oS52irA4 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 13:50:37 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 90023131755 for <tls@ietf.org>; Tue, 4 Jul 2017 13:50:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 727C9652CF; Tue, 4 Jul 2017 23:50:35 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id W10cF4tn63Rw; Tue, 4 Jul 2017 23:50:35 +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-smtp1.welho.com (Postfix) with ESMTPSA id 1BE0827F; Tue, 4 Jul 2017 23:50:33 +0300 (EEST)
Date: Tue, 4 Jul 2017 23:50:32 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Shumon Huque <shuque@gmail.com>
Cc: TLS WG <tls@ietf.org>
Message-ID: <20170704205032.zjpwduybg2hp6gcn@LK-Perkele-VII>
References: <CAOgPGoAcuFF5v8f5LWpYQtgE8WygA+n1fsg0AeVFJX1=cADUgw@mail.gmail.com> <20170702140308.6amd5ds3qqt3ju5m@LK-Perkele-VII> <CAHPuVdWHaEjMQtjdRCS4cLVZW7iJ_urAcaE3DnWgWrwzC8d2Vw@mail.gmail.com> <20170704161918.2voi3uinjv65w3j5@LK-Perkele-VII> <CAHPuVdXWH3TzRhKrydGzrESS4N-Hn3dsx67drboiB9SwW7rXsw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHPuVdXWH3TzRhKrydGzrESS4N-Hn3dsx67drboiB9SwW7rXsw@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WpkvX7l0RuKUZSpDJalncVBKFWU>
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 20:50:42 -0000

On Tue, Jul 04, 2017 at 01:18:05PM -0400, Shumon Huque wrote:
> On Tue, Jul 4, 2017 at 12:19 PM, Ilari Liusvaara <ilariliusvaara@welho.com>;
> 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