Re: [TLS] draft-shore-tks-dnssec-chains-extension

Melinda Shore <melinda.shore@nomountain.net> Wed, 29 July 2015 01:52 UTC

Return-Path: <melinda.shore@nomountain.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20771B30DB for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 18:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 pxVRCj7JALaX for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 18:52:18 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 70D0E1B30D9 for <tls@ietf.org>; Tue, 28 Jul 2015 18:52:18 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 30974202043 for <tls@ietf.org>; Tue, 28 Jul 2015 18:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=MTvKWGHTSzvERbObrqV6J55xRSE=; b=hbguyCzwq6r4o yIaPeCC+SOPRVhEMcjJoCpYHH9IAqlMmfs6KrmxR7pXPUzeHpJ/Ae8jF8a6J6YOs 2vwVOUiFOe/wJ4tsaeMipntqZmIixpFAq9osM9nk0i/DcS1nq8FBxTjvbydu3zUX Y5rE+MeF1wZUurTmzEU5Jq6wDmWSfI=
Received: from spandex.local (216-67-70-212-radius.dynamic.acsalaska.net [216.67.70.212]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id DB51B20202C for <tls@ietf.org>; Tue, 28 Jul 2015 18:52:17 -0700 (PDT)
Message-ID: <55B831D0.1080907@nomountain.net>
Date: Tue, 28 Jul 2015 17:52:16 -0800
From: Melinda Shore <melinda.shore@nomountain.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <alpine.LFD.2.11.1507220736290.2328@bofh.nohats.ca> <20150722171622.GH4347@mournblade.imrryr.org> <CAHPuVdXnZMnoDzJJ+Xa4YKoJpbpS3yQj=nSnSj-jR31jomZsMQ@mail.gmail.com>
In-Reply-To: <CAHPuVdXnZMnoDzJJ+Xa4YKoJpbpS3yQj=nSnSj-jR31jomZsMQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/60GHsij1yZzqPnFxlSSvTxBT0Bg>
Subject: Re: [TLS] draft-shore-tks-dnssec-chains-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 29 Jul 2015 01:52:19 -0000

On 7/28/15 5:44 PM, Shumon Huque wrote:
> I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit
> more before considering DNSSEC key transparency issues. 
> 
> It looks like that draft proposes SCT RRs (with DS+chain data in them,
> signed by log providers), so we could in the future incorporate SCT RRs
> in the chain. 

That draft really is pretty immature and at this point it's not
clear whether and how it's going to progress.  Paul Wouters can
speak for himself about where he thinks the draft needs to go
but I think it does bear pointing out that he's offered to help
out with content, given that he's got considerable DNS and DNSSEC
expertise.  If the document does continue to progress I would
expect quite substantial changes.

> I believe Eric's question was about why this couldn't be done via a new
> 'Certificate Type' (and not about embedding the chain in the X.509
> cert). I presume the idea being the new certificate type would allow
> both the server's X.509 certificate chain and the corresponding
> DANE/DNSSEC chain to be delivered in the server's Certificate Message. I
> believe the argument for doing it via a new TLS extension was that it
> would allow us to mandate the use of the DANE chain ("Must staple DANE")
> via the X.509 TLS Feature Extension.

Well, sort of.  We did talk about creating a new certificate
extension rather than a TLS extension but opted not to.  The
one advantage of an X.509 extension would have been that it wouldn't
require protocol changes, but it still would have required modifying
both the server and the endpoint.

Melinda


-- 
Melinda Shore
No Mountain Software
melinda.shore@nomountain.net

"Software longa, hardware brevis."