IETF Logo Mail Archive

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 13 April 2018 05:41 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 11B5812D7F5 for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 22:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 zL2qyHK89M9q for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 22:41:25 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D185126D45 for <tls@ietf.org>; Thu, 12 Apr 2018 22:41:25 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 53B177A3309 for <tls@ietf.org>; Fri, 13 Apr 2018 05:41:24 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBO3koFfCE1Z=fK0oh8iKOeE8qinVbSvu0CfUaF-grogZw@mail.gmail.com>
Date: Fri, 13 Apr 2018 01:41:23 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <283A3EA9-614A-4CD2-8D81-E3EA3E1D71BF@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <CAHPuVdXfVQ5ZYL+dTvFeTfOaz2NNPrqxvnWuqJkxu0aaKDF_Sg@mail.gmail.com> <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <alpine.LRH.2.21.1804120438460.24369@bofh.nohats.ca> <CAL02cgSuTOaT_NwnpXaa8DPhNJhzqZwepRL+J29BzcBfCTDtHw@mail.gmail.com> <CAHbuEH78KNyk8fnHThRkCERKPjZzYppi1uhkDx6kL_t448q0_g@mail.gmail.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <CABkgnnUwOjkY1_KejV-YOw3YRqjFfzaYurEY1OpZ8phQVhcWLg@mail.gmail.com> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <aa7ca33a-4acd-c770-a43c-df7a1f66c782@nlnetlabs.nl> <E3918F11-9AD7-4C06-9173-5175ECACD16B@dukhovni.org> <CABcZeBP6-7_NNmC+7iVnNXbQw7p3jJH4eC1-EjY4C4CwdWWNcg@mail.gmail.com> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org> <CABcZeBPJY1tsnCTYFbLoFSUX8pdVE7ZCi-+7kWsZkx8vwR_0YA@mail.gmail.com> <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> <a1e1258b-f002-f162-ba05-fd8b728ac2cd@nomountain.net> <095DDF77-F2E6-4522-AFA1-B77710B1BC98@dukhovni.org> <CABcZeBO3koFfCE1Z=fK0oh8iKOeE8qinVbSvu0CfUaF-grogZw@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ylc5e32lFqvGSz0O0Q96MSG3XIE>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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, 13 Apr 2018 05:41:27 -0000


> On Apr 13, 2018, at 12:51 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Thanks for pointing this out. I agree that this text is likely to cause
> interop problems and should be removed or at least scoped out in
> the case where client and server are unrelated. I regret that I didn't
> catch it during my IESG review.

Well (B) is a proposal for doing just that, making it
possible for servers to suppress any such pinning, but it
also allows for future use-cases in which pinning might be
desirable.

If we're revising the text anyway, and given that implementors
suffer no burden to insert (on the server) or ignore (on the
client) an extra two bytes in the extension, (so Melinda's
issue of added complexity is not a barrier here), the sensible
responsive change is to add support for (B) with a requirements
that clients not pin longer than requested, and servers should
generally set the TTL to zero, unless pinning is understood to
be fit for purpose in the given application, and the operator
is willing to commit for the indicated time.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email