> On May 18, 2018, at 2:42 AM, Martin Thomson <martin.thom...@gmail.com> wrote: > > We have potential downgrade attacks on a range of extensions, not just the > identified one. For instance, failing to provide the extended master > secret extension represents a fairly significant regression in capabilities > that could be indicative of an attack. The same for renegotiation info, > SCT, and others. I thought supported_versions might be a valid use, but > I'm not 100% sure there. The extension could reference itself though. > > A commitment to continue to provide a particular feature - as identified > via its extension - would be a potentially useful capability.
The same thought had already occurred to me, and I concluded that chain the extension is materially different in this respect from the others and the approach is not generally applicable. The difference is that the DNSSEC (DANE) chain introduces a new set of trust anchors, and so absent those trust anchors one might reach different conclusions about the authenticity of the peer. Presence or absence of such trust anchors for the server endpoint is authenticated via DNSSEC. The other extensions you mention operate within the same trust-anchor context whether present or absent. An attacker in possession of a forged certificate or a misappropriated private key is not thwarted by the requirement to present those extensions, can employ them at will, and can authenticate a reset of any previous "support lifetime". If the absence of a TLS extension makes it possible to impersonate the peer (without having suitable credentials), that extension should be mandatory in TLS. If the extension merely protects against chosen plaintext attacks (ala CRIME, BEAST, ...) then only the authentic server can downgrade itself, so we don't need a pin to require the extension. Which optional extensions militate server impersonation by an MiTM who does not have forged credentials or misappropriated keys? Does the above make sense? Am I missing a class of extensions that are needed to make sure the peer's authenticity is not compromised even in the absence of forged or stolen credentials? If such attacks are practical, why aren't the militating extensions mandatory? -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls