Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis

From: Sean Turner <[email-masked]>
Date: Fri, 18 Nov 2016 15:55:39 -0800

All,

This is a working group last call for the “4492bis to Standards Track" draft available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please review the document and send your comments to the list by 9 December 2016.  

Note that we are particularly interesting in the issue Yoav raises in the following message:
https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk

Thanks,
J&S

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Nov 2016 23:31:18 +0900

I have not read the document in full (but still noticed a typo in the 
paragraph we're discussing), so I will not comment on its readiness.

Regarding signature context: I don't understand the CFRG recommendation 
that Yoav is citing. IMO we should include a context string wherever we 
can, to reduce the number of possible cross-protocol (or cross-signature 
scheme) attacks. As far as I know context strings do not cost anything 
and can only improve the protocol's security.

Maybe one day we will only have signatures deployed that support 
context, but if we don't add the context string now we will never get 
there. We are not going to revise TLS just to add a context string to EdDSA.

Thanks,
	Yaron

On 19/11/16 08:55, Sean Turner wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 20 Nov 2016 04:21:07 +0000

In CURDLE this week, we had consensus (to be confirmed on the list, of course) that
	Signature contexts were created in the TLS arena, we all thought we needed them in other areas, and we don't, therefore all CURDLE documents for those other areas will specify a zero-length context.

FWIW.

I agree with Yoav's message, for the reasons he states.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Friday, November 18, 2016 6:56 PM
> To: <[email-masked]>
> Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis
> 
> All,
> 
> This is a working group last call for the “4492bis to Standards Track" draft
> available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please
> review the document and send your comments to the list by 9 December
> 2016.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 20 Nov 2016 23:09:37 +0900

Hi Rich,

I am confused by your response.

For those who missed CURDLE, could you please briefly explain why we 
don't need signature context in non-TLS areas.

And even if this is the case, the current thread is about TLS! So why 
are we now saying that contexts are not needed even for TLS?

Thanks,
	Yaron

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 20 Nov 2016 15:33:49 +0000

> For those who missed CURDLE, could you please briefly explain why we don't
> need signature context in non-TLS areas.

The one place we were concerned about attacks was in pre-hash signatures, and we made those a MUST NOT.  And yes, your'e right, it's not relevant to TLS.

> So why are we now saying that contexts are not needed even for TLS?

I think because the key schedule changed.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Nov 2016 06:31:05 +0200

So the key schedule changed and therefore we think cross-version attacks 
are impossible. Have we also analyzed other protocols to ensure that 
cross protocol attacks, e.g. with SSH or IPsec, are out of the question?

Put differently, algorithm designers gave us a cheap, easy to use tool 
to avoid a class of potential attacks. Why are we insisting on not using it?

Thanks,
	Yaron

---

From: John Mattsson <[email-masked]>
Date: Wed, 23 Nov 2016 10:15:06 +0000

I have not read the processing parts in detail. Here are comments on the
first and last sections of the document.

Cheers,
John

- Somewhere
I suggest adding the following sentence from TLS 1.3:
"Applications SHOULD also enforce minimum and maximum key sizes.  For
example, certification paths containing keys or signatures weaker than
2048-bit RSA or 224-bit ECC are not appropriate for secure applications."

This is as true for TLS 1.0, 1.1, and 1.2 as for TLS 1.3

- Section 1
"Compared to currently prevalent cryptosystems such as RSA, ECC offers"

I think this should be updated, ECDHE is already very well-spread.

- Section 1
"This is illustrated in the following table, based on [Lenstra_Verheul],
which gives approximate comparable key sizes for symmetric- and
asymmetric-key cryptosystems based on the best-known algorithms for
attacking them."

The key sizes for DH/DSA/RSA does not seem to be based on the
Lenstra-Verheuls equations which gives much higher key sizes for
DH/DSA/RSA.

The DH/DSA/RSA key sizes seem to be based on NIST recommendations. I
suggest either:

A) Fully based the table on NIST recommendation, which means keeping
DH/DSA/RSA as is but simplifying ECC to 2 * Symmetric.
B) Update the DH/DSA/RSA key sizes based on state-of-the-art. But then I
would say that this is not [Lenstra_Verheul], but rather [RFC3766],
[Lenstra 2004], [ECRYPT 2012]. I think these three all use the same
equation.
C) Just remove DH/DSA/RSA as the draft is about ECC.

- Section 2
"However, the computational cost incurred by a server is higher for
ECDHE_RSA than for the traditional RSA key exchange, which does not
provide forward secrecy."

True, but I think it gives the wrong impression. I think the additional
cost is negligible. I don't have any TLS benchmarks but for i5-6600,
bench.cr.yp.to gives:

ronald3072 decrypt  8776864 cycles

ronald3072 sign     8781842 cycles
curve25519 keygen    163200 cycles
curve25519 compute   165816 cycles

That's only 3.8% overhead for crypto, and much less if calculated for the
whole handshake. I suggest removing the sentence, or writing that the
additional server cost for forward secrecy is negligible and well worth it.

- Section 6
"TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256"

Should this be "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"?
I don't think the document should recommend support of cipher suites
without forward secrecy.

- Section 7
"documemts" -> "documents"

- Section 7
"NEED TO ADD A PARAGRAPH HERE ABOUT WHY X25519/X448 ARE PREFERRABLE TO
NIST CURVES."

I suggest using the excellent explanation in RFC7748 as a basis.
Suggestion:

"Modern curves such X25519 and X448 [RFC7748] are preferable as they lend
themselves to constant-time implementation and an exception-free scalar
multiplication that is resistant to a wide range of side-channel attacks,
including timing and cache attacks. For more information see [SafeCurves]."

[SafeCurves]  https://safecurves.cr.yp.to/

- Section 7
"Substantial additional information on elliptic curve choice can be found
in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]".

I think it is better to refer people to [SafeCurves].

- Section 7
The paragraph about structure gives the impression that "F_p with p
random" is the optimal choice. I think this should be expanded with more
information explaining why we do not recommend random curves.

1) That random curves are hard to protect against side-channel attacks.
2) Non-random curves are significantly faster, so that for a fixed number
of operations, p can be much larger for non-random curves.

---

From: John Mattsson <[email-masked]>
Date: Wed, 23 Nov 2016 10:22:38 +0000

>to avoid a class of potential attacks. Why are we insisting on not using

Unless someone points out any major disadvantages with using a context, I
agree with Yaron.

>> The one place we were concerned about attacks was in pre-hash
>>signatures, and we made those a MUST NOT.  And yes, your'e right, it's
>>not relevant to TLS.
>>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Nov 2016 15:32:52 +0200

Hi, John

Thanks for the review.  See my responses below:

> On 23 Nov 2016, at 12:15, John Mattsson <[email-masked]> wrote:
> 

I can add a sentence like that, but the draft does even better: It deprecates all curves smaller than 256-bit ECC. Now it’s true that this draft is about TLS, not PKIX, so this only forces the public key in the EE certificate to be at least 256-bit, but in general CA keys are no weaker than EE keys. I will add such a sentence , though.

> I think this should be updated, ECDHE is already very well-spread.

Yes, this is copied from 4492.  How about: “Compared to previous cryptosystems such as RSA and finite-field diffie-hellman, ECC offers…"

> C) Just remove DH/DSA/RSA as the draft is about ECC.

I’m inclined to get rid of this table and all the text from “This is illustrated…” entirely. ECC is by now in wide use. We don’t need to “sell” it any more. so unless someone would like to make a PR with better text, I will just get rid of it.

> additional server cost for forward secrecy is negligible and well worth it.

Makes sense. How about:
OLD:
   However, the computational cost incurred by a server is higher
NEW:
   The computational cost incurred by a server is marginally higher
> I don't think the document should recommend support of cipher suites

Definitely. It would be a very poor show to deprecate this ciphersuite (along with all other ECDH_RSA and ECDH_ECDSA ciphersuites), declare that all ciphersuites have forward secrecy, and then make this (sort of ) MTI.  Will fix.

> 
> - Section 7
> "documemts" -> “documents"

OK

> [SafeCurves]  https://safecurves.cr.yp.to/

Cool.  Will add.

> I think it is better to refer people to [SafeCurves].

In addition, OK. I don’t think we should remove everything else, especially when unlike 7748 this draft is specifying NIST curves, and the choice for them was not in [SafeCurves]

> of operations, p can be much larger for non-random curves.

I think the explanation above covers this, but we may want to mention that even the NIST curves are faster than random.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Nov 2016 15:39:38 +0200

> On 23 Nov 2016, at 12:22, John Mattsson <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> 

I’m not even sure what my position is on this. Specifying the use of a context here goes against the recommendation in the CFRG draft:

      Contexts SHOULD NOT be used opportunistically, as that kind of use
      is very error-prone.  If contexts are used, one SHOULD require all
      signature schemes available for use in that purpose support
      contexts.

If someone knows why this recommendation was made, that would be great.

However, three working groups are currently faced with this same decision: TLS, IPsecME and Curdle. I think it would be weird if these three groups came up with different answers to what is essentially the same question. At least for TLS and IKE there are no operational differences either. 

So Curdle, I’ve been told, is leaning towards empty context for Ed448 and no OID for Ed25519ctx. IPsecME has a thread similar to this one (with similar participants…)

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 23 Nov 2016 17:50:47 +0200

On Wed, Nov 23, 2016 at 03:39:38PM +0200, Yoav Nir wrote:
> I’m not even sure what my position is on this. Specifying the use of a
> context here goes against the recommendation in the CFRG draft:
> 

Basically, then those other methods would be a weak point for attack.

Then there's the serious deployment problems with contexts, as those
don't fit into any standard notion of signature various libraries have.

-Ilari

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 23 Nov 2016 18:01:44 +0200

> Basically, then those other methods would be a weak point for attack.

But we are trying to migrate away from the old methods, into the new 
methods. The fewer servers use the old methods, the better off we are, 
right? So we expect the attack surface to gradually be reduced over the 
coming years.

> don't fit into any standard notion of signature various libraries have.

These are new algorithms that are still not widely deployed. The fact 
that several open source libraries (still) don't support a certain 
function parameter is not a very strong reason not to require it.

Thanks,
	Yaron

---

From: Sean Turner <[email-masked]>
Date: Wed, 23 Nov 2016 12:54:46 -0500

> I’m inclined to get rid of this table and all the text from “This is illustrated…” entirely. ECC is by now in wide use. We don’t need to “sell” it any more. so unless someone would like to make a P…

You could be more draconian and start the draft with the paragraph:

  This document describes additions to TLS to support ECC ….

Because you’re right we don’t really need to do much selling here.

spt