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

From: Tom Ritter <[email-masked]>
Date: Sun, 25 May 2014 19:27:06 -0400

Okay, I read draft-ietf-uta-tls-bcp[0] for REAL this time.  Sorry
about that.  Most of my prior comments are addressed, I still have a
few.

1) "will very likely obsolete the current document"
Suggest it be "will very likely obsolete this document"

2) There are a few attacks on TLS that are omitted.  In particular, I
would have expected information on securing deploying a configuration
that also avoids:
 - The ECC algorithm confusion attack[1]
 - Triple Handshake
 - TLS stripping (And using HSTS to prevent)

3) I think it is worth mentioning that TLS Servers have an asymetric
workload with the client, and thus can be subject to computational DoS
attacks.

4) I would like to say something about using PKP to mitigate
certificate forgeries, but that'll have to be in an update when PKP
gets standardized.

5) I would love to say something about section 3.2 and using (if/when
it becomes available) the SCSV, but I suppose that doesn't actually
help anyone because it's not available now either.

6) In the attacks document, I still think it's a little awkward to
mention Lucky 13.  I would suggest mentioning explicitly this is an
implementation error that has been corrected in up to date libraries.
I would also say in BEAST that the flaw was corrected in TLS 1.1.

7) Is it worth mentioning that an operator should not 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?

8) My opinion is that OCSP information, stapled in the response, is a
'Best Current Practice' for TLS.

Again, sorry for my prior confusion.

-tom

[0] http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00
[1] https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf

---

From: Ralph Holz <[email-masked]>
Date: Tue, 27 May 2014 16:01:51 +1000

Hi,

> 1) "will very likely obsolete the current document" Suggest it be
> "will very likely obsolete this document"
> 
> 2) There are a few attacks on TLS that are omitted.  In particular,
> I would have expected information on securing deploying a
> configuration that also avoids: - The ECC algorithm confusion
> attack[1] - Triple Handshake - TLS stripping (And using HSTS to
> prevent)

I agree that all three should be included.

HSTS should go into the companion document.

> workload with the client, and thus can be subject to computational
> DoS attacks.

That is true, but I am wondering how much it helps if we mention it - it
is so generic that the only real help would be to avoid TLS, which is
probably not what we want.

> certificate forgeries, but that'll have to be in an update when PKP 

Agreed on both points (although I'd add that systems like TACK may be
preferable). Maybe we should have an outlook section that mentions
upcoming technologies like CT, HPKP etc.?

> 5) I would love to say something about section 3.2 and using
> (if/when it becomes available) the SCSV, but I suppose that doesn't
> actually help anyone because it's not available now either.

Later revision of the document?

> 8) My opinion is that OCSP information, stapled in the response, is
> a 'Best Current Practice' for TLS.

Totally agree. Although we'd need to mention then that the even better
way would be to include the stapled responses for the intermediate
certs, too (normal stapling doesn't do that).

To sum up, I think I can write something up regarding HSTS and OCSP
stapling, and maybe a little bit about the "outlook section".

Yaron, what's your take?

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: "Salz, Rich" <[email-masked]>
Date: Tue, 27 May 2014 09:37:25 -0400

> That is true, but I am wondering how much it helps if we mention it - it is so generic that the only real help would be to avoid TLS, which is probably not what we want.

The TLS WG has had a few chats about "client puzzles" -- where a server, mainly under load, can ask the client to do some work before resuming the handshake.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Ralph Holz <[email-masked]>
Date: Wed, 28 May 2014 00:22:20 +1000

Hi,

> The TLS WG has had a few chats about "client puzzles" -- where a
> server, mainly under load, can ask the client to do some work before
> resuming the handshake.

Yes, but then we are again at the point that weaker devices will be at a
disadvantage, and that we are burning CPU power for nothing. That,
together with the option of simply renting a botnet to stage the attack,
make the benefits seem rather insignificant.

But I could be wrong. Do we actually have evidence of DoS via TLS?

Ralph

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 May 2014 10:39:57 -0400

> Yes, but then we are again at the point that weaker devices will be at a disadvantage, and that we are burning CPU power for nothing.

If the choice is failure to connect because the server has to push off some load, versus a delayed connection...

> But I could be wrong. Do we actually have evidence of DoS via TLS?

Yes.  Here's one  http://www.arbornetworks.com/asert/2012/04/ddos-attacks-on-ssl-something-old-something-new/

---

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

I agree with most of Tom's comments.

HSTS needs to be added for sure.

I will need an explanation on why Lucky13 is "an implementation error". 
Looks like a protocol error to me.

Re: upcoming technologies (TACK, CT), I suggest to not even mention them 
in this document. It is not a survey of TLS technologies but a guide for 
the perplexed deployer (and possibly their vendor). When these things 
become "current" practices, we will need to republish.

OCSP (stapling or otherwise) assumes widespread deployment of OCSP 
servers. Is that the situation today? To put it into concrete terms, are 
more than 25% of currently issued certificates provided with a working 
OCSP endpoint?

Thanks,
	Yaron

---

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

With respect, Arbor Networks (the article cited below) are anti-DDoS 
vendors...

Thanks,
	Yaron

On 05/27/2014 05:39 PM, Salz, Rich wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 May 2014 16:06:53 -0400

Well so is Akamai, among other things :)

I can posit that yes, TLS DoS is happening.  Not sure how valuable that is.

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Tuesday, May 27, 2014 3:38 PM
To: Salz, Rich; Ralph Holz; [email-masked]
Subject: Re: [Uta] Real draft-ietf-uta-tls-bcp Feedback

With respect, Arbor Networks (the article cited below) are anti-DDoS vendors...

Thanks,
	Yaron

On 05/27/2014 05:39 PM, Salz, Rich wrote:
> Yes.  Here's one  
> http://www.arbornetworks.com/asert/2012/04/ddos-attacks-on-ssl-somethi
> ng-old-something-new/
>
> --

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 May 2014 00:41:33 +0300

In fact it's the other way around. See Sec. 4 of the BCP draft, in 
particular 
http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00#section-4.2. It's 
not a clear-cut decision though.

Thanks,
	Yaron

On 05/28/2014 12:31 AM, Benjamin Black wrote:
> Given the significant performance difference between ECDHE and DHE, what
> is the rationale for recommending DHE? Is DHE being recommended to deal
> with older servers that don't support ECDHE?
>
>
> On Tue, May 27, 2014 at 1:43 PM, Benjamin Black <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Even if OCSP endpoints are prevalent, do many browsers check and is
>     that even the right model? Thoughtful practitioners suggest not:
>     https://www.imperialviolet.org/2014/04/19/revchecking.html
>
>     And another +1 for HSTS.
>
>
>     b
>
>
>     On Tue, May 27, 2014 at 12:36 PM, Yaron Sheffer
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         I will need an explanation on why Lucky13 is "an implementation
>         error". Looks like a protocol error to me.
>
>         Re: upcoming technologies (TACK, CT), I suggest to not even
>         mention them in this document. It is not a survey of TLS
>         technologies but a guide for the perplexed deployer (and
>         possibly their vendor). When these things become "current"
>         practices, we will need to republish.
>
>         OCSP (stapling or otherwise) assumes widespread deployment of
>         OCSP servers. Is that the situation today? To put it into
>         concrete terms, are more than 25% of currently issued
>         certificates provided with a working OCSP endpoint?
>
>         Thanks,
>                  Yaron
>
>
>                 Suggest it be
>         _________________________________________________
>         Uta mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/uta
>         <https://www.ietf.org/mailman/listinfo/uta>
>
>
>

---

From: Tom Ritter <[email-masked]>
Date: Tue, 27 May 2014 22:31:03 -0400

> Looks like a protocol error to me.

Lucky 13 is an attack on CBC padding, where you have an oracle about
whether or not the padding is valid and you use that to perform
decryptions.  The specific oracle Lucky 13 uses is a timing attack -
if it takes more time, it's valid if it takes less time, it's not.  If
the implementation is constant time, like it's supposed to be, then
there's no oracle, and no attack.

https://www.imperialviolet.org/2013/02/04/luckythirteen.html is a good
reference.

> Re: upcoming technologies (TACK, CT), I suggest to not even mention them in
> this document. It is not a survey of TLS technologies but a guide for the
> perplexed deployer (and possibly their vendor). When these things become
> "current" practices, we will need to republish.

I agree with this.

> OCSP (stapling or otherwise) assumes widespread deployment of OCSP servers.
> Is that the situation today? To put it into concrete terms, are more than
> 25% of currently issued certificates provided with a working OCSP endpoint?

Yes. http://uptime.netcraft.com/perf/reports/performance/OCSP

>>     https://www.imperialviolet.org/2014/04/19/revchecking.html

OCSP Stapling neatly solves a lot of problems of revocation. It has no
side channels, it handles CA downtime for several hours while having a
vulnerable window measurd in hours and not days, and so on.  And with
a must-staple pinning for sites in the HSTS header (which I hope will
be coming 'real soon now'), it becomes hard fail.  And, I have a small
hope that we can get enough of the deployed internet to stapling over
the next several years, so that hard fail becomes a possibility.

-tom

---

From: Benjamin Black <[email-masked]>
Date: Tue, 27 May 2014 13:43:39 -0700

Even if OCSP endpoints are prevalent, do many browsers check and is that
even the right model? Thoughtful practitioners suggest not:
https://www.imperialviolet.org/2014/04/19/revchecking.html

And another +1 for HSTS.

b

On Tue, May 27, 2014 at 12:36 PM, Yaron Sheffer <[email-masked]>wrote:

> more than 25% of currently issued certificates provided with a working OCSP
> endpoint?
>
> Thanks,
>         Yaron
>
>

---

From: Benjamin Black <[email-masked]>
Date: Tue, 27 May 2014 14:31:10 -0700

Given the significant performance difference between ECDHE and DHE, what is
the rationale for recommending DHE? Is DHE being recommended to deal with
older servers that don't support ECDHE?

---

From: Ralph Holz <[email-masked]>
Date: Thu, 29 May 2014 11:23:23 +1000

Hi,

On 05/28/2014 06:43 AM, Benjamin Black wrote:
> even the right model? Thoughtful practitioners suggest
> not: https://www.imperialviolet.org/2014/04/19/revchecking.html

The suggestion is to use OCSP Stapling, which is a much saner option
than bare OCSP.

Ralph