Subject: [Uta] draft-ietf-uta-tls-bcp Feedback

From: Tom Ritter <[email-masked]>
Date: Fri, 23 May 2014 07:42:23 -0400

I've read -00[0], and had the following feedback.

1) Is the intent merely to document attacks, or provide Best Current
Practices?  For instance, the BEAST attack does not actually say
explicitly "Servers SHOULD offer TLS 1.1 and above to mitigate the
BEAST attacks."

2) Is there a reason that many attacks on TLS are omitted?  I don't
consider this a comprehensive document for deploying TLS on a
webserver.  In particular, I would have expected information on
securing deploying a configuration that also avoids:
 - The ECC algorithm confusion attack
 - Triple Handshake
 - Secure Renegotiation
 - Browser-based protocol downgrade to the extent it can be
 - TLS-based Denial of Service to the extent it can be
 - TLS stripping (And using HSTS to prevent)
 - Certificate Forgeries, and using PKP to mitigate

3) On the flip side, I actually consider Lucky 13 OUT of scope. Lucky
13 and other implementation errors[1] are the concern of people
_implementing_ TLS.  People deploying TLS should be certain they do
not choose an implementation of TLS that is vulnerable to these
attacks, and it's worthwhile providing a recommendation on that.  I'm
not certain it's worth trying to enumerate patched versions of
libraries, because vendors backport patches, but a general statement
would be appropriate IMO. If implementation concerns are in scope, we
have a number of them also omitted.

4) Then again, I do consider it a 'Best Current Practice' not to
deploy a server that does not meet the TLS spec. In particular, the
deployment of servers that are intolerant of long handshake messages,
ciphersuites or extensions they don't recognize, or that hang on newer
versions of TLS make life very difficult for us.

5) Is DTLS in or out of scope? Presumably a number of TLS options are
also out of scope: PSK, OOB, SRP, Client Certs, OpenPGP, Kerberos....

6) I consider providing OCSP information, stapled in the response, to
be a 'Best Current Practice'.

7) There is nothing about ciphersuite selection.  Like #6, I consider
using PFS a 'Best Current Practice'. But at the same time, ECDHE is
way better than 1024-bit DHE. (Which is also not mentioned.)

FWIW, I think http://armoredbarista.blogspot.com/2013/01/a-brief-chronology-of-ssltls-attacks.html
is an excellent resource worth referencing as well.

-tom

[0] http://tools.ietf.org/html/draft-ietf-uta-tls-attacks-00
[1] Implementation Concerns: Timing attacks that disclose private keys
(the Bleichenbacher attack, targeting square-and-multiply, the
equivalent for ECC, etc), Lucky 13, Heartbleed, others

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 23 May 2014 16:00:19 +0300

Hi Tom,

Thank you for your comments. Can you please read (or skim) the companion 
document [1], and resend your comments within the context of both documents.

Thanks,
	Yaron

[1] http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00

On 05/23/2014 02:42 PM, Tom Ritter wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Tom Ritter <[email-masked]>
Date: Fri, 23 May 2014 09:27:22 -0400

Oh brother, sorry about not seeing that, I will re-read and resend.

-tom

On 23 May 2014 09:00, Yaron Sheffer <[email-masked]> wrote:
>> FWIW, I think
>> http://armoredbarista.blogspot.com/2013/01/a-brief-chronology-of-ssltls-attacks.html

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 26 May 2014 11:18:08 +0200

I had suggested two additions, for which there has been no decision yet. I would like to see more discussion on these.

1. Usage of Extension SignatureAlgorithms by client to signal minimum required hash functions. Ralph's feedback on that
suggestion was that we need more data on the extend of SHA-2 support by current and future implementations. But I think
it's not just about migrating to SHA-2 it could also be useful to prevent usage of MD5.

2. When re-using keys for ECDHE (which is the default behavior in some implementations, e.g. OpenSSL) or when using
non-ephemeral ECDH, the validity of the received public DH-key should be checked to avoid non-group attacks. That is, it
should be checked that the received point P is on the curve (unless point compression was used). Small subgroup checks
could even be recommended for classical DH. Something in the spirit of RFC 6989.

-- 
Johannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 26 May 2014 16:37:08 +0300

On Mon, May 26, 2014 at 11:18:08AM +0200, Johannes Merkle wrote:
> 
> 2. When re-using keys for ECDHE (which is the default behavior in some
> implementations, e.g. OpenSSL) or when using non-ephemeral ECDH, the
> validity of the received public DH-key should be checked to avoid non-
> group attacks. That is, it should be checked that the received point P
> is on the curve (unless point compression was used). Small subgroup
> checks could even be recommended for classical DH. Something in the
> spirit of RFC 6989.

Even if point compression is used, one should check that the square
root exists, unless both:

1) The invalid compressed points are guaranteed to be on the twist[1] AND
2) The curve is twist-secure (NIST and Brainpool aren't[2][3]).

As for small subgroups, unless protocol properly hashes the public keys
(and currently TLS does not), one should check for those[4] as those can
cause trouble[5].

[1] E.g.:
- Using Montgomery X-only
- Using Weierstrass with usual square root mod 4k+3

[2] In fact, both have at least one very twist-insecure curve.

[3] Most of twist-secure curves seem to also be designed for 
Montgomery X-only.

[4] This checking is not really feasible for DH with arbitrary primes.
(if one assumed SG, this could be done (check for -1, 0 or 1), but such
check is wrong for non-SG primes).

[5] Triple Handshake attack with DH handshakes anyone?

-Ilari

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 26 May 2014 16:34:55 +0200

> 2) The curve is twist-secure (NIST and Brainpool aren't[2][3]).
I assumed that the points are uncompressed (which includes taking the square roots) but, yes, an implementation could
use an x-coordinate latter. In this special case your observations apply.

> [3] Most of twist-secure curves seem to also be designed for 
I guess this is because X-only for Weierstrass is expensive, thus either uncompressed points are transmitted, in which
case checking the validity of the point is cheap, or points are uncompressed, which implicitly verifies the validity.

Anyway, I'm not sure if non-Weierstras in the scope for the draft.

> check is wrong for non-SG primes).
If an implementation supports only a limited set of primes, for each prime the required check ("co-factor" (p-1)/q could
be stored along with the primes. Of course, for q << p the check is expensive, but necessary though.

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 27 May 2014 10:13:18 +0200

> I assumed that the points are uncompressed (which includes taking the square roots) 

This was ambiguous, I mean: I assumed that the points are being de-compressed before DH operation.

-- 
Johannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 27 May 2014 13:50:55 +0300

On Mon, May 26, 2014 at 04:34:55PM +0200, Johannes Merkle wrote:

> I guess this is because X-only for Weierstrass is expensive,
> thus either uncompressed points are transmitted, in which
> case checking the validity of the point is cheap, or points
> are uncompressed, which implicitly verifies the validity.

Yes, X-only for Weierstrass is expensive.

And the point was: Even with point compression, in general you
need to check if the square root actually exists (which has cost
of 1 square mod p).

Yes, there are special cases where you don't have to check, e.g, all of:
- Weierstrass.
- p=4k+3, and using the usual a^(p+1)/4 mod p square root.
- The curve is twist-secure.

And breaking any of those can lead into trouble:
- With non-weierstrass forms, invalid points can lead to who knows what.
- One of the p=8k+5 square roots yields 0 on blind application to QNR
  about half of the time
- One can solve ecdlog in twist of Brainpool256t1 pretty easily.

-Ilari

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 27 May 2014 13:18:06 +0200

> Yes, there are special cases where you don't have to check, e.g, all of:

I'm really not sure if non-Weierstrass is worth considering right now in a
TLS-oriented document, given that only Weierstrass can be used with TLS currently.

Also, it seems to me that it will be difficult, and maybe confusing* to come up
with a single set of recommendations that applies uniformly to all forms of
curves. So maybe even in the long term it's better to focus on reduced
Weierstrass now, and expand the document with a distinct set of recommendations
later for other kind of curves.

Manuel.

* For example, a lot of people seem to think that if you use a twist-secure
curve, even with a protocol like TLS ECDH with uncompressed point format (and
reduced Weierstrass) you don't need to validate the received point, which is
plain wrong and dangerous. Twist security is only relevant (from a point
validation perspective) for x-only schemes. So from a "pedagogic" perspective
it's probably interesting to clearly distinguish between different kinds of
curves/protocols.

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 27 May 2014 13:24:55 +0200

> Yes, X-only for Weierstrass is expensive.

And for this reason, you typically de-compress points on Weierstrass curves before further processing.
> need to check if the square root actually exists (which has cost

When decompressing, you _compute_ the square root. Thus, you get the check (if  the square root actually exists) for free.

> - One can solve ecdlog in twist of Brainpool256t1 pretty easily.

All of this is irrelevant as long as you do one of the following:
- You transmit compressed points but decompress them before further processing (using arithmetic with both coordinates).
- You transmit uncompressed points and check the curve equation, which is very cheap.

Twist security is only important, if you use do one of the following:
- You transmit compressed points and use X-coordinate arithmetic. this is not very efficient for Weierstrass curves.
- You transmit uncompressed points and fail to verify the curve equation. Since this check is so simple and cheap, this
would be careless.

I consider the emphasis on twist security more as marketing for certain curves than as a serious argument.

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 27 May 2014 13:26:22 +0200

> TLS-oriented document, given that only Weierstrass can be used with TLS currently.

+1

> later for other kind of curves.

+1

> it's probably interesting to clearly distinguish between different kinds of

+1

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 27 May 2014 13:29:47 +0200

small correction, even strengthening my line of argument.

> Twist security is only important, if you use do one of the following:
[...]
> - You transmit uncompressed points and fail to verify the curve equation. Since this check is so simple and cheap, this
And, actually, in this case, "twist security" doesn't help you.

-- 
Johannes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 May 2014 12:55:16 +0100

>> > later for other kind of curves.

Same here. The TLS WG are working with the CFRG on this topic
so I don't see a good reason to go beyond what's supported in
TLS1.2 or earlier.

S.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 27 May 2014 06:47:35 -0700

> it's not just about migrating to SHA-2 it could also be useful to prevent usage of MD5.

MD5 in TLS 1.2 should not be used anymore. There are some real clever
tricks that can be played. We need a secure hash every time. However,
the ciphersuite, not the SignatureAlgorithms, determines which hash to
use. If we are talking about certificates, then I think this is the
correct thing, but I don't know.

(I don't understand why MD5 was still included as an option in any RFC
after 2004)

> could even be recommended for classical DH. Something in the spirit of RFC 6989.

This is a problem for ephemeral DH as well due to Triple Handshake. We
might as well throw this in: it doesn't hurt. However, if you aren't
doing it already, odds are you aren't capable of implementing TLS
correctly, because you don't understand the issues associated with
implementing cryptography.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 27 May 2014 16:17:45 +0200

> tricks that can be played. We need a secure hash every time. However,

I absolutely agree.

> correct thing, but I don't know.
the Signature Algorithm extension is neither about HMAC nor about certificates, its about signatures on key exchange
messages, in case of PFS the signature of the ephemeral DH keys.

+1

> implementing cryptography.

True, but I'm not sure if we can assume that this is not the case.

-- 
Johannes

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 27 May 2014 22:47:14 +0300

> implementing cryptography.

We should not assume people "understand" anything. If there are 
cryptographic pitfalls, it is our job to spell them out. Which is why we 
published RFC 6989 to close exactly this vulnerability (and why it was 
published relatively quickly - 7 months from -00 to RFC). I'm still 
wondering why an equivalent RFC for TLS has not been published yet.

Thanks,
	Yaron

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 May 2014 12:46:14 +0200

We're getting lots of good feedback on this document which is fantastic
but I urge everyone to focus on stuff that is current, practical and
actionable advise.

	Cheers Leif