Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 16 May 2018 16:34 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 1F95712D940 for <tls@ietfa.amsl.com>; Wed, 16 May 2018 09:34:32 -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 wIDk2AVp5oll for <tls@ietfa.amsl.com>; Wed, 16 May 2018 09:34:30 -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 0558212D88A for <tls@ietf.org>; Wed, 16 May 2018 09:34:29 -0700 (PDT)
Received: from [10.200.0.109] (unknown [8.2.105.17]) (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 AE1927A3309 for <tls@ietf.org>; Wed, 16 May 2018 16:34:28 +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: <CA+cU71=bOG=3TSDs7dfPLYWY96vSpxCm83=jTJB_1s29fVmnNQ@mail.gmail.com>
Date: Wed, 16 May 2018 12:34:27 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <18BF1F5A-DDB7-4F8A-A460-7AC7026E246D@dukhovni.org>
References: <5E208416-CC05-4CA0-91A4-680045823E82@dukhovni.org> <CA+cU71=bOG=3TSDs7dfPLYWY96vSpxCm83=jTJB_1s29fVmnNQ@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/g7mkIw8PQy0E3plc5PQSytKBHeQ>
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
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: Wed, 16 May 2018 16:34:32 -0000
> On May 16, 2018, at 12:20 PM, Tom Ritter <tom@ritter.vg> wrote: > > On the balance, I support adding the two bytes. Thanks for responding, and sorry to frame the request as "please support", I've previously tried to careful and ask people to respond with their comments whatever they might be, and should have done so this time too. > I would argue that the top-most or bottom-most bit should be used as a > testing bit (0 = Testing, 1 = Enforcement), and that the draft (or a > second draft) specifying the policy should add a generic > problem-reporting extension that allows one to post a description of > errors encountered. But these arguments do not hinge my support of two > bytes. For the record, the reason that we're confident that two bytes are enough is that DNS TTLs already take care of sub-hour continuity for any provided TLSA records. So units of hours are natural, and make 16 bits quite sufficient. We've given the need for other pinning properties from other STS-like protocols some thought, and it turns out that none apply. IN particular a testing mode is not possible with this extension. Such a testing mode would itself be a downgrade attack. Any testing mode for DANE would have to be specified as a new element type for the TLSA RRset to be authenticated via DNSSEC, not as a WebPKI-authenticated element of this extension. The extension is a channel to deliver security-relevant data from DNS, and the pin when specified, would just pin support to continue to provide the channel. The STS-analogy is the closest available but it is not a faithful one, the requirements here are much simpler. -- Viktor.
- [TLS] TLS DNSSEC chain consensus text, please spe… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Melinda Shore
- Re: [TLS] TLS DNSSEC chain consensus text, please… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Melinda Shore
- Re: [TLS] TLS DNSSEC chain consensus text, please… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Thomas Lund
- Re: [TLS] TLS DNSSEC chain consensus text, please… Ted Lemon
- Re: [TLS] TLS DNSSEC chain consensus text, please… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Tom Ritter
- Re: [TLS] TLS DNSSEC chain consensus text, please… Christian Huitema
- Re: [TLS] TLS DNSSEC chain consensus text, please… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Christian Huitema
- Re: [TLS] TLS DNSSEC chain consensus text, please… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Melinda Shore
- Re: [TLS] TLS DNSSEC chain consensus text, please… James Cloos
- Re: [TLS] TLS DNSSEC chain consensus text, please… Melinda Shore
- Re: [TLS] TLS DNSSEC chain consensus text, please… Viktor Dukhovni
- Re: [TLS] TLS DNSSEC chain consensus text, please… Peter Gutmann
- Re: [TLS] TLS DNSSEC chain consensus text, please… Tim Hollebeek
- Re: [TLS] TLS DNSSEC chain consensus text, please… Paul Wouters
- Re: [TLS] TLS DNSSEC chain consensus text, please… Tim Hollebeek
- Re: [TLS] TLS DNSSEC chain consensus text, please… Melinda Shore
- Re: [TLS] TLS DNSSEC chain consensus text, please… Tim Hollebeek