Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Viktor Dukhovni <> Thu, 05 April 2018 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 667F3126BF7 for <>; Thu, 5 Apr 2018 07:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.643
X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_PHISH=3.557] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xNnODBLZzK-I for <>; Thu, 5 Apr 2018 07:36:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C508912D7F9 for <>; Thu, 5 Apr 2018 07:36:35 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B8B857A330D for <>; Thu, 5 Apr 2018 14:36:34 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 05 Apr 2018 10:36:33 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <> <> <> <20180405022007.GG25259@localhost> <> <> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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: Thu, 05 Apr 2018 14:36:37 -0000

> On Apr 5, 2018, at 10:20 AM, Eric Rescorla <> wrote:
> Yes, so quite possibly I need to upgrade my entire server farm, which might be running
> on some software which has no version which implements this extension. This could
> be an enormous effort.

Yes, module hijack.  The same applied with STS, if the server farm had no TLS support,
or insufficient capacity to handle the load with TLS.  This is not substantially
different, other than that TLS support is fairly mainstream now.

Note that the hijack would also need obtain WebPKI certificates (as I would expect
DANE for browsers to insist on the restrictive PKIX-TA(0) / PKIX-EE(1)).  So the
that would be a full takeover of the domain, and the affected clients would have
to have visited the hijacked site during the time it was controlled by the malicious

Note also that clients that support the extension will also be rare for some time,
so the impact of any hijack that improbably pins the extension will be modest.

So, if some users running early adopter browsers that support the extension have
to manually clear the pin after a domain hijack, and visiting the hijacked site,
potentially disclosing sensitive information to the wrong party, etc. then becoming
aware of that when the browser warns them about missing extension support seems like
a feature and not a bug.  They can and probably should contact the legitimate site's
help desk and figure out what to do to secure their account, change passwords, ...

This scenario is not impossible, but a rather low risk, and would initially, as
server support ramps up, affect few users.  The pin can be cleared by the user
in such a situation, and having the user be aware of the fact that he/she visited
a hijacked site is not a bad thing.