Re: [TLS] A la carte handshake negotiation

Eric Rescorla <> Sun, 19 July 2015 18:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA9221B2BB4 for <>; Sun, 19 Jul 2015 11:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dtRQN0aeUWUS for <>; Sun, 19 Jul 2015 11:59:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82C3B1B2BB3 for <>; Sun, 19 Jul 2015 11:59:08 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so75696086wib.0 for <>; Sun, 19 Jul 2015 11:59:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PqvZjkLKWq1y4EhZ3R5o6a9zfdEa6/1+XV8xF1AkoU4=; b=XvSdG8Mw4aDN6hJl60+H8OlBslRmYdZ113i68732iywVRLCkJGG32P320wK4AMNKBX SkR3RovONbT2Jc95p0bsePMvFQ/EhSz8YsQxGRsGoAp8YMbckdk3BEOHf3vEMUuwumTJ iyKZFIdCtexThWDYhAgq0uPjZtrUoYYSB1kfhOMGhL8fSfR9SE2auaBKdEE6Qo4J1LNu /uFnhyrAOWggvorjM2yu0OZK+SkFupSsXOuYaENtHjAbjlIDwY+dmGC+eZuGKvjeTZrP JAFP/wskVgdbKz2DRlKmsUaoIAc5W4S9HobNca4sRA6meIPbqCbtMnJd1AE3mLHBJmvM 9vOQ==
X-Gm-Message-State: ALoCoQmzVQ1CzTsv0UJsjduztSvg/S/SVECw1HAvrKNjA5vjc821H3wSB90FjxMyXODhjRk6C4UT
X-Received: by with SMTP id md18mr14633677wic.31.1437332347278; Sun, 19 Jul 2015 11:59:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 19 Jul 2015 11:58:27 -0700 (PDT)
In-Reply-To: <>
References: <> <20150612083153.GA24990@LK-Perkele-VII> <>
From: Eric Rescorla <>
Date: Sun, 19 Jul 2015 20:58:27 +0200
Message-ID: <>
To: Manuel Pegourie-Gonnard <>
Content-Type: multipart/alternative; boundary="001a11c37eb8fbf09e051b3f03c0"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] A la carte handshake negotiation
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: Sun, 19 Jul 2015 18:59:10 -0000

On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard <>

> Hi,
> sorry for resurecting an old message on a fairly tangential point.
> On 6/12/15 10:31, Ilari Liusvaara wrote:
>> AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
>> both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
>> signature_algorithms).
>> (In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA)
>>  Either we're not talking about the same thing, or we don't read RFC 5246
> in the same way. Section 7.4.2 (pages 47-48) says:
>    -  The end entity certificate's public key (and associated
>       restrictions) MUST be compatible with the selected key exchange
>       algorithm.
>       Key Exchange Alg.  Certificate Key Type
>       [...]
>       DHE_RSA            RSA public key; [...]
> To me that clearly means that if the server selects a DHE_RSA ciphersuite,
> it MUST NOT use a certificate that contains an EC key, even if the client
> offered ECDSA in the signature_algorithm extension. However, in that case
> the certificate may be signed using ECDSA, which is not the same.
>  Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is
>> quite clear about interaction of signature algorithms in ciphersuites
>> and explicit signature negotiation (explicit negotiation always takes
>> percedence).
>>  I'm afraid we both agree that TLS 1.2 is quite clear, but disagree about
> what it says, which is ironic :) My understanding is that, regarding the
> key in the server's certificate, there is indeed double negotiation, with a
> clear rule that the set of allowed choices is the intersection of what is
> allowed by the ciphersuite and what is allowed by the signature_algorithms
> extension.
>    If the client has offered the "signature_algorithms" extension, the
>    signature algorithm and hash algorithm MUST be a pair listed in that
>    extension.  Note that there is a possibility for inconsistencies
>    here.  For instance, the client might offer DHE_DSS key exchange but
>    omit any DSA pairs from its "signature_algorithms" extension.  In
>    order to negotiate correctly, the server MUST check any candidate
>    cipher suites against the "signature_algorithms" extension before
>    selecting them.  This is somewhat inelegant but is a compromise
>    designed to minimize changes to the original cipher suite design.
> To me, the "MUST check against" does not suggest "may still pick the
> DHE_DSS suite and use an RSA cert with it if signature_algorithms contains
> acceptable RSA pairs".
> Regarding other signatures in the certificate chain, only
> signature_algorithms apply, so there is no "double negotiation" indeed.

This is how I understand the situation as well. I am sad to hear that we
manage to make the document clear on this point.


>  Of course, I wouldn't be surprised if there was fair bit of software
>> that got those rules wrong...
>>  Regardless of whether your interpretation or mine is correct, I'm pretty
> sure various implementations will do things in different ways here. Anyway,
> a large proportion of servers deployments only have one cert, in which case
> the RFC says "it [the server] SHOULD attempt to validate that it [the
> certificate] meets these criteria", which may be interpreted as an
> indication that the server may try to send its only certificate anyway and
> let the client decide how to deal with it.
> Manuel.
> _______________________________________________
> TLS mailing list