Re: [TLS] Simpler backward compatibility rules for 0-RTT
There are also very common cases of using multiple CDNs or server farms with different capabilities but with the same host name, or of switching a live site between platforms. As others have mentioned, the behaviors need to be well defined and result in extra rtt rather than hard failure to allow 0rtt to be safely deployable. - Erik On Jun 22, 2016 5:58 AM, "Martin Thomson" wrote: On 22 June 2016 at 12:01, Watson Ladd wrote: > Why isn't 0-RTT an extension in the Client Hello to deal with this? You can't stream extensions, which unfortunately is required given how most software interacts with their TLS stack. Let's be clear, the actual risk we're talking about is pretty-much confined to screw-ups. The deployment screwup where you left one server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS MitM, which calling a screw-up might be too positive a statement. Of course, David is right that screw-ups like this are too common for us to do nothing about them. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Remove EncryptedExtensions from 0-RTT
Was there a compelling reason to not just put the ticket age in the clear in the CHLO field as @davidben alluded to before. It seems to make it much simpler in general. With support for multiple tickets the server could issue multiple tickets at different times to make time correlation more difficult. The ticket seems to be a more definitive identifier of the user than the time. Subodh From: TLS [tls-boun...@ietf.org] on behalf of Martin Thomson [martin.thom...@gmail.com] Sent: Thursday, June 23, 2016 1:59 PM To: David Benjamin Cc: tls@ietf.org Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT On 24 June 2016 at 01:05, David Benjamin wrote: > I don't think this matters. Just don't reuse tickets. But, if we cared, per > the "dumbest possible thing that might work" school of thought, we can > replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta > between two ClientHellos, which, precision aside, was already public > information from the receive time (with ticket as correlator). The timestamp > of the ticket-minting connection is as secret as before. That sounds like fine reasoning to me. XOR or addition are both easy enough to specify. ___ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=ryrz7HkNEVNbEb9yKsanQ1ZrOyiVdYuv8BDMJOF55s0&s=ftTVBbImgxjUem3AV87OqX3q_RKQKE1SJ7SGePOhWyc&e= ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
