Re: [TLS] A la carte handshake negotiation

Manuel Pegourie-Gonnard <mpg2@elzevir.fr> Sun, 19 July 2015 18:53 UTC

Return-Path: <mpg2@elzevir.fr>
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 C0C2E1B2BAD for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 11:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.96
X-Spam-Level:
X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, T_RP_MATCHES_RCVD=-0.01] 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 X5BUX2EQdyTF for <tls@ietfa.amsl.com>; Sun, 19 Jul 2015 11:53:57 -0700 (PDT)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8A11B2BAB for <tls@ietf.org>; Sun, 19 Jul 2015 11:53:57 -0700 (PDT)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id A3567161A7; Sun, 19 Jul 2015 20:53:55 +0200 (CEST)
Received: from [192.168.11.181] (unknown [88.208.109.142]) by thue.elzevir.fr (Postfix) with ESMTPSA id AA8AF1FA1E; Sun, 19 Jul 2015 20:53:54 +0200 (CEST)
Message-ID: <55ABF240.6090506@elzevir.fr>
Date: Sun, 19 Jul 2015 20:53:52 +0200
From: Manuel Pegourie-Gonnard <mpg2@elzevir.fr>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Dave Garrett <davemgarrett@gmail.com>
References: <201506111558.21577.davemgarrett@gmail.com> <20150612083153.GA24990@LK-Perkele-VII>
In-Reply-To: <20150612083153.GA24990@LK-Perkele-VII>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/IJJDH4F7bLba5EUnM3rqaQVbn9A>
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:53:58 -0000

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.

> 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.