Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 17 October 2018 15: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 E7E70130EA7 for <tls@ietfa.amsl.com>; Wed, 17 Oct 2018 08:24:53 -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 jQYi7QVl07Xp for <tls@ietfa.amsl.com>; Wed, 17 Oct 2018 08:24:51 -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 9A9CF130EE3 for <tls@ietf.org>; Wed, 17 Oct 2018 08:24:51 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (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 C2DAA2CB02 for <tls@ietf.org>; Wed, 17 Oct 2018 11:24:50 -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: <CABcZeBO6he-FvZH-O0Taqgp7AtDTpc4nhZZsFPKonxVZka7dhw@mail.gmail.com>
Date: Wed, 17 Oct 2018 11:24:49 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <9165DEBE-D12D-4D8B-B829-0E9B64E481EF@dukhovni.org>
References: <CAO8oSXnv5Gpdw-0c9jXtx1rQqpgwmfrZyiFgHF=Kd5qWZSMPCA@mail.gmail.com> <875zy1czbd.fsf@fifthhorseman.net> <20181017011515.GL7773@akamai.com> <CABcZeBO6he-FvZH-O0Taqgp7AtDTpc4nhZZsFPKonxVZka7dhw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3cYTb9hODVIxBDWakWYU5ne-joI>
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 15:25:02 -0000


> On Oct 17, 2018, at 9:18 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>> (1) provides a channel for DANE records that is reliable in the absence of
>>     an attack
> 
> I think this alone would be worthwhile -- and is the purpose I have always had
> in mind for the draft.

Well, a security mechanism that "works in the absence of attack" looks
rather pointless to me.  Cleartext transmission with no authentication
also works in the absence of attack, and yet does not a security mechanism
make.  The -07 draft covers only the use-cases where the extension is
mandatory (pin interval of "from now and forever"), all the other use-cases
fail.

> I don't agree with Viktor's "no substantial issues have been
> raised" claim.

Then, please raise them!  Just saying "hostile pinning, QED" is
not a substantial issue.  We've argued in detail that:

1.  This was never the real problem with e.g. HPKP, and the credible
    concern is footgun, not "hostile pinning".  We've shown that footgun
    is not a substantive problem here.

2.  We've also argued that even with "hostile pinning" the domain owner
    recovers if he is able to deploy the extension (unlike never known
    keys with HPKP).  And clients that can do real DNSSEC lookups can
    always pay the extra latency, and if necessary do DNS over TLS to
    1.1.1.1, et. al. to get around last-mile barriers, and thus clear
    any unauthorized pins even prior to server-side extension support.
    
3.  And, frankly, I find hostile pinning not a credible threat, and to
    the extent that it yields client-visible side-effects of major prior
    compromise, I see any resulting tamper-evidence as a feature, not a
    bug.
    
4.  Lastly, if nevertheless the "hostile pinning" concern is what makes
    or breaks consensus on this draft, then we're OK with introducing
    exponential scaling-up (over time) of max pin TTL, which will keep
    it reasonably low until the last few years of the scaling horizon.

From where I stand, mere repetition of "hostile pinning QED" frankly no
longer counts as a responsive objection. :-(

Likewise, mere repetition of a claimed benefit from downgradable DANE
signalling, without explaining why or how this is useful, is also not
a substantive argument to support a claim that the use-cases are served
without downgrade protection.  Which additional attacks does such
signalling militate, beyond those already handled by WebPKI?  There
would need to be a use-case where:

	* The extension is not mandatory.
        * Just WebPKI alone does not protect the server.
        * WebPKI + downgradable DANE signal protects the server.

I've not seen any such use-case.

-- 
	Viktor.