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

[Yaron Sheffer <[e-mail]>]

On 8/1/21, 20:27, "John R Levine" <[e-mail]> wrote:

    > 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.

YS: some of the attacks do not depend on the client executing JavaScript, but rather on the use of cookies (bearer tokens) which can be intercepted/logged/uploaded on the server side. I don't know of bearer tokens being used in SMTP, but it doesn't look like an HTTP-only notion.

    > 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.

YS: I don't know how to implement "great scepticism"... Specifically, if you have a human in front of a web browser maybe you could use UI indicators, but what do you do if the client is a script calling a REST API?

    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.

YS: Agreed. My own expectation is that the TLS BCP (like other non-urgent security upgrades) will be applied during routine upgrades. Compare enterprise-wide SHA-1-to-SHA-256 migration projects.