Re: [TLS] Review of draft-asmithee-tls-dnssec-downprot-00

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 18 May 2018 13:45 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 148E712D95F for <tls@ietfa.amsl.com>; Fri, 18 May 2018 06:45:12 -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 uKDRizrp2WHz for <tls@ietfa.amsl.com>; Fri, 18 May 2018 06:45:10 -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 3C40312D7F8 for <tls@ietf.org>; Fri, 18 May 2018 06:45:10 -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 511287A3309 for <tls@ietf.org>; Fri, 18 May 2018 13:45:09 +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: <CABkgnnVc_kR0OsO=DbYoA8vCe5sa24qOHRoPdH-ea2iU59t8tg@mail.gmail.com>
Date: Fri, 18 May 2018 09:45:08 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <08EA6A2F-3E74-456D-BC8C-04C57312A214@dukhovni.org>
References: <CABkgnnVc_kR0OsO=DbYoA8vCe5sa24qOHRoPdH-ea2iU59t8tg@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/owF1X3goMrNUUKv6wtcKCQ_JsVo>
Subject: Re: [TLS] Review of draft-asmithee-tls-dnssec-downprot-00
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: Fri, 18 May 2018 13:45:12 -0000


> On May 18, 2018, at 2:42 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> We have potential downgrade attacks on a range of extensions, not just the
> identified one.  For instance, failing to provide the extended master
> secret extension represents a fairly significant regression in capabilities
> that could be indicative of an attack.  The same for renegotiation info,
> SCT, and others.  I thought supported_versions might be a valid use, but
> I'm not 100% sure there.  The extension could reference itself though.
> 
> A commitment to continue to provide a particular feature - as identified
> via its extension - would be a potentially useful capability.

The same thought had already occurred to me, and I concluded
that chain the extension is materially different in this
respect from the others and the approach is not generally
applicable.

The difference is that the DNSSEC (DANE) chain introduces a
new set of trust anchors, and so absent those trust anchors
one might reach different conclusions about the authenticity
of the peer.  Presence or absence of such trust anchors for
the server endpoint is authenticated via DNSSEC.

The other extensions you mention operate within the same
trust-anchor context whether present or absent.  An attacker
in possession of a forged certificate or a misappropriated
private key is not thwarted by the requirement to present those
extensions, can employ them at will, and can authenticate a reset
of any previous "support lifetime".

If the absence of a TLS extension makes it possible to impersonate
the peer (without having suitable credentials), that extension should
be mandatory in TLS.  If the extension merely protects against chosen
plaintext attacks (ala CRIME, BEAST, ...) then only the authentic
server can downgrade itself, so we don't need a pin to require the
extension.

Which optional extensions militate server impersonation by an MiTM
who does not have forged credentials or misappropriated keys?

Does the above make sense?  Am I missing a class of extensions that
are needed to make sure the peer's authenticity is not compromised
even in the absence of forged or stolen credentials?  If such
attacks are practical, why aren't the militating extensions mandatory?

-- 
	Viktor.