On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara <ilariliusva...@welho.com> 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 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
