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

On 12/2/15 4:45 PM, Watson Ladd wrote: > On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum wrote: >> On 12/2/15, Eric Rescorla wrote: >>> It's not really clear to me what the anti-traffic-analysis benefit of your >>> proposal >>> is over and above just padding everything to a fixed size. That's ce

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

On 12/2/15 9:13 PM, 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 expe

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

Hi Mike, On 12/2/15 4:14 PM, Mike Copley wrote: > [...] Not sure if this is the right place to consider, but would DTLS 1.3(?) > be able to encrypt headers and still handle packet loss and re-ordering? If > DTLS needs cleartext headers, would it be better to advise one approach for > both proto

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

Hi Jens, On 12/2/15 11:47 AM, GUBALLA, JENS (JENS) wrote: >> 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 sequenc

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 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, Brya

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

Hi *, Jacob Appelbaum wrote: > I'm sorry but that analysis is just not a serious and rigorous analysis. No it's not. It's a very short presentation from a TLS-WG interim meeting. The threat-model concerns Akamai's (and other's) current and - possibly - future use of TLS. We're not trying to build

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

> I actually went in thinking that I'd be crushed and concede; imagine my > surprise! The fact that you viewed it as "crushed and concede" implies to me that your mind was already made up, and that no description of trade-offs was going to sway you. Is that belief unfair to you? _

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

PS: Aaron Zauner wrote: > No it's not. It's a very short presentation from a TLS-WG interim > meeting. The threat-model concerns Akamai's (and other's) current and - > possibly - future use of TLS. We're not trying to build an Onion routing > protocol. Given the FUD on the Tor dev list, this is a

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

On 12/3/15, Salz, Rich wrote: >> I actually went in thinking that I'd be crushed and concede; imagine my >> surprise! > > The fact that you viewed it as "crushed and concede" implies to me that your > mind was already made up, and that no description of trade-offs was going to > sway you. Is that

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

On Thu, Dec 3, 2015 at 6:36 AM, Jacob Appelbaum wrote: > On 12/2/15, Eric Rescorla wrote: >> 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, Mart

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

Hello, On 12/3/15, Aaron Zauner wrote: > PS: > > Aaron Zauner wrote: >> No it's not. It's a very short presentation from a TLS-WG interim >> meeting. The threat-model concerns Akamai's (and other's) current and - >> possibly - future use of TLS. We're not trying to build an Onion routing >> proto

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

On 12/3/15, Watson Ladd wrote: > On Thu, Dec 3, 2015 at 6:36 AM, Jacob Appelbaum > wrote: >> On 12/2/15, Eric Rescorla wrote: >>> 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:

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

Hey, Jacob Appelbaum wrote: >> I don't think traffic analysis is in the treat model for TLS proper. > > I'm confused by what you mean by traffic analysis. We encrypt content > in TLS because we know that we want confidentiality. We want that > because we know people do basic traffic analysis look

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

Errata: Aaron Zauner wrote: > BTW, I played with SNI DoS a few months back (not too much though as it > wasn't worth a paper), seems not to be as bad as it used to be because > implementations nowadays have at least some counter-measures. Was supposed to say 'renegotiation DoS' I've looked at SNI

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

Jacob Appelbaum wrote: >> >>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >>> secure >> >> That is a myth. > > Are you asserting that TLS 1.3 will be less secure or equally secure here? Even TLSv1.0 is sufficiently secure already, so that there are plenty of other attack su

[TLS] IETF 94 meeting minutes posted

All, I’ve been a bit delinquent with posting the minutes but they are now up: https://www.ietf.org/proceedings/94/minutes/minutes-94-tls They’re pretty much what Jim entered into the etherpad with only minor corrections (typos and filling in some names). If you have comments please send them b

Re: [TLS] Fresh results

On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos wrote: > 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 lo

Re: [TLS] Fresh results

> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier wrote: > > On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos > wrote: >> 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/veroeffentli

[TLS] WGLC for ChaCha20-poly1305 ciphers

draft-ietf-tls-chacha20- poly1305-03 has been submitted incorporating feedback from working group discussions. In particular the construction now matches what is used i

Re: [TLS] Fresh results

On Thursday, December 03, 2015 03:47:52 pm Yoav Nir wrote: > Wouldn’t it be better to mandate that if your TLS implementation supports > both TLS 1.2 and TLS 1.3 it should take actions necessary to mitigate the > bleichenbacher attack? > > In fact, if you don’t care much about very old browsers,

Re: [TLS] Fresh results

On Tue, Dec 1, 2015 at 3:02 PM, 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/Tls13QuicAttacks.pdf >> >> This one looks very nasty to fix. Short of disallowing the use of RSA >> certificates for TLS

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

On 12/3/15, Martin Rex wrote: > Jacob Appelbaum wrote: >>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less secure >>> >>> That is a myth. >> >> Are you asserting that TLS 1.3 will be less secure or equally secure >> here? > > Even TLSv1.0 is sufficiently secure already

Re: [TLS] Fresh results

On Thu, 3 Dec 2015 18:45:14 -0500 Watson Ladd wrote: > On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck wrote: > > So as long as you make sure you implement all the proper > > countermeasures against that you should be fine. (Granted: This is > > tricky, as has been shown by previous results, even the

Re: [TLS] Fresh results

> On Dec 3, 2015, at 12:47, Yoav Nir wrote: > > >> On 3 Dec 2015, at 8:40 PM, Fabrice Gautier wrote: >> >> On Wed, Dec 2, 2015 at 2:14 AM, Nikos Mavrogiannopoulos >> wrote: On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote: On Tue, 1 Dec 2015 14:28:49 -0500 Watson Ladd wro

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

Jacob Appelbaum writes: >TCP/IP and DNS are out of scope, though obviously related. Why are they out of scope? You can't just ignore a threat if it's inconvenient, you need to look at the overall picture. Arguing over plugging a mousehole in the corner of the barn is pointless when two of the

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

On 12/4/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>TCP/IP and DNS are out of scope, though obviously related. > > Why are they out of scope? They are out of scope for the TLS working group as far as I understand the organization of the IETF in terms of mandate. Am I incorrect? Should

Re: [TLS] Draft status and updates

On Wed, Dec 2, 2015 at 11:23 AM, Ilari Liusvaara wrote: > > > > > Trying to read between the lines, is your concern that the server is > > > > now no longer explicitly signing over the ServerConfiguration in > > > > its CertificateVerify [Note that the client continues to do so]? The > idea > > >

Re: [TLS] Fresh results

The use of the same RSA key for decryption and signature has always been problematic from a cryptographic point of view. As far as I am aware, all current security theorems for TLS assume that the same RSA certificate (public key) is not used in both RSA and DHE ciphersuites. In theory this sh

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

Hi Bryan, I guess Dmitry is talking about the trick when each datagram is encrypted with its own key, derived from the "master" session key using some unique public parameter of the datagram, like its sequence_number. This trick makes attacks on encryption key almost useless. It is not specifi

Re: [TLS] Fresh results

On Fri, Dec 04, 2015 at 07:41:16AM +0100, Karthikeyan Bhargavan wrote: > Of course, the current practice is that KeyUsage is ignored. OpenSSL will > take a certificate that only specified Public Key Encryption and happily use > and accept it for digital signature. Similar flexibility allows ECDSA