On 8/1/21, 20:27, "John R Levine" <jo...@taugh.com> 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.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
