Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 17 October 2018 01:24 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 340A8130E63 for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 18:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 oQR9tYQLCNw7 for <tls@ietfa.amsl.com>; Tue, 16 Oct 2018 18:24:06 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8951271FF for <tls@ietf.org>; Tue, 16 Oct 2018 18:24:06 -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 straasha.imrryr.org (Postfix) with ESMTPSA id 684992C21B for <tls@ietf.org>; Tue, 16 Oct 2018 21:24:05 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20181017010720.3C81D2006F8412@ary.qy>
Date: Tue, 16 Oct 2018 21:24:04 -0400
Content-Transfer-Encoding: 7bit
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <7EB925F0-0010-42B5-8B6D-5D03864231C4@dukhovni.org>
References: <20181017010720.3C81D2006F8412@ary.qy>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tIGTqxbFe-eqXLBp8hGkPKVV6Lc>
Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Oct 2018 01:24:08 -0000
> On Oct 16, 2018, at 9:07 PM, John Levine <johnl@taugh.com> wrote: > > Something like "require DANE certs until time N" should be plenty. > > Remember that you can also unpin by publishing a signed NXDOMAIN or > NODATA. Since you need to have DNSSEC working to get the pin in the > first place, that doesn't seem unduly onerous. To be clear the "require DANE certs" above only holds so long as the TLSA records remain published. Since providing proof of non-existence clears the pin, what's really pinned is the extension (and even then, many clients will be able to recover by making independent DNS lookups). So there's no discord here between "require DANE certs" and "just pin the extension", the two are equivalent, because the former really means "require the extension and if signed TLSA records are present require DANE, else, with valid denial of existence, clear the pin". So regardless of how we frame it, the behaviour after first contact is the same, that is: * Apply DANE in a downgrade-resistant manner when published * Drop pins and revert to default behaviour given valid denial of existence. So far, no substantive issues have been noted with the proposed pinning approach to downgrade resistance (which bears no resemblance to HPKP). All that remains is agreement on a maximum time limit (by setting the time unit to max_time/2^16), and perhaps some sort of gradual scaling up of that limit (if concerns about hijacking before the extension is widely available in server software are deemed sufficiently compelling). -- Viktor.
- [TLS] Interim notes and draft-ietf-tls-dnssec-cha… Christopher Wood
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Tom Ritter
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Nico Williams
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Daniel Kahn Gillmor
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… John Levine
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Paul Wouters
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Sean Turner
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk