Re: [TLS] #311 (remove early_data) - Potential deadlock?

On Thu, Nov 5, 2015 at 2:27 AM, Ilari Liusvaara wrote: > I thought of following scenario: > > Client: ClientHello+0RTT > Server: 0RTT rejected. Fallback to 1RTT. > Server: (Drains 0-RTT records) > Client: Finished (corrupted in transit) > Client: Appdata (request for

Re: [TLS] Data limit for GCM under a given key.

On Wed, Nov 4, 2015 at 2:29 PM, Dang, Quynh wrote: > Hi Eric and all, > > > The limit of 2^48 packets under a given key for GCM you mentioned today is > the limit for SRTP > (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-17#section-6). > The nonce space of the

[TLS] Data limit for GCM under a given key.

Hi Eric and all, The limit of 2^48 packets under a given key for GCM you mentioned today is the limit for SRTP (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-17#section-6). The nonce space of the IV construction is only 48 bits and that is why it has the limit of 2^48. The

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

Thanks! Fixed in master. > On 4 Nov 2015, at 9:45 PM, Hubert Kario wrote: > > On Tuesday 03 November 2015 19:05:11 internet-dra...@ietf.org wrote: >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05 > > > typo: >

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

On Wed, Nov 04, 2015 at 06:30:26AM -0500, Watson Ladd wrote: > This draft needs to say that Curve25519 can only be used along with > extended master secret. Alternatively we can completely remove the > cofactor and reject zero keys. X25519 and X448 specifications say zero keys MUST be rejected

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

On Wed, Nov 4, 2015 at 6:34 AM, Ilari Liusvaara wrote: > On Wed, Nov 04, 2015 at 06:30:26AM -0500, Watson Ladd wrote: >> This draft needs to say that Curve25519 can only be used along with >> extended master secret. Alternatively we can completely remove the >> cofactor

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

On Wed, Nov 04, 2015 at 06:56:15AM -0500, Watson Ladd wrote: > On Wed, Nov 4, 2015 at 6:34 AM, Ilari Liusvaara > wrote: > > > > X25519 and X448 specifications say zero keys MUST be rejected (and > > the functions are also internally specified to clear the cofactor). > >

[TLS] #311 (remove early_data) - Potential deadlock?

I thought of following scenario: Client: ClientHello+0RTT Server: 0RTT rejected. Fallback to 1RTT. Server: (Drains 0-RTT records) Client: Finished (corrupted in transit) Client: Appdata (request for something) Server: (Drains corrupt finished as 0-RTT record) Server: (Drains appdata as 0-RTT