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

Shumon Huque <> Sat, 28 April 2018 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F40412778D for <>; Sat, 28 Apr 2018 12:28:41 -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 0pBGUEQXNREC for <>; Sat, 28 Apr 2018 12:28:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81CC9124205 for <>; Sat, 28 Apr 2018 12:28:39 -0700 (PDT)
Received: by with SMTP id e20-v6so6174927iof.4 for <>; Sat, 28 Apr 2018 12:28:39 -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 :cc; bh=UegmHQNbLDZDn9/KW4HQjvjsFex1Hidu+wnsUYpj37k=; b=NMPFEZbjiymnluRlH3AczYPow95rAk4FLsfPtgBzW7vWehebOIknwKjrL21AT/FenH hoMVVPWBfgPw3+DIpTMLlad408f9Wfm046zHVxo7SehIsubyoK29j8CqFR+NS+dYgr1R C2F7VWPoAcAxw1byUyn014tosSxjyKtmkR36vVyhONPit7Boro9OAjzkcxVd3SS9K9H+ LtATM/DEt+cATs3A0a6eT1LiofatgGdGe7o1Rh3QBju1BI9O5e+7j5gMxnsGLrqjM9tI Ys46xNBzFaV5/koyNDGdemZVwJipCU8vq5W7bYgzi+HhUub/kKCUPKxNM652eZmMlb1Y dIEg==
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:cc; bh=UegmHQNbLDZDn9/KW4HQjvjsFex1Hidu+wnsUYpj37k=; b=cRu6d4qQNIMJFe9dr8D9sapTougKh1Jx9NVNEL3sNLV140uFxmoybApC1OF9JR//hx hp9BEVCIp1YW5RqwqEFnJZOJeFFjwDKfM56uwWnk+ongUW8GEnadlFi+FRDDMVKX+yUk nKVrGsatcDER3e/bwBfEaHSEIQ++YDehZDlsmi/rzSum2Rro1I0Gj6hz/ooTtSQ8T1Zk +JxNSxY3LYEg7rF3XNWus3S3FvS9RKCRJcRdbtRWK6IylnaagJvP0af5SqC4QVLWG61E xx8ja64aakDNGX2S5cvgaqYRqDYdxjXpJEJ3NnGI/HAL0nJYj6uFHMNtsJ2VLNrG0Vix OvIw==
X-Gm-Message-State: ALQs6tAh7ACek+W5bcJH7y8wBC7zFgwSLx8HmxfmMALJyVgSuEL/i6K/ NFgHOr3CxgZmD/pyt+/DL/Trxn4oWP7iHp0LMWw=
X-Google-Smtp-Source: AB8JxZphwwNTeYoGpTTIHOLmWofLkQ4NdYIHRA1eHoUxV7MBa3vNd5tWGC5cCgi9yL5vjHbYmeOYjHReCsBXJ+uxBGc=
X-Received: by 2002:a6b:bcc5:: with SMTP id m188-v6mr7684569iof.292.1524943718887; Sat, 28 Apr 2018 12:28:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7c91:0:0:0:0:0 with HTTP; Sat, 28 Apr 2018 12:28:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Shumon Huque <>
Date: Sat, 28 Apr 2018 15:28:38 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: TLS WG <>
Content-Type: multipart/alternative; boundary="000000000000aab80a056aeda031"
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 19:28:41 -0000

On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters <> wrote:

> On Sat, 28 Apr 2018, Shumon Huque wrote:
> [ not going to repeat my technical arguments here, just going to comment
> on process ]
> 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 is incorrect. From the replies to the consensus call on the list,
> it actually weights in favour of _some_ kind of downgrade resistance.

This isn't clear to me at all. What I observe is that some folks who don't
want pinning in the draft are okay with it being an optional separate
extension (which they can ignore, but others that want it can implement).

Sadly, only a handful of people are actually participating on the list.
What you are ignoring is the many people who spoke up in person at
IETF/London against pinning. Most of those folks are not speaking up
on list now. So if we do put the pinning field in this draft, what I suspect
will happen is that it will be discussed at some future IETF TLS WG
meeting, and will be shot down, and we'll be back to square one again,
and this draft will never make progress.

Thus my pragmatic side is encouraging going in the direction of the
new extension, which I believe has more chance of success.