On Fri, Feb 25, 2022 at 11:17 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> I have hard time seeing how one could construct downgrade attack out of > this, as it just requests extra data from server on fallback. For most > other retry stuff, downgrade attack risk is obvious as less secure modes > are introduced / more secure modes are removed. I think I’m raising a question about whether or not implementations will actually do this, and arguably, to explicitly specify this if this is the expectation. In theory, yes, if the only thing changing in a fallback is an optional flag, it “shouldn’t” have concerns. In practice, however, these sorts of fallbacks (e.g. various server bug workarounds) introduce compositions that cause new and unexpected interactions. This is why the ecosystem has tried very hard to avoid fallbacks (c.f. TLS 1.3) and ensuring that both parties are able to commit to the negotiation. We saw this with the renegotiation issues getting confused state from the initial handshake. Having pathLen >= 1 would do as well, right? Sure, “without pathLen constraints” And such ICAs can already be abused for tracking if the browser does > transvalidity. Suppress ICAs flag would make it worse, by allowing other > sites to read such tracking supercookies. Transvalidity was never something widely supported outside of a specific product/library (Mozilla NSS). But yes, this is the point: this feature gives a much stronger signal. Defense is not doing transvalidity nor cached AIA chasing (since those > caches represent state that could be attacked). This closes the attack > for both with and without suppress ICAs. I fail to see how it closes it without suppress ICAs, particularly because the current draft very explicitly suggests caching as a possibility. And yes, implementations that wish to mitigate cross-context tracking are working to isolate those caches, and this was my point: doesn’t this isolation defeat the benefits of the caching / the likelihood of intermediate omission succeeding, and functionally mean that there needs to be a reliable, semi-real-time distribution mechanism for intermediates to achieve the benefits? I’m trying to look at this from a systems perspective, and tease out explicitly: what is this solution assuming exists in order to achieve the desired effect, and with those assumptions, are there simpler/less-risky/alternative technical solutions? Not to bikeshed, but because the design assumptions here are unstated and have practical and meaningful ecosystem effect, and so we at least owe that much.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
