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 work in the context of DT

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

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 indicates >> the length of the *current* record but instead indicates the length of >> the *next* record. > > Ensuring that you know the

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 important question of whether this (new) propo

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

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 would be the implications of this for DTLS? (Knowing that one >>> difference between TLS and DTLS is th

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

On 02 Dec 2015, at 02:24, Peter Gutmann wrote: > Jacob Appelbaum writes: >> I think the only thing that comes close is when I've named a classified US >> government surveillance program (XKeyscore) that would probably have trouble >> with it. > > Why would XKeyscore have trouble with it? Standa

Re: [TLS] Fresh results

On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote: > On Tue, 1 Dec 2015 14:28:49 -0500 > Watson Ladd wrote: > > > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls > > 13QuicAttacks.pdf > > > > This one looks very nasty to fix. Short of disallowing the use of > > RSA > > cert

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

> Fortunately the solution is fairly simple: the receiver simply pre- > computes and keeps in a small hash table the encrypted sequence numbers > of all packets with sequence numbers between H-W and H+W, where H is > the highest sequence number correctly received so far (the horizon) and > W is th

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 writes: > It would work just as well and in exactly the same way if the A

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 attempt to perform sanity-check on >> prot

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

On 12/2/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>I think the only thing that comes close is when I've named a classified US >>government surveillance program (XKeyscore) that would probably have >> trouble >>with it. > > Why would XKeyscore have trouble with it? My point was that w

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 sidelines? >>> >>> Firewall, IPS/IDS devices. Boxes that attempt

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

On Wednesday 02 December 2015 12:59:12 Jacob Appelbaum wrote: > 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 watchin

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. >> 2. #1, and additional

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

On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir wrote: > > I don’t think Bryan’s proposal will hurt the capabilities of a Check Point > firewall, and it will make life difficult for me as a developer no more > than it will make life difficult for developers of OpenSSL, NSS, SChannel, > or any of a dozen

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 indicates > >> the length of the *current* record but instead indicates the len

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: >>> 1. Look at the SYN and SYN-ACK packets. Ma

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: >> >> The 2-byte length field in each record's header no longer indicates >> >> the length of t

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

On 12/2/15, Mike Copley wrote: > > 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: 1

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

On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir wrote: >> >> I don’t think Bryan’s proposal will hurt the capabilities of a Check >> Point >> firewall, and it will make life difficult for me as a developer no more >> than it will make life difficult for developers of O

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 10: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: >>> > On 1 December 2015 at 08:22, Bryan A Ford >>> > wrote: >>> >> The 2-byte length field

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 li

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

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 any TLSv1.2 backwards-compatible ClientHello must includ

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 publi

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 a

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 over > > the handshake. As H

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: > >> > On 1 December 2015 at 08:22, Bryan A Ford > >> > wrote: > >> >> The 2-byte len

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 any TLSv1.2 > bac

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) did

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 the kind of protecti

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 you think that it

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

> 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. > If we can avoid adding them in TLS We're not adding anything

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 the "cleartext" S

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

On Wed, Dec 02, 2015 at 05:53:40PM +, Jacob Appelbaum 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. Furthermore, SNIs have name type, so even

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 g^xs > > > are jointly used to

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 would be the implications of this for DTLS? (Knowing that one differenc

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 presented

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

Bryan Ford writes: >We have repeatedly stated several relevant threat models here; you just >don’t seem to be accepting them as threat models for some reason. That's because they're not actual threat models, just handwringing about vague, undefined bogeymen. Yoav Nir has made a good start, al

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 provides protection. Spe

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. >> >> I think that is false.

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

> 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 a very very long time. __

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

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, are blindingly obvious. > If > > it actually provides no true protection, then it's just as bad as

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 conclusion we expected, or

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 described

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 a very very long t

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, are blindingly obvious. >> If >> > it actually provides no

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

On 12/3/15, Martin Thomson wrote: > There are a lot of inaccuracies in that presentation, so I wouldn't > pin too much on it. > I'm not pinning too much on it and I was surprised by the amount it was suggested would win me over. I actually went in thinking that I'd be crushed and concede; imagine

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 throu