Subject: [Uta] TLS BCP Review

From: Aaron Zauner <[email-masked]>
Date: Mon, 21 Jul 2014 23:54:09 +0200

Hi *,

I'm in the process of reviewing the BCP currently and do have a couple
of open questions and remarks before submitting a patch. Please excuse
me if some of them have already been asked before on the mailing list,
although I tried to go through most of the mails, I might have missed some.

   * the document on github seems to be out of sync with the document
     that is currently available on the IETF website.

   * I've found some typos, rhetorical flaws w.r.t phrasing throughout
     the document as well as missing information in reasoning parts. I
     would be willing to submit a patch and a related message
     explaining changes (if need be) to this list. is that acceptable?

   * the document effectively states in 1. that TLS 1.3 will obsolete
     this document. UTA should still give recommendations for legacy
     protocols that will be widely deployed on the internet. although
     faster than it used to be - TLS adoption is still very slow.

   * 3.1. states that SSLv2 has "serious security vulnerabilities"
     while this is true, it does not emphasize how broken SSLv2
     actually is. how about changing the wording to "considered to be
     insecure"?

   * as for the deployment of "3%", mentioned in 3.2. - previous
     posters have pointed to the scans by j.vehent and sslpulse/qualys.
     there's also a monthly scan being conducted by h.kario of
     redhat [0].

   * in 3.6 disabling compression is a SHOULD. with the issues currently
     raised by attacks this has to be a MUST in my opinion. and:

   * the document does not mention issues with compression in underlying
     applications when using TLS (e.g. BREACH for HTTP).

   * 4.2: once accepted (and everything looks this way) the draft by DKG
     will obsolete parts of this section [2].

   * currently the document provides for no reasoning as to why no ECDSA
     ciphersuites have been included. while I agree that they should be
     excluded, one should include a sentence or two on the matter. I'm
     not an expert with DSA/DSS so I can just refer to [1] and the
     sources mentioned therein.

   * the document currently does not mention any views for
     standardization bodies and implementors on key pinning (TACK,
     HTKP).

   * the document currently does not mention any views for
     standardization bodies and implementors on certificate
     transparency.

That's all for now, I'm pretty sure I'll come up with more.

Thanks for your time,
Aaron

Sources:
[0] - http://securitypitfalls.wordpress.com
[1] - http://blog.cr.yp.to/20140323-ecdsa.html
[2] - http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Mon, 21 Jul 2014 22:01:21 +0000

- absolutely!
Orit.
________________________________
From: Aaron Zauner<mailto:[email-masked]>
Sent: ‎7/‎21/‎2014 5:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Uta] TLS BCP Review

Hi *,

Thanks for your time,
Aaron

Sources:

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Jul 2014 16:21:26 -0600

>       explaining changes (if need be) to this list. is that acceptable?

With the proviso that substantive issues need to be discussed in a venue 
(such as this list) that is explicitly covered by the IETF Note Well 
statement. As far as I know, github.com is not such a venue.

Peter

---

From: Leif Johansson <[email-masked]>
Date: Tue, 22 Jul 2014 00:47:16 +0200

> statement. As far as I know, github.com is not such a venue.

Absolutely. Please provide suggested text changes to the list!

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 22 Jul 2014 01:20:52 +0200

Hi Peter, Leif:

>> statement. As far as I know, github.com is not such a venue.

I have no issue providing all text changes to the list for discussion.
And I will (not yet done). Just asking to update the document on github
[0], since it has seemed to be used to edit the document in the past.
Versioning is really helpful to track changes in my experience. I hope
you agree.

Aaron

[0]- https://github.com/stpeter/uta

---

From: Leif Johansson <[email-masked]>
Date: Tue, 22 Jul 2014 03:28:24 +0200

On 2014-07-22 01:20, Aaron Zauner wrote:
> Hi Peter, Leif:
> 
> Leif Johansson wrote:
> 
>>> With the proviso that substantive issues need to be discussed
>>> in a venue (such as this list) that is explicitly covered by
>>> the IETF Note Well statement. As far as I know, github.com is
>>> not such a venue.
> 
> I have no issue providing all text changes to the list for
> discussion. And I will (not yet done). Just asking to update the
> document on github [0], since it has seemed to be used to edit the
> document in the past. Versioning is really helpful to track changes
> in my experience. I hope you agree.
> 
> Aaron
> 

No I don't actually.

I understand this might be a convenient way to collaborate on a
document but in the IETF we have a consensus process which relies on
open discussion on mailing lists that comes first.

Please provide your suggestions (and those are *very* welcome) on this
list and we'll see what the rest of the WG thinks.

	Best R
	Leif

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 22 Jul 2014 15:00:17 +0300

Hi Aaron,

Thanks for your review. Please see some responses below. Unfortunately 
your review came too late to include your points in the presentation 
today, feel free to raise them during the discussion.

Best,
	Yaron

>       that is currently available on the IETF website.

Yes, sorry about that. As Leif mentioned, the main discussion needs to 
be on this list.

>       faster than it used to be - TLS adoption is still very slow.

Yes, but the situation will change once 1.3 is out. An implementor will 
need to make a choice whether to spend time/money implementing this BCP, 
or spend time/money moving to 1.3, or maybe deploy 1.3 and use this 
draft to close any remaining issues.

>       actually is. how about changing the wording to "considered to be

OK.

>       there's also a monthly scan being conducted by h.kario of

As you point out, there are several scans (and the numbers vary between 
them...). We might remove the reference altogether.

>       applications when using TLS (e.g. BREACH for HTTP).

Good point, we may need to do that.

>       will obsolete parts of this section [2].

This is a point-in-time document. The DHE draft, as well as fallback 
SCSV, CT and pinning are important changes. When any of them is 
standardized and deployed at scale, some sections here will need to 
change. But we are not there yet.

>       sources mentioned therein.

Because VERY few servers use ECDSA certs.

>       standardization bodies and implementors on key pinning (TACK,

See above.

>       standardization bodies and implementors on certificate

Ditto.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 23 Jul 2014 10:27:52 -0400

Additional points:

- The rationale for the current SSL 3.0 "SHOULD NOT" is that it "did not
support strong cipher suites", just as for TLS 1.0.  The document should be
clear that allowing SSL 3.0 is much worse than allowing TLS 1.0, for a
number of reasons including the following:

1. No support for TLS extensions (meaning, for example, that you can't use
ECDHE).
2. SSL 3.0 CBC padding is unfixably broken (unlike with TLS 1.0, a
complicated constant-time implementation won't save you; see in
https://www.openssl.org/~bodo/tls-cbc.txt).

- The rationale for the TLS 1.0 "SHOULD NOT" includes the following: "TLS
1.0 [...] includes a way to downgrade the connection to SSLv3". This seems
poorly worded, or at least I can't figure out what you really mean. As
written, it doesn't seem to make much sense -- *all* versions of TLS by
design do support protocol negotiation down to SSL 3.0 (which, of course,
is no issue for implementations that don't support SSL 3.0 at all).

- Given that (SSL 3.0 and) TLS 1.0 is still allowed (even with a "SHOULD
NOT"), the specification should describe 1 : n-1 record splitting (the
improved-interoperability tweak of my original empty-record approach:
instead of sending an empty plaintext record first to avoid predictable CBC
IVs, send a single-byte plaintext record first), and make it RECOMMENDED
for CBC ciphersuites in SSL 3.0/TLS 1.0.

This is really more about TLS per se than about using TLS in applications,
but in practice the BCP document is probably the best place to document
this (and it seems within the WG charter, and in particular covered by this
BCP's goal to provide "recommendations for improving the security of [...]
implementations").

Bodo

---

From: Leif Johansson <[email-masked]>
Date: Wed, 23 Jul 2014 16:36:35 +0200

On 2014-07-23 16:27, Bodo Moeller wrote:
> support strong cipher suites", just as for TLS 1.0.  The document should
> be clear that allowing SSL 3.0 is much worse than allowing TLS 1.0, for
> a number of reasons including the following:

Joe Hildebrand volunteered to propose text related to this.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 29 Jul 2014 23:52:24 +0200

Dear UTA contributors,

Ad git/github: Duly noted.
Thanks for your patience and pointing this out.

Sorry for my delayed reply to this thread; I'm extremely busy at the
moment - as I'm sure most of you are. As promised a few remarks on typos
phrasing/wording and clarification which I have not addressed in my
previous e-mail to this list.

1. (Introduction):
- [...] and their prevalence in implementatios at the time of writing.
                                ^^^^^^^^^^^^^^
                                    typo

- Individual specifications may have stricter requirements related to
one or more aspects of the protocol, and based on their particular
circumstances.

should we rephrase that? e.g. "based on their particular security
requirements".

- [...] When that is the case, implementers MUST adhere to those
                               ^^^^^^^^^^^^
                                  typo

3.2 (Fallback to SSL):
In my opinion this should be a MUST. Clients MUST not fall back to
SSLv3. This is a BCP, no reason to have this security issue stated as
SHOULD NOT. I'm aware that this might break compatibility with legacy
software.

3.4 (Cipher Suites):
- Rationale: Although these cipher suites are not actively subject to
breakage, their useful life is short enough that stronger cipher suites
are desirable.

maybe change the wording of 'their useful life' to e.g. 'their lifespan'.

- Rationale: Although the useful life of such cipher suites is unknown,
it is probably at least several years [...]

I'd also go with 'lifespan' there.

- Given the foregoing considerations [...]

foregone instead of foregoing(?).

3.5. (Public Key Length):
- The most common workaround for these systems is to prefer the "ECDHE"
family of cipher suites instead of the "DH" family, then use longer keys.

I simply do not understand the sentence. Which keys are referred to exactly?

- [...] and might be sufficient for at least the next 10 years.

I'd simply remove the estimate on the lifespan of 2k keys. No one can
say for sure and there's really no reason to estimate.

- Note: The foregoing recommendations are preliminary [...]

foregone instead of foregoing(?).

3.7 (Session resumption):
- ticket keys MUST be changed regularly, e.g. once every week, so as not
to negate the effect of forward secrecy.

That's a bit of nitpicking but in this sentence it's "effect of forward
secrecy" in the next sentence "benefits of forward secrecy" - I'd go for
the latter in both sentences.

4.1 (Cipher Suite Negotiation Details):
- Servers SHOULD prefer this cipher suite (or a similar but stronger
one) whenever it is proposed, even if it is not the first proposal.

"a similar but stronger one" is very vague. I'd either remove it or give
examples of possible cipher suites to be used.

4.2 (Alternative Cipher suites):
- [...] moreover, 1024 bits DH parameters are generally considered
insufficient at this time. [...]

I'd change "bits" to "bit" - "1024 bit DH parameters".

6.2 (Forward Secrecy):
- Should the attacker be able to obtain these long-term keys at some
point later in the future [...]

I'd change this to "at some point later in time".

- Unfortunately, many TLS/DTLS cipher suites were defined that do not
enable PFS, e.g.  TLS_RSA_WITH_AES_256_CBC_SHA256. [...]

Would rephrase as "that do not feature PFS". That's not optional in the
case of RSA key transport, it's just not possible the way it's spec'd in
TLS (there is a paper on ephemeral RSA, but I've never gotten around to
read it).

Thanks,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 30 Jul 2014 00:03:10 +0200

> - [...] When that is the case, implementers MUST adhere to those

Misread that's actually not a typo.

Aaron