Subject: [TLS] Review of draft-ietf-tls-rfc4492bis-15

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Mar 2017 07:44:51 -0700

Sorry for the late review of this document. I just got to it this
week. I'm sending this as comments rather than issues/PR due to
how late it is in the proces.

I have two high-level comments:

- This document seems to still have a bunch of material about
  static DH (especially static DH authentication). I thought we
  had agreed to remove that.

- You are inconsistent about using capital 2119 language
  and I expect you want to be consistent.

DETAILED
S 2.
   All of these key exchange algorithms provide forward secrecy.

This is actually only true if each side generates fresh ephemerals
which does not seem to be required by the spec.

Do we really want to promote ECDH_anon to standards track?

Nit: you want a line break between the last line of Figure 1
and the legend explaining the message types.

S 2.3.
   This specification does not impose restrictions on signature schemes
   used anywhere in the certificate chain.  The previous version of this
   document required the signatures to match, but this restriction,
   originating in previous TLS versions is lifted here as it had been in
   RFC 5246.

This section is about ECDH_anon, so maybe this text belongs in S 2.1 or
2.2.?

S 3.
You have a bunch of lower case 2119 key words here.

   If these conditions are not met, the client should send a client
   Certificate message containing no certificates.  In this case, the
   ClientKeyExchange should be sent as described in Section 2, and the
   CertificateVerify should not be sent.  If the server requires client
   authentication, it may respond with a fatal handshake failure alert.

Actually, this "should not be sent" is a MUST NOT, because if you send
an empty certificate, you're forbidden to send CertificateVerify.

S 4.
   choice of curves and compression techniques specified by the client.

s/compression techniques/point formats/?

S 5.1.1.
Do you want to rename elliptic_curve_list to named_curve_list?

S 5.1.2.

   Three point formats were included in the definition of ECPointFormat
   above.  This specification deprecates all but the uncompressed point
   format.  Implementations of this document MUST support the
   uncompressed format for all of their supported curves, and MUST NOT
   support other formats for curves defined in this specification.  For
   backwards compatibility purposes, the point format list extension
   MUST still be included, and contain exactly one value: the
   uncompressed point format (0).

This implies that you have to send supported point formats, but in
S 5.1, this is a SHOULD. I believe what you may be trying to say
here is that if you send the extension, it must be non-empty.

Also, maybe I'm missing it, but where do you say that the default
is to assume that the other side supports uncompressed if it doesn't
do so. This is a backwards compat issue.

S 5.3.
You don't define what "authorized for signatures" is, but I suspect
you're talking about KeyUsage, etc.? If so, don't you need to say
this about ECDHE_ECDSA as well.

S 5.4.
   The value named_curve indicates that a named curve is used.  This
   option SHOULD be used when applicable.

When would you not?

S 5.5.
This defines:
             rsa_fixed_ecdh(65),
             ecdsa_fixed_ecdh(66),

But the specification doesn't actually support this. Note that
the fixed_DH authentication mechanism are specified as having
the client's cert be on the same curve as the long-term
ECDH key, but you've deprecated those KE mechanisms, so as far
as I can tell, static DH auth is impossible

Also:
1. Why isn't the ECDSA cert required to be signing capable.
2. You probably should standardize on ECDSA_sign or ecdsa_sign.

S 5.7.
More text about static DH auth. Also "implicit" can probably go away.

   The client selects an ephemeral ECDH public key corresponding to the
   parameters it received from the server according to the ECKAS-DH1
   scheme from IEEE 1363.  It conveys this information to the client in
   the ClientKeyExchange message using the format defined above.

I don't understand what this means.

S 5.8.
   This message is sent when the client sends a client certificate
   containing a public key usable for digital signatures, e.g., when the
   client is authenticated using the ECDSA_sign mechanism.

This is the only way that things can work now.

S 5.1.1.
   Failing to
   do so allows attackers to gain information about the private key, to
   the point that they may recover the entire private key in a few
   requests, if that key is not really ephemeral.

To the best of my knowledge, this only applies to DH, not signature
verification.

S 6.
Do we really want to promote NULL and 3DES to ST?

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2017 15:07:10 +0000

Thanks Eric,

Let's see what folks say in response to this and I can post
anything not immediately resolved as a DISCUSS ballot. We
can then process that in the coming week or two, and you
can take over the DISCUSS for whatever's not resolved by
the swap-over in Chicago. Or if someone else wants to
make some or all of Eric's comments a DISCUSS that'd work
too, but I'm fine with taking it.

Cheers,
S.

On 15/03/17 14:44, Eric Rescorla wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Mar 2017 08:21:48 -0700

FWIW, there's a lot here, but I think it's all essentially editorial, so it
shouldn't
be that hard to clean up.

-Ekr

---

From: David Benjamin <[email-masked]>
Date: Wed, 15 Mar 2017 17:20:33 +0000

If there's to be a respin anyway, I have another small editorial comment:
https://github.com/tlswg/rfc4492bis/issues/36

On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla <[email-masked]> wrote:

> FWIW, there's a lot here, but I think it's all essentially editorial, so
> it shouldn't
> On Wed, Mar 15, 2017 at 8:07 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>
> Thanks Eric,
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Mar 2017 20:44:59 +0200

There is (going to be a re-spin). There already is a PR there.

If you can make a PR to solve your issue, that would be great.

> On 15 Mar 2017, at 19:20, David Benjamin <[email-masked]> wrote:
> 
> https://github.com/tlswg/rfc4492bis/issues/36 <https://github.com/tlswg/rfc4492bis/issues/36>
> 
> On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> FWIW, there's a lot here, but I think it's all essentially editorial, so it shouldn't
> On Wed, Mar 15, 2017 at 8:07 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Thanks Eric,
> 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> >
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: David Benjamin <[email-masked]>
Date: Wed, 15 Mar 2017 19:32:16 +0000

How's this look? https://github.com/tlswg/rfc4492bis/pull/37

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Mar 2017 21:38:52 +0200

LGTM

> On 15 Mar 2017, at 21:32, David Benjamin <[email-masked]> wrote:
> 
> How's this look? https://github.com/tlswg/rfc4492bis/pull/37 <https://github.com/tlswg/rfc4492bis/pull/37>
> 
> On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>> On 15 Mar 2017, at 19:20, David Benjamin <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Mar 2017 09:44:28 +0200

Hi

This pull request addresses most of these comments.   https://github.com/tlswg/rfc4492bis/pull/39 <https://github.com/tlswg/rfc4492bis/pull/39>  There is some discussion on that PR

Some that are not addressed, I’ve answered below.  Let me know if you want me to merge and submit.

Yoav

On 15 Mar 2017, at 16:44, Eric Rescorla <[email-masked]> wrote

> Do we really want to promote ECDH_anon to standards track?

It’s the EC version of DH_anon, which is on the standards-track. I don’t expect to convert the web to use DH_anon, but its security is very much like what you get with a self-issued certificate, with many less bytes on the wire. Anyway, I don’t think this effort is the place to deprecate what is a pretty good mechanism for opportunistic security if nothing else.

> This section is about ECDH_anon, so maybe this text belongs in S 2.1 or 2.2.?
> 
> 
> S 3.

Since we’re deprecating all point formats other than uncompressed, I just removed the “and” and left it as choice of curves.

> Do you want to rename elliptic_curve_list to named_curve_list?

Yes

> I don't understand what this means.

Yeah, neither do I.  I reworded it.

> Do we really want to promote NULL and 3DES to ST?

The place to remove 3DES is TLS 1.3. The alternative is to either deprecate it for TLS 1.2 or to not obsolete 4492.

NULL is a little more nuanced, but I think the same argument applies.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Mar 2017 09:04:32 +0000

Thanks Yoav,

> want me to merge and submit.

I'd say give it a chance for one round of comments from Eric
and/or others, and then submit. Or, submit before you head
for an airport on your way to Chicago if that happens first.
If we're left with an RFC editor note being needed, that's
ok so long as it's simple enough.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Mar 2017 05:02:25 -0700

On Tue, Mar 21, 2017 at 12:44 AM, Yoav Nir <[email-masked]> wrote:

> Hi
>
> This pull request addresses most of these comments.
> https://github.com/tlswg/rfc4492bis/pull/39  There is some discussion on
> that PR
>
> It’s the EC version of DH_anon, which is on the standards-track. I don’t
> expect to convert the web to use DH_anon, but its security is very much
> like what you get with a self-issued certificate, with many less bytes on
> the wire.
>

Well, assuming you don't do TOFU.

, neither do I.  I reworded it.
> The place to remove 3DES is TLS 1.3.
>

Well, we certainly did that, but why?

> The alternative is to either deprecate it for TLS 1.2
>

This seems like it might be reasonable at this point.

> or to not obsolete 4492. NULL is a little more nuanced, but I think the
> same argument applies.
>

What we probably should actually do is make this depend on the IANA draft
and then mark
these Not Recommended.

-Ekr

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Mar 2017 08:28:30 -0400

> On Mar 21, 2017, at 08:02, Eric Rescorla <[email-masked]> wrote:
> 
> What we probably should actually do is make this depend on the IANA draft and then mark
> these Not Recommended.

That is an option as none of the 3DES suites are marked as Recommended in the IANA draft.

spt

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Mar 2017 20:54:22 +0200

> On 21 Mar 2017, at 14:28, Sean Turner <[email-masked]> wrote:
> 
> 

Which to me sounds like an argument for leaving the text as is.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 23 Mar 2017 18:38:12 +0200

> On 21 Mar 2017, at 11:04, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Thanks Yoav,
> 

OK, so how is that technically done?  The Upload page is defunct until Monday.

Yoav

---

From: joel jaeggli <[email-masked]>
Date: Thu, 23 Mar 2017 10:03:22 -0700

> OK, so how is that technically done?  The Upload page is defunct until Monday.

send to [email-masked] with the request for posting, cc the
responsible ad and they will approve.