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

From: Sean Turner <[email-masked]>
Date: Mon, 10 Nov 2014 17:17:55 -1000

All,

This message is confirming the WG consensus we reached in Toronto about producing an updated RFC4492 that is bound for standard track.* Yoav has produced an individual draft that can be found here:

http://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/

that we would like the WG to consider adopting.  Please let us know by November 18th whether you object to adopting Yoav’s draft (and why).

spt

* This is for pre-TLS 1.3 because the 1.3 spec is going to incorporate the EC text directly in the base spec.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 11 Nov 2014 10:00:37 +0100

> that we would like the WG to consider adopting.  Please let us know by November 18th whether you object to adopting Yoav’s draft (and why).

Two points:
1. This document includes fixed ECDH ciphersuites (ECDH_RSA,
ECDH_ECDSA). Given they have 0 deployment on the internet, the question
is why? What are the practical use cases of these ciphersuites and why
should they be defined in a standards track document.

2. This document includes arbitrary curve support. What is the rationale
for including that as no implementations support that [0], and even for
DH we are switching from arbitrary to named groups as well (I also
ignore the known attacks for this option).

Unless there is sufficient argumentation and applicability for the
above, I support the document only with the above removed.

regards,
Nikos

[0].
http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Supported_elliptic_curves

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Nov 2014 23:58:38 -1000

> On Nov 10, 2014, at 11:00 PM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 

Hi, Nikos

The current draft is pretty much a copy of RFC 4492. The intent is to match whatever decision the WG will make for TLS 1.3.

So the changes that you suggest will be made after the document is adopted (either in the -00 or -01 version, whichever way the chairs prefer it). 

Following Sunday’s interim, we’re also likely to remove all the defined curves weaker than P-256 (or maybe P-224 to match the strength of 3DES, although I’m not in favor)

We are also likely to deprecate point format negotiation. We won’t remove it for TLS 1.2, just mandate non-compressed format for existing curves)

And when CFRG recommends a new curve, we will add it to this one.

So this document is in no way in its final form.

The question before the working group now is whether we want such a document that obsolete 4492 and aligns EC for TLS 1.2 with what we want for 1.3, or if we don’t.

Hope this clarifies the situation

Yoav

---

From: Sean Turner <[email-masked]>
Date: Sat, 15 Nov 2014 12:07:17 -1000

> Hope this clarifies the situation

The idea is that the -00 version is pretty much 4492 so that every change we make will be easily tracked in the diffs.

spt (as chair)

---

From: Sean Turner <[email-masked]>
Date: Sat, 15 Nov 2014 12:13:06 -1000

spt (as chair)

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Nov 2014 10:13:34 +0200

Seeing as the 18th has come and gone, can I take the near silence as confirmation that I can resubmit as a WG draft?

Yoav

> On Nov 11, 2014, at 5:17 AM, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stephen Checkoway <[email-masked]>
Date: Thu, 27 Nov 2014 11:15:59 -0500

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

$ openssl genrsa -out ca.key 2048
$ openssl req -new -x509 -days 2 -key ca.key -out ca.crt -sha256

$ openssl ecparam -out server.key -name prime256v1 -genkey
$ openssl req -new -sha256 -key server.key -out server.csr
$ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt -days 1 -sha256 -CAserial ca.seq -CAcreateserial

Now I have a cert with a P-256 public key that is signed with signature algorithm sha256WithRSAEncryption. That is, this does not meet the MUSTs in your draft.

Using openssl s_server and s_client, I get a connection using ECDHE-ECDSA-AES256-GCM-SHA384.

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

-- 
Stephen Checkoway

---

From: [email-masked] (Martin Rex)
Date: Thu, 27 Nov 2014 23:02:48 +0100 (CET)

Stephen Checkoway wrote:
> 
> Yoav Nir <[email-masked]> 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?
> 
> 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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 28 Nov 2014 00:21:47 +0200

> On Nov 27, 2014, at 6:15 PM, Stephen Checkoway <[email-masked]> wrote:
> 
> 

Hi, Stephen

What Martin said.

Once this is accepted and -00 submitted would be a great time to raise this or make a pull request to get rid of this (IMO silly) restriction.

Yoav

---

From: Stephen Checkoway <[email-masked]>
Date: Thu, 27 Nov 2014 17:41:12 -0500

> of other TLS implementations.

I agree it seems reasonable. It's good to know there wasn't something subtle I was missing.

> realize that this must be a defect in the spec and is backwards-incompatible

It makes sense that a new document shouldn't mandate unnecessarily restrictive behavior.

SSLv3 compatibility isn't high on my list of concerns though. I know you disagree, but we should stop using SSLv3 for all of the reasons specified in draft-thomson-sslv3-diediedie.

-- 
Stephen Checkoway

---

From: [email-masked] (Martin Rex)
Date: Fri, 28 Nov 2014 00:41:08 +0100 (CET)

Stephen Checkoway wrote:
> 
> Martin Rex <[email-masked]> wrote:
>> 

Such a restriction would be in direct conflict with rfc2109 section 6.

  http://tools.ietf.org/html/rfc2119#section-6

The original wording can be seen as a may "unless otherwise specified",
because it comes entirely without rationale, without any indication why
this would be a problem and with no security consideration whatsoever.

> 
> SSLv3 compatibility isn't high on my list of concerns though.
> I know you disagree, but we should stop using SSLv3 for all
> of the reasons specified in draft-thomson-sslv3-diediedie.

This is only relevant when looking at that statement from a viewpoint
of formal correctness of an implementor, who might have been reading
at rfc2246 in Summer 1999, when pretty much the entire installed
base was SSLv3-capable.

This wording, if it was meant to be real, would have required
a TLSv1.0 server implementation to negotiate SSLv3 (and not be allowed
to use TLSv1.0) if the server cert did not fulfil that requirement.

Such a "requirement", especially when it comes entirely without rationale,
is clearly bogus and void.

-Martin

---

From: Stephen Checkoway <[email-masked]>
Date: Fri, 28 Nov 2014 01:51:52 -0500

> Once this is accepted and -00 submitted would be a great time to raise this or make a pull request to get rid of this (IMO silly) restriction.

Great. Sounds good to me!

-- 
Stephen Checkoway

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Nov 2014 23:37:36 -0800

On 27 November 2014 at 08:15, Stephen Checkoway <[email-masked]> wrote:
> Why should we require that the certificate be signed with the signature scheme corresponding to the public key?

If the certificate is selected based on the cipher suite (ECDSA, for
instance), maybe there is a desire to have a uniform chain so that a
client doesn't end up in a situation where they can't verify the chain
(because they don't have RSA, for example).

Now, we do have a lot of implementations that do both, so that's cool.
And we have other ways of advertising what signature methods are
available.  So, maybe this can be loosened to say that all
certificates in the chain MUST be supported by the client (as
determined by X, where X is TBD, mostly because I'm lazy).

---

From: Stephen Checkoway <[email-masked]>
Date: Sat, 29 Nov 2014 15:38:07 -0500

> determined by X, where X is TBD, mostly because I'm lazy).

I think that's reasonable. TLS 1.2 specifies

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.

and it also specifies what the defaults are when that isn't sent. I imagine similar text could be used here.

-- 
Stephen Checkoway

---

From: Martin Thomson <[email-masked]>
Date: Sat, 29 Nov 2014 23:31:05 -0800

[...]
> and it also specifies what the defaults are when that isn't sent. I imagine similar text could be used here.

We can probably do better: https://github.com/tlswg/tls13-spec/issues/99