Re: [TLS] The progress about theNegotiated FFDHE proposal

On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: > Hi, > > Any one know why the negotiated FFDHE draft hang on MISSREF state for more > than 180 days? > > http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ Normatively depends on the false-start draft that isn't

[TLS] Encrypted SNI

Subject: SNI Encryption Part XLVIII Folks, TL;DR. This message describes a technique for doing SNI encryption that just requires (re)adding EncryptedExtensions to the client's first flight [0] defining an extension that indicates "tunnelled TLS" and (maybe) a new TLS content type. We would only

Re: [TLS] Encrypted SNI

On Sat, Dec 05, 2015 at 02:15:07PM -0500, Watson Ladd wrote: > I've got another question: how does the client know that the gateway > is supposed to be the gateway? As it stands it seems an attacker can > MITM the Gateway, and recover all SNIs. That's a whole lot different than passively reading

Re: [TLS] Would there be security issues with a 0-RTT resume?

On Sat, Dec 5, 2015 at 4:24 PM, Bill Cox wrote: > I am not sure why we have a 0-RTT connect, but only a 1-RTT resume. If > anything, it seems like it would be easier to have a secure 0-RTT resume > than a 0-RTT connect, though the 0-RTT connect does use some information

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

Watson Ladd writes: >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 rejects it when

Re: [TLS] Encrypted SNI

On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension

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

On 12/6/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>On 12/4/15, Peter Gutmann wrote: >>> Jacob Appelbaum writes: TCP/IP and DNS are out of scope, though obviously related. >>> Why are

Re: [TLS] Encrypted SNI

Can we embed an EncryptedExtension inside an existing EE? That would let us do TOR purely within TLS, right? You said “in the interest of explicit signaling” but I think you meant in the interest of avoiding that, right? I still think the “inner/real SNI” is simpler, but will have to think

Re: [TLS] Encrypted SNI

On 5 December 2015 at 12:32, Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII A small concern that probably is "No, that can't happen", but I would want to be sure that a normal (non-encrypted SNI) ClientHello would be unable to be wrapped in a new ClientHello to a

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

On Sat, Dec 5, 2015 at 8:18 PM, Peter Gutmann wrote: > Watson Ladd writes: >>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann >>wrote: >>> Hubert Kario writes: >>> miTLS does accept Application

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

Watson Ladd writes: >miTLS did not claim to be consistent with the RFC. Rather it claimed to be >secure, and to interoperate with most other implementations in circumstances >tested. The informal nature of the RFC makes it impossible to carry out >formal verification

Re: [TLS] Encrypted SNI

On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote: > On 5 December 2015 at 12:32, Eric Rescorla wrote: > > Subject: SNI Encryption Part XLVIII > > A small concern that probably is "No, that can't happen", but I would > want to be sure that a normal (non-encrypted