Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

Viktor Dukhovni <> Wed, 21 February 2018 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5E64124BE8; Wed, 21 Feb 2018 10:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fh_6gEewYLkA; Wed, 21 Feb 2018 10:49:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74C8A124BAC; Wed, 21 Feb 2018 10:49:56 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B3CBA7A3309; Wed, 21 Feb 2018 18:49:49 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Wed, 21 Feb 2018 13:49:49 -0500
Cc: tls-chairs <>,, The IESG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Feb 2018 18:49:58 -0000

> On Feb 21, 2018, at 11:00 AM, Shumon Huque <> wrote:
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson <> wrote:
> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
> <> wrote:
>> What's the behavior when the middlebox is a proxy, let's say existing
>> a managed network?  I presume from from section 3.1 that this
>> negotiation doesn't work in that instance unless sites configured for
>> this are not subject to the proxy as is often done for financial site
>> access from corporate networks.  It would be good to know if it does
>> work and that is addressed with the text Mirja calls out for her #1
>> question.  Having this clarified could be helpful.
> If there is a MitM, then this extension simply isn't negotiated.
> That's pretty well understood.  I don't see why that requires special
> mention.
> Yeah, I agree Martin .. this is the same as with any other extension.

Actually, I don't think it is quite the same.  This extension may
be naïvely expected to provide a different peer authentication
mechanism than the traditional WebPKI.  Users who might expect this
extension to protect them from WebPKI compromise via DANE TLSA
records, need to understand that such protection only exists when
DANE is enforced (mandatory) by the client.

The absence of DANE TLSA records, which is downgrade-resistant
when the client has access to DNSSEC authenticated denial of
existence (makes its own DNSSEC lookups) is no longer downgrade-
resistant when delivered via this extension if the client
is willing to accept just WebPKI in the (apparent) absence of DANE
TLSA records.