Re: [TLS] Fresh results

Karthikeyan Bhargavan <> Fri, 04 December 2015 06:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D4451B2DF7 for <>; Thu, 3 Dec 2015 22:41:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Status: No, score=0.301 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, MANGLED_BACK=2.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 85VCp7HWjKyq for <>; Thu, 3 Dec 2015 22:41:22 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80D381B2DF6 for <>; Thu, 3 Dec 2015 22:41:21 -0800 (PST)
Received: by wmww144 with SMTP id w144so51849470wmw.0 for <>; Thu, 03 Dec 2015 22:41:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OVxE38RWJiLyGR83VC3C/yVytf5SWXfWdNz7TZQo3jY=; b=CMu3I3uOOE1A7oOKpLkSC3YwBfjTfOMam22vb3sWUFWUNNlf3JIydjQrCA0r/S3Utf eAMAJ4xyyZZMXi5Uy0pMTFbyuO4cCK95mTvhAkmhnPJhTusHK8AAzf7NIR2UeduOS5cs 5Tb98cxqBl5BsWaY3HSUUu5p65CI6Ny6dXKWFRU4nxbUwQ7KU8T6JkT0WN3qdtcPPOdJ Bc669HBHCY1ECHINQSF1FlWNWKFrNOphDbfCBoFjS/AgjsjY5eLy70NzWWKYniUl6+x0 AKWaQ9L6q3HO0aiMGUWYMJ6EaqXTtjEKaQXe2rraoR8iUA4g3flgiWESXJ14OXbdjtVi Y6mQ==
X-Received: by with SMTP id m6mr15198931wja.124.1449211280108; Thu, 03 Dec 2015 22:41:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id q9sm10708464wjo.9.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Dec 2015 22:41:18 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AA136A2F-F2E0-4454-AF66-EC99AFD6D82A"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Fri, 04 Dec 2015 07:41:16 +0100
Message-Id: <>
References: <> <20151201210257.64f1a7a5@pc1> <> <> <> <>
To: Fabrice Gautier <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Fresh results
X-Mailman-Version: 2.1.15
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: Fri, 04 Dec 2015 06:41:24 -0000

The use of the same RSA key for decryption and signature has always been 
problematic from a cryptographic point of view. As far as I am aware, all
current security theorems for TLS assume that the same RSA certificate (public key) 
is not used in both RSA and DHE ciphersuites. 

In theory this should be enforced by KeyUsage, there are distinct KeyUsages
for public key encryption and digital signatures and we may require that DHE/ECDHE
ciphersuites must use certificates that *do not* enable public key encryption,
and that clients must enforce this behavior.

Of course, the current practice is that KeyUsage is ignored. OpenSSL will
take a certificate that only specified Public Key Encryption and happily use
and accept it for digital signature. Similar flexibility allows ECDSA certs that
should only be used for signing to be used for static ECDH key exchange (leading
to other vulnerabilities). Do we (as in the TLS working group) have the necessary
influence to make sure that KeyUsage is respected?

> On 04 Dec 2015, at 02:11, Fabrice Gautier <> wrote:
>> On Dec 3, 2015, at 12:47, Yoav Nir <> wrote:
>>> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier <> wrote:
>>> On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos <> wrote:
>>>>> On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote:
>>>>> On Tue, 1 Dec 2015 14:28:49 -0500
>>>>> Watson Ladd <> wrote:
>>>>>> 13QuicAttacks.pdf
>>>>>> This one looks very nasty to fix. Short of disallowing the use of
>>>>>> RSA
>>>>>> certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I
>>>>>> don't see a good fix. I haven't read this paper in detail yet.
>>>>>> Cross-protocol attacks are the gift that keeps giving.
>>>>> Correct me if I'm wrong, but as I understand the result (and I had
>>>>> one
>>>>> of the authors explaining it to me a few days ago) the problem
>>>>> appears
>>>>> only if you have a TLS 1.2 implementation with an RSA keyexchange
>>>>> that
>>>>> is vulnerable to a bleichenbacher attack. If it is not then you're
>>>>> fine.
>>>> The interesting result of the paper is:
>>>> "Even though this limits the
>>>> practical  impact  of  this  attack,  it  demonstrates  that  simply
>>>> removing a legacy algorithm from a standard is not necessarily
>>>> sufficient to protect against its weaknesses."
>>>> Even though the attack does not work for current implementations it
>>>> underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't get
>>>> any advantage from the better algorithms in TLS 1.3. You are as safe,
>>>> as if you'd be using TLS 1.2.
>>>> That can be claimed to be trivial result given that it is underlined on
>>>> almost every paper that describes a cross-protocol attack, but it is
>>>> not still grasped by the engineering community. There have been
>>>> described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5
>>>> by Yu et al., TLS between ciphersuites starting by Wagner and
>>>> Schneier), but still we reuse keys between protocols.
>>> Can we solve that problem generically by having TLS implementations
>>> use different certs for different TLS version, and have an indicator
>>> in the certs to indicate which version(s) they are for ?
>> That’s a heavy-handed approach that requires servers to have multiple certificates and new selection logic.
> Implementations already should have logic to select certificates based on SNI, so that doesn't seem so far fetched especially in the context of adopting TLS1.3.
>> Wouldn’t it be better to mandate that if your TLS implementation supports both TLS 1.2 and TLS 1.3 it should take actions necessary to mitigate the bleichenbacher attack?
>> In fact, if you don’t care much about very old browsers, isn’t it possible today to mandate that the TLS implementation not use RSA keying? That way the oracle is gone.
> Seems fine, for this specific attack, assuming you can ignore old clients and that your countermeasures are fully efficient.
> On the other hand, having two keys seems like it would counter any current and future cross protocol attacks.
>> Seems better than requiring web server administrators to acquire two certificates.
>> Yoav
> _______________________________________________
> TLS mailing list
> <>
> <>