Re: [TLS] draft-ietf-tls-tls13-21: actual early data...

On Fri, Aug 11, 2017 at 2:56 PM, Le Van Gong, Hubert wrote: > Hithere, > > While looking into leveraging early data, it occurred to me that the > actual effectiveness of 0-RTT is going to be highly dependent on > implementationdetails. > > In section 2.3 (Zero-RTT Data)

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote: > I don't argue with this but this is not the approach TLS 1.3 took. It > provides a generic padding mechanism to be used across application > protocols. The design approach that TLS 1.3 took was to provide a mechanism for padding

[TLS] draft-ietf-tls-tls13-21: actual early data...

Hithere, While looking into leveraging early data, it occurred to me that the actual effectiveness of 0-RTT is going to be highly dependent on implementationdetails. In section 2.3 (Zero-RTT Data) -tls13-21 [1], the first sentence says "TLS 1.3 allows clients to send data on the first

[TLS] Protocol Action: 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' to Proposed Standard (draft-ietf-tls-ecdhe-psk-aead-05.txt)

The IESG has approved the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' (draft-ietf-tls-ecdhe-psk-aead-05.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group.

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Aug 11, 2017, at 3:19 PM, Eric Rescorla > wrote: On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd > wrote: Also as pointed out by Andrei Popov, the application needs to tell TLS how much padding to apply, so

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd wrote: > If the plaintext length indicates a message type, then this could lead to > the issue the original query posted. In that an observer might know what > message type was passed. TLS padding is supposed to prevent this (but

Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT)

This is just a result of goofy tooling. I.e., I removed my discuss but didn't edit the rest of my comments -Ekr On Fri, Aug 11, 2017 at 11:13 AM, Daniel Migault < daniel.miga...@ericsson.com> wrote: > Hi Eric, > > Thank you for reviewing the document. Given your second comment, I suspect >

Re: [TLS] Looking for sample captures involving ChaCha20-Poly1305

Hi Debapriyay, On Mon, Aug 07, 2017 at 05:30:12PM +0530, Debapriyay Mukhopadhyay wrote: >I am in need of a sample capture through which I can get to see the > packet exchanges involving CHACHA20_POLY1305 cipher suites. Can anyone > please point me to any such sample capture. The Wireshark

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

If the plaintext length indicates a message type, then this could lead to the issue the original query posted. In that an observer might know what message type was passed. TLS padding is supposed to prevent this (but it doesn’t necessarily). However, I argue that having TLS do significant

Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-ecdhe-psk-aead-05: (with COMMENT)

Hi Eric, Thank you for reviewing the document. Given your second comment, I suspect you are reading the version 04 while the current version is version 05 [1]. I believe your comments have been addressed in the version 05.However let me know if you have other concerns. Regarding TLS1.3. we were

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Fri, Aug 11, 2017 at 9:47 AM, Nikos Mavrogiannopoulos wrote: > On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla wrote: > >> >> On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos > > wrote: >> >>> Imagine the following scenario, where the

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

* I don't argue with this but this is not the approach TLS 1.3 took. It provides a generic padding mechanism to be used across application protocols. At some point I thought we said that the TLS 1.3 padding mechanism was supposed to be application-driven (in the form of application-provided

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla wrote: > > On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos > wrote: > >> Imagine the following scenario, where the server and client have this >> repeated communication N times per day: >> >> client

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Fri, Aug 11, 2017 at 5:17 PM, Short, Todd wrote: > The application can solve this by having its own padding. If it’s going to > force all messages to be padded out to 1024 bytes by TLS, why not just make > that part of the application protocol? Its not as though it’s trying

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos wrote: > Imagine the following scenario, where the server and client have this > repeated communication N times per day: > > client server > --X--> > <--Y-- > > > the client puts in X a message A of 1 byte or B

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

On Aug 11, 2017, at 11:17 AM, Short, Todd wrote: > The application can solve this by having its own padding. If it’s going to > force all messages to be padded out to 1024 bytes by TLS, why not just make > that part of the application protocol? Its not as though it’s trying

Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

The application can solve this by having its own padding. If it’s going to force all messages to be padded out to 1024 bytes by TLS, why not just make that part of the application protocol? Its not as though it’s trying to save bytes here. -- -Todd Short //

[TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

Imagine the following scenario, where the server and client have this repeated communication N times per day: client server --X--> <--Y-- the client puts in X a message A of 1 byte or B of 1024 bytes, and pads it to the maximum size of TLS record. The server replies with the