Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

Martin Thomson <> Wed, 16 January 2019 03:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A64F12F1A2 for <>; Tue, 15 Jan 2019 19:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=oOk+q3bG; dkim=pass (2048-bit key) header.b=T/Dp8ZxH
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6rYke31ngxjy for <>; Tue, 15 Jan 2019 19:39:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E57012F18C for <>; Tue, 15 Jan 2019 19:39:46 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailnew.nyi.internal (Postfix) with ESMTP id 3DA4A286A7 for <>; Tue, 15 Jan 2019 22:39:45 -0500 (EST)
Received: from web4 ([]) by compute1.internal (MEProxy); Tue, 15 Jan 2019 22:39:45 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:references:in-reply-to; s=fm1; bh=RHv lfLqndXBasiJpN4C/KZk8kEoJ25+HzdyadVqpZnc=; b=oOk+q3bGw1X7k9toPqp ZXSnFUdq76Z/0BDR64Hsl2aeUgXQ/kIBATiP1DoxSI8KKxqyXBDy50mCMKIb4THV afW3IbPQRTk99nxsj8te5mUiqvD1gM0r1tPyk5BECdaRV5JP8YTlpQm4ReFeKVCP 3BFgKmqf8Q0X2ci2SNJxa4PSKIR6KX2zGT+NrA8UGiTxX3VyPDtLZ2PJiDXTVUct 1KDkdSi2FS79/KLz3FeCV5fVey3kyppn4bAm0EvPFEUDJ8gO0KSTdLBNlPL8fYXO Z9AbnUXCTOfwwfuA5GbaPuK5EfunNza4XVgFiJySnPI/maky+dKUp3fK/Mu6Fz4D R2Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=RHvlfLqndXBasiJpN4C/KZk8kEoJ25+HzdyadVqpZ nc=; b=T/Dp8ZxHMxR4/F545g3PNjInNJ5yOzFSyKo073afeDb8GJtsmXiOGv8wG IZKsyMf6ttIbBfozkQxCalmCIFS1MhVpATrWMNwwNEUjT0fxA3CYc71dnkXhIlM1 WGWHR6zB3dIjG8UbaRDNww8a235CrUsDi5c8IzBg7P7NhX3ctgcp4fyvtUF2iDn8 oaJqxS9eqzVi7k3QBEmfYp3iRLrTSNeOI2IZLvN8CVSYl8oFDmWxJT8GMInSIoet csP4vo203vtY1zhpz4gn42bDF6N90RwvsL0fXfRFvT6d9/L5HDKYrE0+vlc6Nwtz kfTedlvsW0MeUC0oaJRIROwnLx68A==
X-ME-Sender: <xms:gKc-XBkHWQHR3xWMZZweFxUTahVDp77DlvZBfp6nlU8NpvLKdlQt_g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeeggdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfouffffhgjsehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:gKc-XGKtsrnWVkHouz-OlgyzLmchvAZV0R9hb6vi-ivKX3W0kBRNCA> <xmx:gKc-XPpHA7V3RY8MgAeL8VvPi5SJZcIw9zlY7AVn2Vj2uhxzl8_Aqg> <xmx:gKc-XLSgl28MJqup2RAWIHS1HYAW3dmCTakG4L5vW_WsgXzMhxjTGw> <xmx:gac-XFPBLETiw5YAf7HBLZCxbANZPwRBfX2DA14LncZvUIUrhhUX_Q>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 87288BA783; Tue, 15 Jan 2019 22:39:44 -0500 (EST)
Message-Id: <>
From: Martin Thomson <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-36e4bfd3
Date: Wed, 16 Jan 2019 14:39:44 +1100
References: <> <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02
X-Mailman-Version: 2.1.29
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, 16 Jan 2019 03:39:49 -0000

On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote:
> Usually the negotiation happens during the processing of the client hello.

I don't think that the problem here is a code problem.  It's an operational one.

In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be made in isolation.  You decide to flip the switch and flip it.  But if you are doing delegated credentials, deploying a new version depends on having a fallback in place for that version, or getting the vendor of delegated credentials to start supplying new credentials.  And that assumes that all the necessary stores are keyed correctly (though this highlights the case where that might not happen), and the code has been written.  It's not that it's impossible, but more that it complicates what was previously uncomplicated.

As you say, the decision to use a delegated credential is fairly simple.