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

2021-08-01 Thread Yaron Sheffer
On 8/1/21, 03:59, "Uta on behalf of John Levine" wrote: It appears that Martin Thomson 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,

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

2021-08-01 Thread John R Levine
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 mit

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

2021-08-01 Thread Yaron Sheffer
On 8/1/21, 20:27, "John R Levine" 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

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

2021-08-01 Thread John R Levine
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. Mail sessions

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

2021-08-01 Thread Martin Thomson
On Sun, Aug 1, 2021, at 10:58, John Levine wrote: > 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. Curious, that's not how I read it. If you look, it's non-HTTP s