Re: [TLS] Encrypting record headers: practical for TLS 1.3

> > If Akamai wants to leave their users insecure, I look forward to > another CDN offering privacy options. Such choice is missing if that > isn't an option and it isn't on as a strong default. The NSA has contracts with ISPs to have access to their user's content. Is a CDN an ISP?

Re: [TLS] Data volume limits

How often does TLS rekey anyway? I know RC4 rekeys per packet, but I've read and searched a fair amount of documentation, and haven't found anything on the subject. Perhaps I'm looking for the wrong terms or through the wrong documents. ___ TLS mailing li

[TLS] Enforcing Protocol Invariants

Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe we should ask Google. The SSHFP DNS record exists. DNSSEC exists. This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record. In another DNS TXT record, a list of supported protoco

Re: [TLS] Enforcing Protocol Invariants

I think I have implied that ClientHello is unneccesary to an extent, it can be replaced by a DNS TXT record. I think I implied that self-signed certificates are acceptable given the precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence of DNS spoofing attacks against a CA?). I

[TLS] Enforcing Protocol Invariants

On Thursday, November 8, 2018, Eric Rescorla wrote: > It's also worth noting that in practice, many sites are served on > multiple CDNs which do not share keying material. > > Encrypting common knowledge is cargo cult fetishism for cryptography. The files could be sent unencrypted, and protected

Re: [TLS] Enforcing Protocol Invariants

Okay, a modern browser connecting to a server owned by billion dollar corporations are able to implement the latest version of TLS, I’ll concede that. Regardless, I can only underline one point: any new protocol needs to break both compatibility and be downgradable, and require a small amount of co

Re: [TLS] Industry Concerns about TLS 1.3

> > The impact on supervision will be particularly severe. Financial > institutions are required by law to store communications of certain employees > (including broker/dealers) in a form that ensures that they can be retrieved > and read in case an investigation into improper behavior is initi

Re: [TLS] Industry Concerns about TLS 1.3

I've never quite understood what TLS was supposed to be protecting against, and whether or not it has done so successfully, or has the potential to do so successfully. Well, I don't think anyone here even knows how to protect a mailing list from multi-billion dollar threat actors so...??? Let me

Re: [TLS] Industry Concerns about TLS 1.3

On Sat, Oct 1, 2016 at 4:23 AM, Peter Gutmann wrote: > Ryan Carboni writes: > > >I've never quite understood what TLS was supposed to be protecting > against, > >and whether or not it has done so successfully, or has the potential to > do so > >successfully. &

[TLS] How should inability to access key revocation lists impact the TLS handshake?

How should inability to access key revocation lists impact the TLS handshake, if previous public keys and/or certificate hashes are not cached? I cannot see this in the standard. Considering that all one has to do is DDOS a certificate authority nowadays...