Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Viktor Dukhovni <[e-mail]>]

> On Apr 5, 2018, at 10:20 AM, Eric Rescorla <[e-mail]> 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.