Alt-Svc and Cert Pinning

[MikeBishop]

If http://www.example.com sends Alt-Svc pointing to evil.haxor.bg showing a cert from a hacked CA for the right origin, we don’t want to trust it. Cert pinning would mitigate this for https:// origins, and we could go a step further for https:// origins without pinning and validate that the cert on the alternate resembles the cert we last saw on the origin (identical cert, same issuer, same issuer country, etc.).

However, for http:// origins, we're pretty vulnerable. That scenario looks a lot like 9.2 again for http:// origins – if you’re MITM’d once, you can be MITM’d for as long as you trust the fishy cert.

[martinthomson]

The alternative needs to present credentials that are valid. That means that if the original requires pinning, then the alternative needs to present a certificate that is valid against the pin set.

Requiring that an alternative present an identical certificate would make this considerably less attractive.

[mnot]

Mike, is this really an issue, or just a question? Do you have proposed text?

[MikeBishop]

This is a concern that came up in our internal discussions. Reasonable text could range anywhere from general guidance that implementations might use caution in which certificates they accept to specific requirements on the cert, depending on the consensus of the rest of the group.

More generally, I think this is something a cautious implementation might do anyway, and if it's at least mentioned in the spec, origin operators will be more prepared for it than if it's strictly an implementation "quirk."

[mnot]

Discussed in Prague; need to add security considerations text explaining the potential attack and possible mitigations.

[mnot]

@MikeBishop, perhaps you could suggest some text?