Subject: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt

From: Yaron Sheffer <[email-masked]>
Date: Sun, 08 Sep 2013 11:25:59 +0300

This is an early version of my proposal for a BCP-like document, to 
inform the industry on what can be done with existing implementations, 
while TLS 1.3 is still not ready.

I would appreciate your comments of course. Specifically,
I would like to fill in the Implementation Status table (Sec. 5) and 
would be glad to receive solid information (dates, planned dates, 
version numbers) from implementers.

Thanks,
	Yaron

-------- Original Message --------
Subject: New Version Notification for draft-sheffer-tls-bcp-00.txt
Date: Sat, 07 Sep 2013 15:46:38 -0700
From: [email-masked]
To: Yaron Sheffer <[email-masked]>

A new version of I-D, draft-sheffer-tls-bcp-00.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Filename:	 draft-sheffer-tls-bcp
Revision:	 00
Title:		 Recommendations for Secure Use of TLS and DTLS
Creation date:	 2013-09-08
Group:		 Individual Submission
Number of pages: 8
URL: 
http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp
Htmlized:        http://tools.ietf.org/html/draft-sheffer-tls-bcp-00

Abstract:
    Over the last few years there have been several serious attacks on
    TLS, including attacks on its most commonly used ciphers and modes of
    operation.  This document offers recommendations on securely using
    the TLS and DTLS protocols, given existing standards and
    implementations.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sun, 8 Sep 2013 10:12:36 +0000

Dear Yaron, 

Thanks for sharing this draft.

Some quick points of feedback:

* Firstly, you asked:

[[Is it possible to affect some length hiding using TLS 1.2 as
   specified today, i.e. without draft-pironti-tls-length-hiding-01, and
   using available APIs?]]

The answer is "yes, to some extent, and for some cipher suites, but it
does not help much against compression attacks".

Expanding: variable length padding is available for CBC-mode ciphersuites
in TLS 1.0 and higher (but not widely implemented). This allows an
implementation to "disguise" the underlying message size to some extent,
and it can be proven to be secure providing you avoid short MAC tags as in
RFC 6066 (see my paper with Ristenpart and Shrimpton from Asiacrypt 2011:
http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf).

Such padding is not available for RC4-based ciphersuites, nor for AES-GCM,
nor AES-CCM. 

The amount of variability this feature introduces into ciphertext lengths
is not sufficient to prevent CRIME/BREACH, but only slows them down a bit
(I have not quantified this; that would require a more detailed analysis
which is not justified given the apparent benefit).

* Secondly, concerning attacks on RC4:

You mention the work of Isobe et al. from FSE 13 (as citation
[RC4-Attack]). I've also been involved in parallel work which goes more
deeply into the practical applications of RC4 weaknesses to breaking TLS
and which includes more powerful attacks, making the case for abandoning
RC4 even stronger:

N.J. AlFardan, D.J. Bernstein, K.G. Paterson, B. Poettering and J.C.N.
Schuldt. On the Security of RC4 in TLS. In USENIX Security Symposium 2013.

https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls

http://www.isg.rhul.ac.uk/tls

* Thirdly, a technical point concerning CRIME/BREACH:

You write: "The attack is a consequence of the TLS MAC-then-encrypt
approach."

This is incorrect. The attacks would apply equally well to AES-GCM
ciphersuites (which do not adopt the MAC-then-ecnrypt approach).

Regards

Kennt

On 08/09/2013 09:25, "Yaron Sheffer" <[email-masked]> wrote:

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

---

From: Patrick Pelletier <[email-masked]>
Date: Sun, 08 Sep 2013 18:39:04 -0700

One thing which I feel is missing is recommendations on the size of 
Diffie-Hellman parameters.  It seems generally accepted that 1024-bit 
Diffie-Hellman is no longer secure, and yet that's what most folks are 
still using.  How about something along the lines of "Diffie-Hellman 
parameters of at least 2048 bits SHOULD be chosen"?

--Patrick

On 9/8/13 1:25 AM, Yaron Sheffer wrote:
> URL: http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Sep 2013 16:10:10 +0100

Hi Yaron,

Thanks for doing this. I hope the WG adopt this and
process it quickly.

A few comments:

1) Given recent news, I think section 2 should describe why
PFS is a good thing and should say a bit about how server
private keys can be exposed (e.g. someone hacks into
server and copies a private key file, or gets keys from
a decommissioned server), and the consequences that flow
if non-PFS ciphersuites are used.

2) I think an appendix or section that shows how to configure
a server to prefer whatever ciphersuite configurations end
up as recommended would be very valuable. I realise that that
would be server specific but it should be easy enough to get
for the most popular server or the two most popular. While
that information is already available on the web, and will
go out of date, its finicky stuff so it'd be good to make
all this easier for a site admin who reads the RFC in
the next couple of years.

3) Similarly, saying how to turn off ciphersuites that you
don't want and which those are might be useful.

4) I also think it'd be good to give recommendations for
older versions of TLS (and maybe SSL) that are still
widely deployed, even though TLS 1.2 will have better
options and the overall recommendation is to use a
1.2 ciphersuite.

5) I agree with the point raised by Patrick that some
guidance about reasonable key lengths/strengths would
be good where its needed. I'd be ok with that being in
the non-normative bit where you show how to configure
stuff and/or in the security considerations.

Some text related to a number of the above points can be
found via the links in a mail that Patrick Pelletier [1]
sent to the perpass list.

Cheers,
S.

[1] http://www.ietf.org/mail-archive/web/perpass/current/msg00062.html

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 09 Sep 2013 23:06:09 +0300

Hi Stephen,

thanks for your review. Please see comments inline.

	Yaron

> Thanks for doing this. I hope the WG adopt this and

So do I. This document will become way more valuable if the WG adopts it.

> if non-PFS ciphersuites are used.

Agree.

> the next couple of years.

I'm not crazy about including Apache directives in an RFC. More 
importantly, I believe this is more about the client offering the right 
ciphersuite in a high enough place than about the server, which normally 
must support any client that comes along.

> don't want and which those are might be useful.

This is a security vs. inclusiveness tradeoff. Even if we tell people to 
turn off RC4 on the server, they won't.

> options and the overall recommendation is to use a

I wish I knew what to recommend for <1.2. Any ideas?

> stuff and/or in the security considerations.

Agree. My current thinking, based on today's discussion, is 2048 bits 
for both DH and RSA.

---

From: Patrick Pelletier <[email-masked]>
Date: Mon, 09 Sep 2013 14:22:47 -0700

> [1] http://www.ietf.org/mail-archive/web/perpass/current/msg00062.html

Besides those links, another link worth reading is this one:

https://www.imperialviolet.org/2013/06/27/botchingpfs.html

I think it would be good to cover the risks of session resumption and 
how to mitigate them.  (e. g. rotating the keys used for session tickets)

--Patrick

---

From: Hanno Böck <[email-masked]>
Date: Tue, 10 Sep 2013 11:47:18 +0200

On Sun, 08 Sep 2013 11:25:59 +0300
Yaron Sheffer <[email-masked]> wrote:

> inform the industry on what can be done with existing
> implementations, while TLS 1.3 is still not ready.
> 

I was asked on another list to cross-post my comments on it here:

I don't really see from the document why the authors discourage
ECDHE-suites and AES-256. Both should be okay and we end up with four
suites:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Also, DHE should only be considered secure with a large enough modulus
(>=2048 bit). Apache hard-fixes this to 1024 bit and it's not  
configurable. So there even can be made an argument that ECDHE is more
secure - it doesn't have a widely deployed webserver using it in an
insecure way.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Sean Turner <[email-masked]>
Date: Tue, 17 Sep 2013 11:08:24 -0400

> version numbers) from implementers.

Yaron,

Thanks for this draft, I'm supportive of it, and hope that the WG adopts 
it.  They've not had a history of adopting algorithm drafts, but this is 
one I think they should strongly consider adopting especially because it 
impacts the base specification.

A couple of things come to mind:

1. TLS isn't just used by browsers, but Brian Smith is also proposing 
some changes to the cipher suites offered by browsers 
(https://briansmith.org/browser-ciphersuites-01.html).  It'd be good to 
review those recommendations especially since he's recommending a few 
TLS_ECDHE suites ahead of TLS_DHE suites (assuming I'm reading the 
recommendation properly).  Also note that there's some information about 
implementation support there as well.

2. An implication of your draft is that version TLS 1.2 is preferred 
over other TLS versions.  That is kind of already done with the 
obsoletes trail from 1.0 to 1.1 to 1.2, but maybe it's time to dust off 
the issue of whether it's worth providing guidance on SHOULD NOT use SSL 
3.0/ TLS version 1.0/1.1.  Two caveats: 1) Unsure if it is practical to 
knock off older versions based on an algorithm recommendation given the 
deployment numbers, and 2) I'm also not sure this kind of recommendation 
needs to go in this draft.

3. (not specific to the draft) Going forward for TLS 1.3 maybe we should 
consider splitting out the MTI algorithms from the base specification so 
that we can update the MTIs on a regular basis without having to revise 
the base specification, which is what IPsec, S/MIME, PKIX, etc. have done.

4. I like Stephen's idea of explaining why PFS is needed.  Note that 
there's some information in RFC 4949 about PFS that you could start from.

5. Providing BCP algorithms for earlier TLS versions is okay in my mind 
essentially because those versions are still out there.

6. I'm torn on the idea of adding an appendix on how to 
add/remove/configure algorithms.  If it's information that's not readily 
available then I'd say it'd be worth documenting, but whether it goes in 
this draft or another I'd leave to the authors/wg.  (i.e., not sure we'd 
need to have a death match over the commands to input to apache to get 
this draft done)

On the procedural notes:

1. Don't worry about whether the draft's intended status is BCP or 
standards track.  I'd have no problem sponsoring it regardless; I've 
been down this path before, BCPs can document what is being done already 
or what we want to done now and in the future.

2. Feel free to use 2119 language, but depending on how you write it it 
might not be necessary.

spt

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 17 Sep 2013 22:10:06 +0300

Hi Sean,

Thanks for your review. Please see my comments below.

	Yaron

> On 9/8/13 4:25 AM, Yaron Sheffer wrote:
[...]
> implementation support there as well.

Thanks for pointing it out. It is very useful. And it agrees on the #1 
cipher suite with our upcoming -01 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).

> needs to go in this draft.

TLS 1.2 is sort-of implicit in the draft. Also, there have been 
proposals to backport GCM to 1.0 and 1.1. I'm not sure if it makes sense 
(vs. wholesale transition to 1.2), but if that happens, fine.

> the base specification, which is what IPsec, S/MIME, PKIX, etc. have done.

I agree.
> there's some information in RFC 4949 about PFS that you could start from.

Ralph contributed excellent text on PFS for -01.

> essentially because those versions are still out there.

Except that nobody wants to come forward with a proposal for such 
algorithms, because so much is unfortunately broken. E.g. I don't think 
you can recommend AES-CBC without some of the mitigations people have 
implemented.

> need to have a death match over the commands to input to apache to get

I simply don't have the time to do it. But here's someone who did: 
http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

> On the procedural notes:

Let's go into this when we discuss WG adoption. Currently the draft is 
strictly lower case.