Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 2/12/2015, at 1:38 pm, Yoav Nir wrote: > >> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum wrote: >> >> >>> These are corporate >>> firewalls. When it comes to filtering HTTPS connections, firewalls have >>> three ways to classify the connection: >>>

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 02/12/15 15:38, Jacob Appelbaum wrote: >> > It’s quite >> > useful in hotspot/public wifi environments where making policy decisions >> > based on hostname is more than sufficient, and explicit user configuration >> > of proxy settings is a non-starter. > That is an attack in my book and

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote: > On 02 Dec 2015, at 06:02, Martin Thomson wrote: > > On 1 December 2015 at 08:22, Bryan A Ford wrote: > >> The 2-byte length field in each record's header no longer

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

>Again, I'm surprised that no one is attacking the crypto design that Bryan >offered... They are. Security is about trade-offs, and the questions have been if the benefit is worth the complexity. People are assuming that it works. ___ TLS mailing

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote: > >> On 02 Dec 2015, at 06:02, Martin Thomson >> wrote: >> > On 1 December 2015 at 08:22, Bryan A Ford >> > wrote: >> >>

Re: [TLS] Draft status and updates

On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara wrote: > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > > are jointly used to produce the traffic keys and also to form a MAC

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/2/15, Martin Rex wrote: > Jacob Appelbaum wrote: >> >> I hope that we'll hide the SNI data by default and I understand that a >> discussion about encrypted SNI is currently scheduled for some point >> in the future. > > Hiding SNI data is completely silly security-wise, and

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> I think that is false. One could easily use the "cleartext" SNI field and > insert an encrypted value. A hash of the name would be a simple example but > not a secure example, of course. Encrypted SNI doesn't give you the kind of protection you think that it does. We (me and a colleague)

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum wrote: > On 12/2/15, Eric Rescorla wrote: > > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford > wrote: > > > >> On 02 Dec 2015, at 06:02, Martin Thomson > >> wrote:

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On Wed, Dec 2, 2015 at 10:00 AM, Salz, Rich wrote: > > I think that is false. One could easily use the "cleartext" SNI field > and insert an encrypted value. A hash of the name would be a simple example > but not a secure example, of course. > > Encrypted SNI doesn't give you

Re: [TLS] Draft status and updates

On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > are jointly used to produce the traffic keys and also to form a MAC over > the handshake. As Hugo pointed out originally, this alone should > be sufficient to

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/2/15, Salz, Rich wrote: >> I think that is false. One could easily use the "cleartext" SNI field and >> insert an encrypted value. A hash of the name would be a simple example >> but not a secure example, of course. > > Encrypted SNI doesn't give you the kind of protection

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Jacob Appelbaum wrote: > On 12/2/15, Martin Rex wrote: >> >> So your client will have to know a-priori, out-of-band or be configured >> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello >> with cleartext SNI. > > I think that is false. One could easily use

Re: [TLS] Draft status and updates

On Wed, Dec 02, 2015 at 09:29:23AM -0800, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara > wrote: > > > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > > > > > 3. The server provides g^y in his ServerHello and then g^xy and

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> On Dec 2, 2015, at 01:51, Bryan Ford wrote: > >> On 02 Dec 2015, at 00:54, Fabrice Gautier wrote: >>> On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford wrote: On 12/1/15 4:02 AM, Fabrice Gautier wrote: 1) What

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: > Encrypted SNI doesn't give you the kind of protection you think that it does. > We (me and a colleague) did a pretty thorough analysis that showed this. It > was not a conclusion we expected, or wanted, to reach. It was

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

Dear Bryan, On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford wrote: > Hi Dmitry, > > On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > > Dear Bryan, > > > > DTLS: > > > > Now there's still the important question of whether this (new) > proposal > > could be made to

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

On 02 Dec 2015, at 09:42, Dmitry Belyavsky wrote: > On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford > wrote: > On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > > Dear Bryan, > > > > DTLS: > > > > Now there's still the

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/2/15, Salz, Rich wrote: >> it seems blindingly obvious to me that we want it > > Few things, particularly in the security arena, are blindingly obvious. If > it actually provides no true protection, then it's just as bad as the > security theater in US airports. It

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/2/15, Martin Rex wrote: > Jacob Appelbaum wrote: >> On 12/2/15, Martin Rex wrote: >>> >>> So your client will have to know a-priori, out-of-band or be configured >>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello >>> with cleartext SNI.

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/3/15, Eric Mill wrote: > On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum > wrote: > >> On 12/2/15, Salz, Rich wrote: >> >> it seems blindingly obvious to me that we want it >> > >> > Few things, particularly in the security arena,

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On Thu, Dec 03, 2015 at 03:49:02AM +, Jacob Appelbaum wrote: > > It is far from clear that the privacy gains anything in the form of > > practical protection. Having looked at it, I'm unconvinced. And I've been > > a privacy/crypto advocate for a very very long time. > > I resolve DNS

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

There are a lot of inaccuracies in that presentation, so I wouldn't pin too much on it. In any case, before we all get too excited about this, there are some solutions, I've seen a write-up of one of them, but it was a little hard to follow first time around. Some of the things that are

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/3/15, Salz, Rich wrote: >> It provides protection. Specifically it provides confidentially. > > It is far from clear that the privacy gains anything in the form of > practical protection. Having looked at it, I'm unconvinced. And I've been > a privacy/crypto advocate for

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/2/15, Dave Garrett wrote: > On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: >> Encrypted SNI doesn't give you the kind of protection you think that it >> does. We (me and a colleague) did a pretty thorough analysis that showed >> this. It was not a

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/1/15, Yoav Nir wrote: > >> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote: >> >> On 12/1/15, Viktor Dukhovni wrote: >>> On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote: >>> Bryan A Ford

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum wrote: > > On 12/1/15, Yoav Nir wrote: >> >>> >>> Which would those be? And what is the definition of capital-intensive >>> for those watching on the sidelines? >> >> Firewall, IPS/IDS devices. Boxes that

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

On 12/2/15, Yoav Nir wrote: > >> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum wrote: >> >> On 12/1/15, Yoav Nir wrote: >>> Which would those be? And what is the definition of capital-intensive for those watching on the

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum wrote: > > >> These are corporate >> firewalls. When it comes to filtering HTTPS connections, firewalls have >> three ways to classify the connection: >> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. >>