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

Jim Reid <jim@rfc1035.com> Fri, 07 July 2017 14:14 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 05E5C128CFF for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 07:14:57 -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, 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 uZkHt1NCZ5rx for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 07:14:55 -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 D061C131551 for <tls@ietf.org>; Fri, 7 Jul 2017 07:14:52 -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 B927F2421529; Fri, 7 Jul 2017 14:14:51 +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: <CAHPuVdXwvbnfqm3O6GSTSD0BVG3JjdqQBjj9n4mvMOhzgHs-PA@mail.gmail.com>
Date: Fri, 07 Jul 2017 15:14:51 +0100
Cc: TLS WG <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <31C79391-24AA-422D-8F5B-EBB4DE7DB82E@rfc1035.com>
References: <765945B5-B686-45EB-84AE-38731C3006D6@rfc1035.com> <CAHPuVdXwvbnfqm3O6GSTSD0BVG3JjdqQBjj9n4mvMOhzgHs-PA@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_LDs0-qBdxSrYcsTuU3xYREFGkY>
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 14:14:57 -0000

> On 7 Jul 2017, at 02:47, Shumon Huque <shuque@gmail.com> wrote:
> 
> I assume you're referring to the examples in Appendix D (Test Vectors)?

Yes.

> These are working examples that implementers can test code against. But it looks like the testbed involved in these examples uses combined signing keys (i.e. ones that are both the zone's secure entry point and the ZSK). Perhaps we should use an example with the KSK/ZSK split to make them look more like the real world. Let me discuss with Willem Toorop (co-author) who generated these ...

Willem told me he’d used the KSK as the ZSK for cosmetic reasons. Examples showing the KSK/ZSK split would show how things generally work the real world.