Re: [TLS] Precluding bilateral opt-in for downgrade protection.

Shumon Huque <> Sat, 28 April 2018 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 515FC126BFD for <>; Sat, 28 Apr 2018 09:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IKugRMa-_kpd for <>; Sat, 28 Apr 2018 09:26:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D44E81243F3 for <>; Sat, 28 Apr 2018 09:26:27 -0700 (PDT)
Received: by with SMTP id e12-v6so5878205iob.8 for <>; Sat, 28 Apr 2018 09:26:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HWksXgOxz8tUAsDVQ9NdyW7ZtjTL1AfhGCCvI2cydRs=; b=vQKamN70JVE+k4kK94e8zvbpCIyBWvIvOZqDzT1AtVOJIexOiGwWPfQtgxbOMBewwe aVlzmhNhyJ5zELrnGLQ4zjHz4hzwwFEm08dwFI2wdG+jA3m9Sw6y4jomsesyOknc8pvr vCvmCL2IklIxpoBCxvocCZM8qso19jpMoxOpLpC9ERkE87WUIcEf8beViN4u1fRqPf7s PHwWuzj6jZfdHSohWUQ48TkuVPcvuSTvc9J8ifbQGvB6SFmT9aR5InLs9ULzOQljOZZL qcrCtIKb6SOYbMz/8AcJv6L2dAoUJCtTa3AZbjDSooSgU6kIgUcV3LvgOD3S0mcZu/vr PEmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=HWksXgOxz8tUAsDVQ9NdyW7ZtjTL1AfhGCCvI2cydRs=; b=JpuQfWpEPy3TNrflGmGGMO1dE+9AfWpOE9hgbA7dijaYwKiYWbPDA2cGsVihEKNHv+ TFEJ8CD3TEP2K9kKca9dlZpeXTe/OSf4Esj9yCsgf4OQ+2LBH2hSZE6staeIwOwXAfjk quUz6SXh+dq4ZSQP31c1dqLOlHmxfSox3QxzoXGSB88RXb0QzQ4BGGKuJvePTMmx4mRe wrMQkzqP16JRy7V885lQIfr6oaJTCHcII8TGv53hXAa1plnIO67I2KLDCYmkDRD5eRcl H6iL5+9EtVTEuh7UK2MSTczkjBYRFHUSV6wfdYZTUGQCHewTqlTKxOD671DhzK9tmOvo i4+w==
X-Gm-Message-State: ALQs6tAucEfkJYq+s6Pv1Vr/+wbhQcAzapzV/NIaofinbDp9fz+3f+Yf ls+vxRQIT/n3A72LoG0PrQ2FCBcl5zsb05ekv3RZkszR
X-Google-Smtp-Source: AB8JxZoSaOa71Xf/BG7EEu+9NCQ+00bwkhD6FIxKW5wg4sClcSJAyJu2DhbqS3jwHqsb2C5x1zUq26uvdollvlPyivw=
X-Received: by 2002:a6b:bcc5:: with SMTP id m188-v6mr7221781iof.292.1524932786774; Sat, 28 Apr 2018 09:26:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 09:26:26 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Shumon Huque <>
Date: Sat, 28 Apr 2018 12:26:26 -0400
Message-ID: <>
To: TLS WG <>
Content-Type: multipart/alternative; boundary="0000000000000fe8b4056aeb1536"
Archived-At: <>
Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection.
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: Sat, 28 Apr 2018 16:26:30 -0000

On Fri, Apr 27, 2018 at 4:17 PM, Viktor Dukhovni <>

> It would be helpful to know where opponents stand on negotiating
> continued use of the extension in general and in the future.  We
> are confused by their statements so far, and wonder if they are
> not just generally in opposition to any negotiation of continued
> support for the extension (in all applications), and whether that
> might be driving their opposition to the 16 bits, whether consciously
> or not.

Hi Viktor,

I am in support of doing the pinning in a new extension, and will
even help you write the draft if you like. I'm pretty sure we could
have easily done this in the time that has been taken up on list
endlessly and repetitively discussing this.

Clearly I can speak only for myself, but I strongly suspect others
in the WG will also support this (as long as it's in a separate
extension), so if you pursue this approach, I think you'll succeed
in adding this functionality, and will not be actively blocked by

As far as I can assess, the reason you are getting resistance for
adding a pinning field in this spec is two fold:

First, there is no agreement that your reason for doing pinning,
i.e. that DANE needs downgrade resistance against PKIX attacks
is even valid. This can be clearly seen from various comments on
list and at IETF/London, such as the point made many times that
the original purpose of this draft was to add DANE as an additional
possible authentication mechanism in TLS, not to position it as a
mechanism that if available unconditionally trumps PKIX authentication.
If you look back at my back-and-forth answering IESG review comments,
you will observe that I had to add text to the draft that says TLS clients
can fail back to normal PKIX authentication if DANE fails for any reason
(i.e. a protocol behavior that is the opposite of downgrade resistance).
There are other comments like (paraphrasing) "What's the downgrade
problem? The only security downgrade issue I see is DNSSEC's use of
legacy crypto"?

Clearly, for most DANE proponents, an obvious goal for the protocol
would be to protect against PKIX attacks. In an ideal world, I share
that view also. But I also recognize the other views I just described,
and am willing to make compromises to get a foot in the door for DANE
first. There will always be opportunities to improve the protocol

In fact, the legacy crypto issue will always be a huge impediment for
any DANE proponent in arguing against the Internet PKI. An argument
I've heard many times: Since most of the Internet PKI has moved to
2048-bit RSA or better, why would I degrade the security of my system
by moving to DANE, which in most cases is protected by 1024-bit RSA ZSK's
in the weakest part of the chain (some chains are even weaker)? And if so,
why should PKIX not need downgrade resistance against DANE, rather than
vice versa? For DANE proponents to make a stronger case, they need to
urgently solve this problem. I'm not sure how to do that quickly - it
probably involves getting ICANN to impose rules on TLDs prohibiting
weak keys (which would likely take years).

The second reason is that pinning really is a controversial feature.
And for this reason, putting it in the core spec will be difficult.
I won't repeat all the arguments and concerns expressed already, many
of which I share by the way. So moving this feature into a new optional
extension (both the pinning field and a description of the associated
behavior) appears to me to be the past of least resistance.

By continuing to argue your position, the most you can hope to achieve
is deadlock.


(Addendum: I did want to thank you for pushing on the issue of
explicitly allowing authenticated denial of existence chains in the
current draft. In environments where all TLS servers support this
extension, this allows the protocol to be bulletproof in a way that
satisfies even the security purist, so I'm glad it's in the core

Shumon Huque