On 8/1/21, 03:59, "Uta on behalf of John Levine" <uta-boun...@ietf.org on
behalf of jo...@taugh.com> wrote:
It appears that Martin Thomson <m...@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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
