On Mon, Jul 19, 2021 at 12:38 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Hiya, > > On 19/07/2021 17:35, David Benjamin wrote: > > We need to*both* not add new tracking vectors*and* mitigate the > existing > > ones. Doing either one on its own is not useful. That means if the > existing > > mitigation for the existing vector applies just as well to this new > > feature, we have not added a new vector. > > I think that clarifies where we disagree, thanks - i'm > not convinced that our existing mitigations for tracking > via the web, or otherwise, are anywhere near sufficient. > I think you're still misunderstanding me. Let me try to phrase this better. By "existing" I mean "already written down in Fetch", and just talking about the TLS resumption component. I certainly don't mean to suggest the problem is done. Tracking via the web overall is a complex, evolving topic, with lots of folks working on it across the stack. Most of it is not relevant to low-level TLS state, except in recognizing that, because correlation is transitive, you can only solve it looking at the application as a whole. To bring this back to resumption, there is really only a single question to answer here: do you offer a session, negotiated in context A, over this new connection being established in context B? If you say yes, you potentially get a performance improvement, but you also allow contexts A and B to be correlated. Whether you are okay with that depends on the application, and is not something TLS can answer. What TLS needs to do is translate this TLS-level notion into things the application is worrying about. In this case, the deciding question is: do you mean for those two contexts to be correlated? If not, don't offer resumption. That is what this draft says, and it is what rfc8446 needed to say, but omitted. That omission has been corrected in rfc8446bis. Do you have other text in mind? There doesn't seem to be any other possible answer here, since there is only one decision to make in resumption. It's also one that clearly will continue working as we evolve and strengthen applications' privacy goals, including that of the web, since everything boils down to what contexts can and cannot be correlated. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
