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

[Ilari Liusvaara <[e-mail]>]

On Sat, Feb 19, 2022 at 04:28:52PM -0500, Ryan Sleevi wrote:
> On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > > - Connection re-establishment affects the security and privacy
> > > assumptions and should be captured. I am not sure the concern is
> > > worse than the regular fingerprinting text already in the draft,
> > > but point taken. We can improve the text and I created an issue
> > > for it.
> > https://github.com/csosto-pk/tls-suppress-intermediates/issues/12
> >
> > Regarding security and privacy, the most severe impact of any attack
> > I can come up with is determining if some arbitrary ICA is on the
> > ICA list or not (for passive attacks, that is restricted to the issuing
> > ICA used by the server). Practical impact of attacker being able to do
> > that depends on how many endpoints share that same ICA list.
> >
> > Rough outline of the attack (active variant): Fabricate a certificate
> > purporting to be from some ICA, send it to client and observe if the
> > client retries (ICA not on the list) or just fails (ICA is on the list).
> 
> 
> I'm hopeful that some may be interested to perform a more thorough
> analysis. We saw enough complexity with respect to previous TLS versions
> and the fallback logic being possible to induce downgrade attacks that I
> think we should be very wary about introducing a class of anticipated
> handshake failures that require connection re-establishment, especially
> across independent TLS sessions. I realize that sounds a little like FUD,
> but rather: every time we've tried to do this, it's blown up spectacularly,
> so we need to make sure we're not setting up another bomb.

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 also think the active attack analysis is a bit lacking, especially since
> the attacker has the ability to mint arbitrary ICAs on demand, without
> running afoul of any existing client policies. For example, for the Web
> PKI, by virtue of nameConstraints without pathLen in the basicConstraints,
> the site can mint arbitrary ICAs and arbitrary EE certificates. Combined
> with the discovery mechanism discussed, this is effectively the same as
> other forms of stateful tracking (ala HSTS tracking), and thus likely to be
> subjected to the same mitigations that would largely render the benefits
> here ineffective, at best.

Having pathLen >= 1 would do as well, right?

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.

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.

Another defense to make reading ICA list harder would be to always
trigger fallback if certificate validation fails and ICAs were
suppressed.

Neither defense would render suppress ICAs ineffective, since in vast
majority of cases one can use quasi-static ICA list to buld verifiable
certificate chain and then use that with no fallback.



-Ilari