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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 01 Aug 2021 17:01:52 +0300

On 8/1/21, 03:59, "Uta on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

    It appears that Martin Thomson  <[email-masked]> 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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/uta

---

From: "John R Levine" <[email-masked]>
Date: 1 Aug 2021 13:27:50 -0400

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

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

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.

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.

R's,
John

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 01 Aug 2021 21:58:08 +0300

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.

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?

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.

---

From: "John R Levine" <[email-masked]>
Date: 1 Aug 2021 15:16:07 -0400

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

Mail sessions have very little context, and none from one session to the 
next.  You can send multiple messages in a session but the only thing the 
session remembers is the set of features offered by the server at the 
start of the session.

POP, IMAP, and SUBMIT all use SASL authentication before you can do 
anything interesting, but I don't immedately see how ALPACA would take 
advantage of that.

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

Beats me.  What happens if the REST API uses a server that only speaks SSLv3?

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

OK, but don't get your hopes up.  DKIM mail authentication has been 
telling people to use SHA-256 since we published the original DKIM spec in 
2007, and we formally deprecated SHA-1 in RFC 8301 in January 2018.  I 
just counted the signatures on mail I've gotten since the beginning of the 
year:

sha-256 9141
sha-1 1479

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 02 Aug 2021 10:44:16 +1000

On Sun, Aug 1, 2021, at 10:58, John Levine wrote:
> 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 servers accepting 11-17 lines of HTTP garbage and still carrying on to produce a response that is technically valid HTTP.  HTTP handling in browsers is pretty heavily regulated.  While it is unfortunate that HTTP/0.9 compatibility is still necessary and that tends to lead to more tolerance of errors than is ideal, I don't attribute this error solely to browsers.

> 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 is exactly what they do, which is also what RFC 7301 states.  The problem is that some servers don't implement ALPN support.  And those servers often can't as a result of there not being an ALPN defined for that protocol.

> I made my mail servers a lot less useful for that particular hack by 
> adjusting them to drop the connection after
> any bad command since real mail clients never send bad commands.  

Yeah, tolerance of bad inputs is an anti-feature for a networking protocol.