This is one way to frame the problem. Another is that TLS is (1) typically only authenticated on the server side and (2) not cryptographically bound to the IP or port, the combination resulting in potential cross-protocol attacks. We as a community (inclusive of all protocols) are trying to mitigate this issue with whatever tools we have.
Noting that as far as I can tell 100% of the targets of ALPACA attacks are web browsers, this is a somewhat strained version of community. I suppose it possible someone might concoct an attack on a mail or FTP server but since they don't execute the stuff they receive, it'd be a whole lot harder.
Unfortunately I don't think your HTTP-only proposal can work, because in order to "expect" ALPN coming back from the server, a client would need to keep a long-term cache of ALPN-friendly servers. This is much more logic than just checking a received ALPN, either in HTTP or SMTP - which, as far as I can tell, is mostly done inside the TLS library.
Sure it can, you treat any responses from a server without an http ALPN with great scepticism. I realize this will be hard on the long tail of web servers, but it does give them an incentive to upgrade, like it did when we stopped accepting SSLv3.
To put it another way, why is the solution for every non-web server to upgrade, rather than for every web server to upgrade? I'm not opposed to adding ALPNs to other servers when we do routine upgrades, but "you urgently have to solve our problem" is not a compelling arguent.
R's, John _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
