Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Ryan Sleevi <[e-mail]>]

On Fri, Feb 25, 2022 at 11:17 AM Ilari Liusvaara <[e-mail]>
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.