Re: [TLS] Security review of TLS1.3 0-RTT
Sure, those are fine weasel words. But do we really want to allow into this protocol something that can be misused with security implications in a protocol that’s attempting to solve a security problem? I really don’t know. I’m inclined to say, ‘no’ though. For all those same reasons that IPsec provides replay detection, I think TLS should too. Derrell > On May 4, 2017, at 4:00 PM, Erik Nygren wrote: > > "The onus is on clients not to send messages in 0-RTT data which are not safe > to have replayed and which they would not be willing to retry across multiple > 1-RTT connections. The onus is on servers to protect themselves against > attacks employing 0-RTT data replication." > > The server responsibility is a general property TLS can maintain while the > client responsibility requires an application profile to define. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Idempotency and the application developer
> On May 4, 2017, at 5:35 PM, Watson Ladd wrote: > > 0-RTT is opt-in per protocol …and at the end of the day, that’s the only reason I’d agree to this. Derrell ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] datacenter TLS decryption as a three-party protocol
> On Jul 19, 2017, at 6:02 PM, Yoav Nir wrote: > > At the very least, a standards-track multi-party protocol like that can be > something that standards like PCI, HIPAA and others can latch on to and say > “Do TLS 1.3 without backdoors unless you really need to and in that case use > *this*”. > > That is better guidance than “Do TLS 1.3 without backdoors, unless you really > need to and in that case do whatever works for you” Yes, that’s what I would like to see after today’s meeting too.___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
