Re: [TLS] TLS interim meeting material

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 14 September 2018 16:16 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 86E3C130F13 for <tls@ietfa.amsl.com>; Fri, 14 Sep 2018 09:16:58 -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 HUrVQVvhqS07 for <tls@ietfa.amsl.com>; Fri, 14 Sep 2018 09:16:56 -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 CDF4F130E3A for <tls@ietf.org>; Fri, 14 Sep 2018 09:16:56 -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 298D4308D01 for <tls@ietf.org>; Fri, 14 Sep 2018 12:16:56 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBPS9VAmQnOKJFoMMqzV-FJrMwqZjbjR-RtxcXA56z3vow@mail.gmail.com>
Date: Fri, 14 Sep 2018 12:16:55 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <030DD622-0A87-42B5-A5AD-4163FC01749E@dukhovni.org>
References: <alpine.LRH.2.21.1809121721300.5141@bofh.nohats.ca> <CAL02cgRfOF1Y_XC-=oPqB59RV97=O9_9BJHg2cE2mx3Rk0m26g@mail.gmail.com> <D29B3688-76C6-4A91-9C22-5B0C2601FB19@dukhovni.org> <CABcZeBPS9VAmQnOKJFoMMqzV-FJrMwqZjbjR-RtxcXA56z3vow@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WotrvioH-hB1IW7nF8WCzmyaTZU>
Subject: Re: [TLS] TLS interim meeting material
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: Fri, 14 Sep 2018 16:17:09 -0000


> On Sep 14, 2018, at 12:09 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> In theory perhaps, but as a practical matter, no browser client, at least, can do DNSSEC hard fail, because the rate of organic DNSSEC interference is too high. Indeed, this is the primary reason why DANE over TLS is interesting.

Yes, of course, no disagreement there.

But the result is not lots of browsers with half-baked implementations
of DANE that ignore DNS lookup failures and accept the downgrade risk,
but rather no implementation of DANE in browsers via direct DNS lookups,
which makes sense given the current state of the Internet "edge".

And so here we are evaluating an alternative approach, that might also
address latency concerns, support raw keys while addressing UKS attacks,
...  And, to the extent possible, should be downgrade resistant.  Unfortunately,
only after contact, but we'll have a chance to hash that out at the meeting soon
enough...

-- 
	Viktor.