Re: [TLS] Encrypted SNI

> I'm not sure I understand the design you're suggesting. Does the EncryptedExtensions contain the entire hello for the "next hop"? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Saturday 05 December 2015 23:54:25 Peter Gutmann wrote: > Hubert Kario writes: > >miTLS does accept Application Data when it is send between Client > >Hello and Client Key Exchange and rejects it when it is sent between > >Change Cipher Spec and Finished. > > Given that

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

Our state machine design in miTLS was quite deliberate, and based on our interpretation of the TLS 1.2 spec. It is possible that we got this interpretation wrong, but maybe the protocol authors can clarify the intended behavior. However, I think that looking at the Handshake protocol message

Re: [TLS] Encrypted SNI

On Sun, Dec 6, 2015 at 6:46 AM, Salz, Rich wrote: > > I'm not sure I understand the design you're suggesting. > > Does the EncryptedExtensions contain the entire hello for the "next hop"? > No. It (at most) says "the stuff that is post-handshake is actually a ClientHello for

Re: [TLS] Forward secrecy with resumption, and 0-RTT security

On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > AFAIK, there has never been a session resumed with forward secrecy. Is > this correct? > Yes, session resumption does not have PFS. Though note that with 1.3 that will no longer be true, because you can do PSK-DHE. >

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Saturday 05 December 2015 19:20:11 Watson Ladd wrote: > On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann wrote: > > Hubert Kario writes: > >>miTLS does accept Application Data when it is send between Client > >>Hello and Client Key Exchange and

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On Sunday 06 December 2015 02:33:39 Peter Gutmann wrote: > > No matter how you colour it, accepting > Application Data after a Client Hello is wrong. Is there any random, > non-formally-verified implementation that would do that? The discussion is about renegotiated handshakes, and yes there is

Re: [TLS] Encrypted SNI

On 12/6/15, Dave Garrett wrote: > On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote: >> Can we embed an EncryptedExtension inside an existing EE? That would let >> us do TOR purely within TLS, right? > > If clients are allowed to send any encrypted extensions

Re: [TLS] Forward secrecy with resumption, and 0-RTT security

On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: > In the past, there were two cases: resumption using session IDs, and > resumption with session tickets. Using session IDs loses forward secrecy, > because the server always has session keys in a session cache, which could

Re: [TLS] Forward secrecy with resumption, and 0-RTT security

Just how strict do we want to be with forward secrecy? The choices I see are: 1) Avoid 0-RTT connections, and do only 1-RTT connections when we want strict forward secrecy and strong client authentication 2) Keep server-side state for decrypting each ticket, and issue new tickets on each

Re: [TLS] Forward secrecy with resumption, and 0-RTT security

On Sun, Dec 6, 2015 at 11:39 AM, Eric Rescorla wrote: > With PSK-DHE over 0-RTT, would we use the static DHE server share for the >> first resume flight? >> > > No. In All PSK-DHE modes, the PSK is used as SS. > That's cool. I need to re-read the spec more carefully. > >>

Re: [TLS] Forward secrecy with resumption, and 0-RTT security

On Sun, Dec 6, 2015 at 8:17 AM, Bill Cox wrote: > On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla wrote: > >> On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote: >> >>> AFAIK, there has never been a session resumed with forward secrecy.