Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis (Martin Rex) Thu, 27 November 2014 22:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6F3851A006E for <>; Thu, 27 Nov 2014 14:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9HlXXTuqfDCh for <>; Thu, 27 Nov 2014 14:02:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95F141A0056 for <>; Thu, 27 Nov 2014 14:02:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68EA03A334; Thu, 27 Nov 2014 23:02:48 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 5E2BC428A7; Thu, 27 Nov 2014 23:02:48 +0100 (CET)
Received: by (Postfix, from userid 10159) id 533AD1B01C; Thu, 27 Nov 2014 23:02:48 +0100 (CET)
In-Reply-To: <>
To: Stephen Checkoway <>
Date: Thu, 27 Nov 2014 23:02:48 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Cc: " (" <>
Subject: Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis
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: Thu, 27 Nov 2014 22:02:54 -0000

Stephen Checkoway wrote:
> Yoav Nir <> wrote:
>> Seeing as the 18th has come and gone, can I take the near
>> silence as confirmation that I can resubmit as a WG draft?
> I support adopting this draft.
> Maybe this isn't the right time to ask, but I think I'm
> misunderstanding a part of it.
>    Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
>    key exchange algorithms require the server's certificate to be signed
>    with a particular signature scheme, this specification (following the
>    similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in the TLS base
>    documents) does not impose restrictions on signature schemes used
>    elsewhere in the certificate chain.
> Why should we require that the certificate be signed with the signature
> scheme corresponding to the public key? It's easy to produce working
> certificates that don't meet this:
> Using openssl s_server and s_client,
> I get a connection using ECDHE-ECDSA-AES256-GCM-SHA384.

This is actually perfectly reasonable behaviour of OpenSSL and a lot
of other TLS implementations.

> Is my reading correct that this is disallowed by the draft?
> If so, can you explain why that's the case?

I assume that this might be cause by a serious and stupid defect in
the TLSv1.0 and TLSv1.1 specifications that is obviously unreasonable and
backwards-incompatible to SSLv3, and was only fixed in TLSv1.2 (rfc5246).

   7.4.2. Server certificate


   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
*>     method, as follows. Unless otherwise specified, the signing
*>     algorithm for the certificate must be the same as the algorithm
*>     for the certificate key. Unless otherwise specified, the public
*>     key may be of any length.

For comparison SSLv3:

   5.6.2.  Server Certificate

   If the server is to be authenticated (which is generally the case),
   the server sends its certificate immediately following the server
   hello message.  The certificate type must be appropriate for the
   selected cipher suite's key exchange algorithm, and is generally an
   X.509.v3 certificate (or a modified X.509 certificate in the case of
   FORTEZZA(tm) [FOR]).  The same message type will be used for the
   client's response to a certificate request message.

So any *new* document should advise implementors to remove any such
erroneous and counterproductive "same algorithm checks" that might
accidentally got implemented by an unexperienced implementor who didn't
realize that this must be a defect in the spec and is backwards-incompatible
to SSLv3.