> On Apr 5, 2018, at 10:20 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
> Yes, so quite possibly I need to upgrade my entire server farm, which might
> be running
> on some software which has no version which implements this extension. This
> could
> be an enormous effort.
Yes, module hijack. The same applied with STS, if the server farm had no TLS
support,
or insufficient capacity to handle the load with TLS. This is not substantially
different, other than that TLS support is fairly mainstream now.
Note that the hijack would also need obtain WebPKI certificates (as I would
expect
DANE for browsers to insist on the restrictive PKIX-TA(0) / PKIX-EE(1)). So the
that would be a full takeover of the domain, and the affected clients would have
to have visited the hijacked site during the time it was controlled by the
malicious
party.
Note also that clients that support the extension will also be rare for some
time,
so the impact of any hijack that improbably pins the extension will be modest.
So, if some users running early adopter browsers that support the extension have
to manually clear the pin after a domain hijack, and visiting the hijacked site,
potentially disclosing sensitive information to the wrong party, etc. then
becoming
aware of that when the browser warns them about missing extension support seems
like
a feature and not a bug. They can and probably should contact the legitimate
site's
help desk and figure out what to do to secure their account, change passwords,
...
This scenario is not impossible, but a rather low risk, and would initially, as
server support ramps up, affect few users. The pin can be cleared by the user
in such a situation, and having the user be aware of the fact that he/she
visited
a hijacked site is not a bad thing.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
