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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 05 April 2018 02:15 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 E1C5012D7F0 for <tls@ietfa.amsl.com>; Wed, 4 Apr 2018 19:15:29 -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 Ce8-1vfNgiye for <tls@ietfa.amsl.com>; Wed, 4 Apr 2018 19:15:28 -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 C9B81127775 for <tls@ietf.org>; Wed, 4 Apr 2018 19:15:27 -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 4E1FC7A330D for <tls@ietf.org>; Thu, 5 Apr 2018 02:15:26 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABkgnnWBdp=KtmBVDcrR9-5tdVPfhWG7pWR0FE57H=iWS37dWw@mail.gmail.com>
Date: Wed, 04 Apr 2018 22:15:25 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <C52564E1-ABCD-4E1A-8517-19743BD2180B@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <EDB0F480-1272-4364-9A3D-23F9E1A02141@dukhovni.org> <CABkgnnWBdp=KtmBVDcrR9-5tdVPfhWG7pWR0FE57H=iWS37dWw@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZsAx5tV5gtrM7eoWV3OO83KDYOQ>
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: Thu, 05 Apr 2018 02:15:30 -0000


> On Apr 4, 2018, at 10:07 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> Given what we've learned about pinning (it is being removed from
> browsers), this seems like a bad plan to me.

Question, are you thinking of HPKP or STS?  HPKP pins rather volatile
data, and is too fragile to be used (something I would have predicted
without even running the experiment).  STS and this proposal pin a
capability:

	* STS:  I can be relied on to support TLS
	* option (B): I can be relied on to support the TLS extension
          for the specified itme (or not when the TTL is 0).

So I rather that the unsurprising failure of HPKP is the wrong lesson
to apply.  STS seems successful enough, indeed in the UTA working
group Google, Microsoft, Yahoo et. al. are standardizing an STS for
SMTP (as a work-around for lack of DNSSEC in their domains) and this
pins an STS policy for timescales comparable to the proposal here.

The UTA STS draft has just cleared WG last call, Should I expect that the
folks in this WG opposing the pin for the DANE chain extension are strongly
opposed to SMTP STS and will argue against it in IETF last call and if
IESG members in IESG review?

-- 
	Viktor.