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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Jul 2021 14:31:29 +0100

Hi,

Section 3.8 of the draft says:
    TLS implementations (both client- and server-side) MUST support the
    Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].

This looks fine to me. I assume it is still up to application protocols 
to decide whether or not use of ALPN is required? I am thinking of email 
and I can't see a use case where, for example, an IMAP server would 
share the same IP/port number with another protocol. Or is the point of 
this is to prevent an IMAP client talking to a non IMAP server, as well 
as to prevent a non IMAP client talking to an IMAP server?

Thank you,

Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2021 08:19:01 -0600

Hi Alexey!

On 7/28/21 7:31 AM, Alexey Melnikov wrote:
> to decide whether or not use of ALPN is required? 

Yes. This text could be phrased more clearly: implementations of TLS
itself must support the ALPN extension, but application protocols can
choose to support ALPN or not.

Peter

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jul 2021 17:27:23 +0300

Hi Akexey,

This is about different protocol servers sharing the same IP, but *not* the same port. There's nothing to bind the encrypted TLS connection to a particular port, and that's the problem addressed here - an IMAP client being forced to talk to an FTP server. Obviously you can have IMAP on one port of a given server, SMTP on another, and FTP on a third.

Please read https://alpaca-attack.com/ if you haven't yet, it's fun reading.

Thanks,
	Yaron

On 7/28/21, 16:32, "Uta on behalf of Alexey Melnikov" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Thank you,

    Alexey

    _______________________________________________
    Uta mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/uta

---

From: Grant Taylor <[email-masked]>
Date: Wed, 28 Jul 2021 11:23:50 -0600

On 7/28/21 8:27 AM, Yaron Sheffer wrote:
> This is about different protocol servers sharing the same IP, but*not* 
> the same port. There's nothing to bind the encrypted TLS connection 
> to a particular port, and that's the problem addressed here

Is there something that binds the encrypted TLS connection to a 
particular IP?

What if the certificate & key is used on multiple IPs on the same or 
different systems?  Won't the same problem exist?

-- 
Grant. . . .
unix || die

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jul 2021 21:16:04 +0300

Yes, of course it would.

Thanks,
	Yaron

On 7/28/21, 20:24, "Uta on behalf of Grant Taylor" <[email-masked] on behalf of gtaylor=[email-masked]> wrote:

    -- 
    Grant. . . .
    unix || die

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 01 Aug 2021 09:42:10 +1000

> choose to support ALPN or not.

I know that this what you are trying to say, so I am not disagreeing, but...

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 01 Aug 2021 09:43:12 +1000

There is no binding to an IP or port.  The only relevant binding here is to a TLS connection.

On Thu, Jul 29, 2021, at 04:16, Yaron Sheffer wrote:
> Yes, of course it would.
> 
> Thanks,
> 	Yaron
> 
> On 7/28/21, 20:24, "Uta on behalf of Grant Taylor" 
> <[email-masked] on behalf of 
> gtaylor=[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2021 20:58:44 -0400

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

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.  (They weren't useful for ALPACA
anyway since I don't run mail and web servers with the same domain name but it's the thought that counts.)

R's,
John