Subject: Re: [Uta] TLS BCP 01 Draft

From: Yaron Sheffer <[email-masked]>
Date: Sun, 06 Jul 2014 22:09:14 +0300

Hi Trevor, thanks for your review. Please see my comments in line.

On 06/30/2014 09:11 PM, Trevor Freeman wrote:
> General Comments.
>
> There are still no definition on what constitutes best protection
> against monitoring i.e. what offers best, adequate or minimal protection
> against monitoring.  Give one of the goal is to move the internet to
> better protect against this kind of activity, we need to clarify which
> actions in this draft best enable that goal and not just providing basic
> interoperability.

These are lofty goals indeed. But the draft's goal is not to define 
"best protection against monitoring", let alone to define 3 levels of 
such protection. It is simply to remediate issues with the way TLS is 
currently deployed. I don't think we "just provide basic 
interoperability", I believe we provide strictly better security, within 
the constraints of current technology and interoperability.

>
> Section 3.4 and 4.1 needs to be consolidated as there is a lot of
> overlap between the two sections.

I am not sure about the overlap, and would appreciate specific points.

>
> I think it is good to provide rational behind the recommendations for
> various cipher sites, it leaves the reader with some interpretation
> between that and the actual cipher suites. It would be better to
> actually list the cipher suites in question to remove any scope for
> misinterpretation.

The first part of Sec. 3.4 provides more than half a page of rationale 
for the cipher suite selection.

>
> Also support for the SNI is missing from the draft. This is a mandatory
> for any application interacting with a service.

Quoting my own earlier response to you (my mail of June 21): "I'm all in 
favor of using SNI. But as far as the draft goes, I believe this is an 
operational decision, and so we should not include such a recommendation."

>
> Specific comments.
>
> Section 3.2 still treats SSL 3.0 differently to TLS 1.0. Why is it ok to
> fall back to TLS 1.0 but not SSL 3.0 if both offer the same security?

This is a good question. I believe the answer is, because much of the 
server population still only supports TLS 1.0, and if we recommend 
otherwise, the recommendation will be ignored for (justified) 
interoperability reasons. But I may be wrong about the prevalence of 
such servers.

>
> Section 3.4.
>
> bullet 3.  Implementations MUST NOT negotiate cipher suites with an
> effective key length of less than 112

I can live with this.

>
> bullet 5   Implementations SHOULD prefer cipher suites with greater than
> 128 bits of effective key length

No, this contradicts our recommendation, and IMO is too strict for the 
current state of the industry. In other words, people are perfectly 
happy with AES-128 today and it is NOT our goal to push to AES-256.

>
> bullet 6  Given the foregoing considerations, implementation of the
> following suites are recommended (in order of preference)
>
> ·TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>
> ·TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>
> ·TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>
> ·TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>
> Rational: In the preceding bullet we give preference to cipher with 256
> bit key

Again, we disagree on this point.

>
> Also client MUST send an ec_point_formats extension

As I mentioned earlier, "RFC 4492 specifies the MUST/SHOULD status for 
these extensions. I don't think we should be repeating or overriding that."
>
> 3.5 public key lengths.
>
> Public key algorithms based on integer factorization or discrete
> logarithms MUST use a public key size of at least 2048 bits.

This is currently a SHOULD-level requirement (we use the equivalent term 
RECOMMENDED). Given the problems with modular DH in TLS, I'm afraid we 
cannot mandate >2048 because of the interoperability issues, and because 
some people might value forward secrecy over key length.

>
> 4.1
>
> Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as the
> first proposal to any server.
>
> Rational: Section 3.4 bullet 5 says we give preference to ciphers
> stronger than 128 bits.

Disagree again.

>
> Clients MUST include the “supported elliptic curve” extension

See above.

Thanks,
	Yaron

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 06 Jul 2014 22:29:07 +0300

Adding some data to my previous mail:

As of Jan. 2014, 65% of the top 1M Web servers did not speak TLS 1.1 or 
1.2 [1]. So while we should move implementations to TLS 1.2 (as we do in 
this draft), it is probably too early to mandate against the fallback to 
TLS 1.0.

Thanks,
	Yaron

[1] https://jve.linuxwall.info/blog/index.php?post/TLS_Survey

> On 06/30/2014 09:11 PM, Trevor Freeman wrote:
[...]

> interoperability reasons. But I may be wrong about the prevalence of
[...]

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 Jul 2014 20:31:24 +0100

> this draft), it is probably too early to mandate against the fallback to

I wonder if that's changed post-heartbleed? I suspect it may well
have but no idea by how much. Anyone know?

S.

---

From: Ivan Ristić <[email-masked]>
Date: Sun, 06 Jul 2014 20:35:55 +0100

> have but no idea by how much. Anyone know?

Monthly stats are available from SSL Pulse:

  https://www.trustworthyinternet.org/ssl-pulse/

There might be some problems currently when viewing the site in Firefox
on Windows. Please use another browser if you can. I'll report the problem.

If you'd like to see some stats that are currently not available, let me
know. CVE-2014-0224 stats will be available in a couple of days.

-- 
Ivan

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 06 Jul 2014 22:41:21 +0300

Hmmm, surprisingly the answer to Stephen's question is, essentially no. 
We're now at 60% TLS 1.0-only.

Thanks,
	Yaron

---

From: Ivan Ristić <[email-masked]>
Date: Sun, 06 Jul 2014 20:47:52 +0100

> We're now at 60% TLS 1.0-only.

According to SSL Pulse data, 25.7% supported TLS 1.2 in January, and 37%
in June. It will be 38.5% in July. So there's been a significant change.

As to why my numbers are different to those Julien publisher, it will
come down to the differences in data sets and the scanning methodology.
Just as an illustration, I accept only valid certificates in my survey,
but there's no mention of validation in Julien's post.

-- 
Ivan

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 Jul 2014 20:51:25 +0100

> We're now at 60% TLS 1.0-only.

Well, different data sets and all that;-) Ivan's data has
TLS1.2 at 37% in June, but 26% in Jan. But yeah, I'd have
guessed there'd be more of a bump.

S.

PS: Ivan - thanks for your site/data! I think its great.
If I were to ask for something more, I'd say the ability
to see the graphs for how things change over time and/or
the ability to export the data (as a csv or whatever)
would nice additions.

---

From: Ralph Holz <[email-masked]>
Date: Mon, 07 Jul 2014 12:11:43 +1000

Hi,

>> Section 3.2 still treats SSL 3.0 differently to TLS 1.0. Why is it
>> ok to fall back to TLS 1.0 but not SSL 3.0 if both offer the same
>> security?
> 
> This is a good question. I believe the answer is, because much of
> the server population still only supports TLS 1.0, and if we
> recommend otherwise, the recommendation will be ignored for
> (justified) interoperability reasons. But I may be wrong about the
> prevalence of such servers.

Someone should chime in here, but I remember the state of TLS extensions
is a concern for SSL 3. Anyway, TUM's Internet-wide measurements showed
SSL 3-only deployment to be around 3%, so I don't think we have a
problem there.

If you need a citable source, we might have to ask Ivan Ristic for data
from SSLPulse. TUM is not going to publish a Technical Report at this
time, so you'd have to take my word for it.

> As I mentioned earlier, "RFC 4492 specifies the MUST/SHOULD status
> for these extensions. I don't think we should be repeating or
> overriding that."

This question seems to pop up reltaively frequently, however. I am
starting to think we might compromise here - after all, the BCP is a
collection of practices that are otherwise distributed over many
(non-RFC and RFC-) sources, and it might not do us worse if we happen to
reiterate on this one issue. If we can keep it limited to this one.

Another concern of mine is that normal RFCs often go unheeded anyway by
software implementations - maybe this BCP has a better-than-average
chance of being noticed.

>> Clients MUST include the “supported elliptic curve” extension

Same would apply here.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Watson Ladd <[email-masked]>
Date: Sun, 6 Jul 2014 20:22:43 -0700

> SSL 3-only deployment to be around 3%, so I don't think we have a

Why are we not including 1/(n-1) record splitting when TLS 1.0 is negotiated?

Furthermore, we should mention workarounds for Triple Handshake and Lucky 13.
I think we mention CRIME already.

Sincerely,
Watson Ladd

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 07 Jul 2014 09:41:46 +0200

> the constraints of current technology and interoperability.

Adding my voice here as chair. Even though the WG haven't really talked
about the type of RFC to publish, the term 'BCP' should still guide our
efforts.

This means that the draft should focus on best _current_ (my emphasis)
practice which means neither good, worst, bad or good-enough and also
neither future or historic practice.

We need to strike a careful balance between what we want and what we can
have given current deployment status. This also means that a BCP-like
document is not an appropriate forum for pushing too much against the
inside of the envelope - in fact it should nestle right up to the inside
edge of the envelope.

If we want to write a document describing what we'd _wish_ implementers
and deployers would do, we can do that too.

> I am not sure about the overlap, and would appreciate specific points.

Speaking as chair: Trevor, please suggest changes so the WG has
something more tangible to work with.

> operational decision, and so we should not include such a recommendation."

Speaking as an individual, I'd say that SNI should (in this day and age)
be considered mandatory to implement if not mandatory to deploy. I
suspect Trevor is pushing on the first issue while you are pushing back
on the second.

> Again, we disagree on this point.

Speaking as chair I need others to chime in here. The WG needs to come
to consensus (even if it is rough) and right now me and Orit don't have
enough data.

>> Rational: Section 3.4 bullet 5 says we give preference to ciphers

cf above

>> Clients MUST include the “supported elliptic curve” extension

cf above

---

From: Adam Caudill <[email-masked]>
Date: Mon, 7 Jul 2014 12:44:04 -0400

On Jul 6, 2014, at 3:09 PM, Yaron Sheffer <[email-masked]> wrote:

> No, this contradicts our recommendation, and IMO is too strict for the current state of the industry. In other words, people are perfectly happy with AES-128 today and it is NOT our goal to push to AES-256.

For a BCP, I don’t see how a SHOULD prefer >128 is too strict. 

This isn’t a MUST, and certainly isn’t a requirement that only the 256 bit variants are used. Personally, if someone asks me what the best practice today is - I wouldn’t hesitate to say that 256 should be prioritized over 128, and 128 prioritized over 112. There may be environments where this isn’t practical - and that’s why this isn’t a MUST, but it is what SHOULD be done.

-- 
Adam Caudill
[email-masked]
http://adamcaudill.com/

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 17 Jul 2014 16:28:51 +0000

Hi Yaron,

Thanks for the response. My the point remains is why treat TLS1.0 different to SSL3.0 if they have the same security characteristics. Why is fallback to TLS1.0 is ok, but is SSL 3.0 not? The only rationale I can think of is given their similarity, the odd of success with SSL 3.0 if TLS 1.0 fails are slim, but that seems a weak case for prohibition. 

Trevor
-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Sunday, July 06, 2014 12:29 PM
To: Trevor Freeman; [email-masked]
Subject: Re: [Uta] TLS BCP 01 Draft

As of Jan. 2014, 65% of the top 1M Web servers did not speak TLS 1.1 or
1.2 [1]. So while we should move implementations to TLS 1.2 (as we do in this draft), it is probably too early to mandate against the fallback to TLS 1.0.

Thanks,
	Yaron

[...]

>>
>> Section 3.2 still treats SSL 3.0 differently to TLS 1.0. Why is it ok 
>> to fall back to TLS 1.0 but not SSL 3.0 if both offer the same security?
>
[...]

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 17 Jul 2014 20:02:06 +0000

Hi Yaron,

Thanks for the response. See inline

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Sunday, July 06, 2014 12:09 PM
To: Trevor Freeman; [email-masked]
Subject: Re: [Uta] TLS BCP 01 Draft

On 06/30/2014 09:11 PM, Trevor Freeman wrote:
> against monitoring i.e. what offers best, adequate or minimal 
> protection against monitoring.  Give one of the goal is to move the 
> internet to better protect against this kind of activity, we need to 
> clarify which actions in this draft best enable that goal and not just 
> providing basic interoperability.

These are lofty goals indeed. But the draft's goal is not to define "best protection against monitoring", let alone to define 3 levels of such protection. It is simply to remediate issues with the way TLS is currently deployed. I don't think we "just provide basic interoperability", I believe we provide strictly better security, within the constraints of current technology and interoperability.

[TF] The strategy for the ietf's response is to increase the cost of those activates by making it more expensive to read the traffic. You already hint that some aspects provide better security that others by the keywords you use to devein what must, should, may or should not be done.  

[TF] Overall I don’t see any logic behind the split between section 3 and 4 which is what I mean by overlap. A lot of what's in section 3 seems pretty detailed. It's much easier to read if the bottom line of what we need you to do in in one place.

> actually list the cipher suites in question to remove any scope for 

The first part of Sec. 3.4 provides more than half a page of rationale for the cipher suite selection.

>
> Also support for the SNI is missing from the draft. This is a 
> mandatory for any application interacting with a service.

Quoting my own earlier response to you (my mail of June 21): "I'm all in favor of using SNI. But as far as the draft goes, I believe this is an operational decision, and so we should not include such a recommendation."

[TF] The implementers are totality ignorant of the operational choice made by the server so is in no position to make an informed decision hence the need to mandate. 

[TF] Give the similarity of the security properties of SSL 3.0 and TLS 1.0, I am still unclear why you consider it is ok to fall back 1.0 and not 3.0. The only rational I can think of is given the similarities the likelihood of success with SSL 3.0 if TLS 1.0 fails is pretty small but that seems a weak case for a prohibition.   

I can live with this.

[TF] This is a less redundant interpretation of how I read this bullet. The  read the "if possible 256" part overriding the "at least 128 bit" part. The base 1.2 rfc already mandates 128 bit ciphers as a MUST.  What are you trying to convey with this bullet?

[TF] I agree that the base RFC should be authoritative however I less convinced all implementers are totally diligent in recusing though every aspect of every normative reference and would like to some language on the need to follow rfc 4492 guidance on this extension. Rfc's are complex documents and it is all too easy to miss something

[TF] Then we need to differentiate static from ephemeral use cases.  

Implementations MUST support  end entity public keys in certificates based on integer factorization or discrete logarithms of at least 2048 bits. Implementations MUST support  ephemeral discrete logarithms public keys of at least 1024 bits.  

I would like to add a rider to do better that 1024 bit but give the inability of the client to signal what it supports in terms of key sizes, that would be futile. 

Disagree again.

> Clients MUST include the “supported elliptic curve” extension

See above.
[TF] Likewise

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Jul 2014 20:12:35 +0300

Hi Trevor,

There are quite a few differences between SSLv3 and TLS 1.0, including 
(to the best of my knowledge) that TLS servers tend to support TLS 
extensions, while SSL-only servers do not (including of course 
security-sensitive extensions like Renegotiation Indication). 
Unfortunately I cannot find an extensive list of differences online.

Since SSLv3-only servers are rare nowadays and we're trying to move the 
industry forward, I think the prohibition does make sense.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Jul 2014 20:43:42 +0300

Hi Trevor,

Please see further comments inline.

Thanks,
	Yaron

> [TF] The strategy for the ietf's response is to increase the cost of those activates by making it more expensive to read the traffic. You already hint that some aspects provide better security that…

Sorry, I still do not understand what you would like to see changed in 
the draft WRT this comment.

> [TF] Overall I don’t see any logic behind the split between section 3 and 4 which is what I mean by overlap. A lot of what's in section 3 seems pretty detailed. It's much easier to read if the bott…

I agree that Sec. 3.4 suffered some "feature creep" and became too long. 
I suppose it could be trimmed down or broken into several subsections.

The logic is that Sec. 3.4 provides reasoning for selecting preferred 
cipher suites, leading to a list of recommended cipher suites. Sec. 4.1 
builds on this list, and tells the implementer/deployer how to use it.

> [TF] The implementers are totality ignorant of the operational choice made by the server so is in no position to make an informed decision hence the need to mandate.

OK, I get your point. SNI is important enough to mandate its 
implementation. Whether it needs to be used in particular cases, is up 
to operations people.

> [TF] Give the similarity of the security properties of SSL 3.0 and TLS 1.0, I am still unclear why you consider it is ok to fall back 1.0 and not 3.0. The only rational I can think of is given the…

See my response in a separate email.

> [TF] This is a less redundant interpretation of how I read this bullet. The  read the "if possible 256" part overriding the "at least 128 bit" part. The base 1.2 rfc already mandates 128 bit cipher…

The current wording is a bit vague: "Implementations SHOULD prefer 
cipher suites that use algorithms with at least 128 (and, if possible, 
256) bits of security." But I think it makes sense in the context of 
leading up to the list of cipher suites.

> [TF] I agree that the base RFC should be authoritative however I less convinced all implementers are totally diligent in recusing though every aspect of every normative reference and would like to…

OK, as Ralph noted, we will include the relevant RFC 4492 extensions in 
the next revision.

> I would like to add a rider to do better that 1024 bit but give the inability of the client to signal what it supports in terms of key sizes, that would be futile.

I agree we should differentiate between static and ephemeral use cases. 
Basically, the section should be broken into "Ephemeral DH" and 
"Certificates". We should replace both occurrences of "DH" by "DHE" 
(people only care about Ephemeral DH, and our recommended list only 
includes DHE and ECDHE cipher suites). And AFAIK, nobody cares about 
"certificates based on discrete logarithms" (i.e. DSA certs).

>> Clients MUST include the “supported elliptic curve” extension

Likewise, will be added.