Re: [TLS] PR ¤468: Cookie for hrr

On Sun, May 22, 2016 at 1:48 PM, Ilari Liusvaara wrote: > On Sun, May 22, 2016 at 12:50:38PM -0700, Eric Rescorla wrote: > > On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > On Sun, May 22, 2016 at 11:30:10AM -0700,

Re: [TLS] PR ¤468: Cookie for hrr

On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara wrote: > On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > Actually, looking at it, I didn't find how

[TLS] TLS 1.3 draft 13.

Folks, I just uploaded draft-13. Changelog appended at the bottom of this message. The following nontrivial issues are outstanding: - How to encrypt post-handshake messages (post-handshake client auth, NewSessionTicket, etc.). I'm having a discussion now with the cryptographers about this.

[TLS] I-D Action: draft-ietf-tls-tls13-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename

Re: [TLS] PR ¤468: Cookie for hrr

On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara > wrote: > > > Actually, looking at it, I didn't find how EDI context is > > determined. And EDI context needs to be fit into cookies because > > it isn't

Re: [TLS] PR ¤468: Cookie for hrr

On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara wrote: > On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote: > > On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > Looking at PR #468: > > > - It isn't at all

Re: [TLS] PR ¤468: Cookie for hrr

On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara > wrote: > > > Looking at PR #468: > > - It isn't at all obvious how to use it for stateless rejection. > > - It is even less obvious how to recover (not

Re: [TLS] PR ¤468: Cookie for hrr

On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara wrote: > Looking at PR #468: > - It isn't at all obvious how to use it for stateless rejection. > - It is even less obvious how to recover (not causing non-retryable > fault) from bad cookie (e.g. expired) remembered

Re: [TLS] Issue 471: Relax requirement to invalidate sessions on fatal errors

This still makes the *stateful* implementation much more deterministic and those implementations are common enough. So how about: Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may