Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

[John R Levine <[e-mail]>]

> 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