Re: [TLS] WG adoption: draft-nir-tls-rfc4492bis

[[e-mail] (Martin Rex)]

Stephen Checkoway wrote:
> 
> Yoav Nir <[e-mail]> 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).

  https://tools.ietf.org/html/rfc2246#section-7.4.2

   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:

  https://tools.ietf.org/html/rfc6101#section-5.6.2

   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.


-Martin