Re: [TLS] A la carte handshake negotiation

Eric Rescorla <ekr@rtfm.com> Sun, 19 July 2015 18:59 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9221B2BB4 for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 11:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtRQN0aeUWUS for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 11:59:09 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C3B1B2BB3 for <tls@ietf.org>; Sun, 19 Jul 2015 11:59:08 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so75696086wib.0 for <tls@ietf.org>; Sun, 19 Jul 2015 11:59:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.180.208.114 with SMTP id md18mr14633677wic.31.1437332347278; Sun, 19 Jul 2015 11:59:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Sun, 19 Jul 2015 11:58:27 -0700 (PDT)
In-Reply-To: <55ABF240.6090506@elzevir.fr>
References: <201506111558.21577.davemgarrett@gmail.com> <20150612083153.GA24990@LK-Perkele-VII> <55ABF240.6090506@elzevir.fr>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 19 Jul 2015 20:58:27 +0200
Message-ID: <CABcZeBPJUXdhER3qLiq0e_wK4bxCxw6D+Oq+3ZFXGeo6Bn1sXw@mail.gmail.com>
To: Manuel Pegourie-Gonnard <mpg2@elzevir.fr>
Content-Type: multipart/alternative; boundary=001a11c37eb8fbf09e051b3f03c0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MY1EsytO1TLr-s6TqfhL8AUkcdc>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] A la carte handshake negotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 <mpg2@elzevir.fr>;
wrote:

> 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
didn't
manage to make the document clear on this point.

-Ekr


>
>  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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>