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

On 8/1/21, 03:59, "Uta on behalf of John Levine" <uta-bounces@ietf.org on behalf of johnl@taugh.com> wrote:

    It appears that Martin Thomson  <mt@lowentropy.net> said:
    >There is a piece missing. Yaron mentioned Alpaca. For that what we need to say is what Alexey might fear: application protocols
    >MUST define ALPN labels and use them.

    Well, you know, ALPACA is the predictable result of three decades of web browsers accepting any crud from
    broken web servers and trying to guess what it was supposed to mean.  It'd be more effective to say that browsers
    MUST send ALPNs and MUST NOT accept responses that don't send an expected ALPN back.  That's seems
    more likely to happen as people implement http/2 than that mail and IMAP and FTP servers that don't care about ALPNs will
    add them to defend against attacks that don't affect them.

[...]

    R's,
    John

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.

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.

Thanks,
	Yaron

    _______________________________________________
    Uta mailing list
    Uta@ietf.org
    https://www.ietf.org/mailman/listinfo/uta