[Uta] Dealing with STARTTLS Stripping

[Aaron Zauner <[e-mail]>]

Hi,

During the UTA meeting pinning/HSTS for STARTTLS protocols came up
again. I think it's important to discuss how to mitigate active attacks
on these protocols. I, too, think this should be separate from the
current DEEP draft.

I don't believe this should be done via DNS.

Just an idea (might not be the most favorable/elegant approach) for e.g.
SMTP: SMTP servers could announce an extension 'NOSTRIP'. Where NOSTRIP
offers a structure similar to HSTS/HPKP [0][1] which clients cache
locally. Instead of re-inventing the wheel for key-pinning specific to
STARTTLS protocols we could require use of TLS TACKs instead [2].

In the case of an established plaintext connection the connection must
be upgraded via STARTTLS immediately - a valid certificate for the
service presented and NOSTRIP information re-queried by the client and
thus re-sent by the server. I.e. an attacker could inject NOSTRIP but
that would only result in permanent protocol-upgrade or connection failure.

What do you guys think?
Aaron

[0] https://tools.ietf.org/html/rfc6797
[1] https://tools.ietf.org/html/rfc7469
[2] https://datatracker.ietf.org/doc/draft-perrin-tls-tack/