Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

From: Peter Gutmann <[email-masked]>
Date: Fri, 3 Oct 2014 16:25:06 +0000

Alyssa Rowan <[email-masked]> writes:

>As I've pointed out, if you're forced into backwards compatibility with rusty
>legacy, 3DES is, though crappy, a less crappy choice than RC4.
>
>As Rich points out, just because legacy devices are indeed out there doesn't
>mean that they do TLS safely, and doesn't mean we shouldn't prohibit unsafe
>practice like using weak ciphers.

It's not just TLS implementations, you also need to look at the surrounding
infrastructure.  For example Microsoft's NDES (Network Device Enrolment
Service) hardcodes in MD5 to authenticate certs (via cert fingerprints) and
single DES (not 3DES, single DES) for "protection" of messages (even if you
send in a request using AES, the response comes back using single DES).  In
other words the most modern algorithm in there is more than twenty years old,
and it's broken.  So it doesn't matter how secure the TLS implementation is if
the certs used to control it are being "protected" with broken crypto.

Peter.

---

From: Ryan Carboni <[email-masked]>
Date: Fri, 3 Oct 2014 22:52:26 -0700

RC4 only has theoretical breaks. Most websites give you a new session
cookie certainly before 2^20 visits (1048576). The recent bias only are
noticeable after 2^26 (67108864) visits.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Fri, 24 Oct 2014 14:54:32 +0000

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Blumenthal, Uri - 0558 - MITLL
Sent: Friday, October 24, 2014 10:50 AM
To: [email-masked]' <[email-masked]>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

I disagree. In case of SMTP STARTTLS something *is* better than nothing. It is not about false sense of security - it is about making the adversary's job harder when possible as much as possible; realizing that sometimes what's possible is not going to be AES256-hard.

P.S. In that case/scenario even ROT13 is better than nothing.

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Salz, Rich [mailto:[email-masked]]
Sent: Friday, October 24, 2014 10:31 AM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-01.txt

> Leaving a cipher suite out is only practical once it is no longer the best shared
> cipher with any peers.  

I don't agree with this blanket statement.  Sometimes nothing trumps "something is better than nothing."

When the IETF's leading cryptographers say not to use something, then you're better off with plaintext than a false sense of security for your users.

	/r$

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

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