IETF Logo Mail Archive

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

Jim Reid <jim@rfc1035.com> Fri, 07 July 2017 15:35 UTC

Return-Path: <jim@rfc1035.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 5641712EA53 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 08:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 gFiU2bXqclF2 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 08:35:00 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EF012762F for <tls@ietf.org>; Fri, 7 Jul 2017 08:35:00 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 3D2CF2421519; Fri, 7 Jul 2017 15:34:58 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <CAHPuVdVbLw+vw4pzHNeBJK_gnqWntEfCgqo-DPQcdcmwXRV00A@mail.gmail.com>
Date: Fri, 07 Jul 2017 16:34:57 +0100
Cc: TLS WG <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A17C4AB2-FCBB-443D-AD66-BCA228C0D546@rfc1035.com>
References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <20170705171211.GM5673@mournblade.imrryr.org> <1F943876-91FC-4529-9B44-9F187EDA48B5@rfc1035.com> <CAHPuVdVbLw+vw4pzHNeBJK_gnqWntEfCgqo-DPQcdcmwXRV00A@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CjlHP1gRSb84yIbAXPSLATunyFM>
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: Fri, 07 Jul 2017 15:35:01 -0000

> On 7 Jul 2017, at 16:06, Shumon Huque <shuque@gmail.com> wrote:
> 
> IMO, the real gain from having the client cache data, is that the server could then potentially send a much smaller DNSSEC chain. But this requires the client to signal what they've cached, and makes the protocol more complex. I would prefer to leave that to a future revision of the spec, after we've gained some operational experience with the current one.

Shumon, I think the biggest gain would be fewer RRSIGs for the client to validate. Having the server send a smaller DNSSEC chain (and perhaps add something to the protocol for a client to signal that) probably won’t have the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS client didn’t need to revalidate everything in the chain for tlsa.foo.com after closing and reopening a TLS session to that end-point or it could start at the previously validated delegation for .com when the TLS server returned the full chain for tlsa.bar.com.

As you hint at, it would be good to get more data and operational expertise.

v2.23.0 | Report a Bug | By Email