Subject: [ietf-smtp] ALPN

From: Jeremy Harris <[email-masked]>
Date: Thu, 8 Jul 2021 00:11:31 +0100

Should we request a TLS ALPN identifier?

Current registry:
   https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

Draft recommendation:

   draft-ietf-uta-rfc7525bis-01.txt
   - Section 5 "Applicability Statement" lists "SMTP traffic".
   - Section 3.8 "Application-Layer Protocol Negotiation" says that the TLS
     must support - but nothing is said about the application layer actually
     making use.

Implementing a defensive-only ALPN check (refusing a TLS startup, as
server, if anything but the obvious choice of "smtp" is offered as a
requested ALPN by the client) is not hard coding for either OpenSSL
or GnuTLS.  Locking out retries with downgrade to cleartext would be
more effort, but perhaps not relevant as a defence against the ALPACA
attack.

In client MTA mode I'd expect the coding to make an ALPN request to
be similarly simple. Administrative controls for non-use/offer/require-acceptance
would probably be more work than just the library interface.
-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 8 Jul 2021 22:51:16 -0400

>Should we request a TLS ALPN identifier?

Maybe we should request two, one for SMTP and one for SUBMIT.

I asked one of the draft's authors if he knows why POP and IMAP have ALPNs
and SMTP doesn't.

I do worry about getting the ALPNs right in the common case that the same host
offers SMTP, SUBMIT, POP, and IMAP.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Jul 2021 01:32:34 -0400

> On 8 Jul 2021, at 10:51 pm, John Levine <[email-masked]> wrote:
> 

It is not uncommon for SOHO domains to relay outbound mail via a
provider submission server.

Some care may be needed to make sure that MTAs acting as submission
clients know to use the right ALPN for "SUBMIT".  This means that
MTAs should avoid defaulting the ALPN to "SMTP" on ports other than
25, likely sending no "ALPN" unless configured explicitly by the
administrator.

-- 
	Viktor.

---

From: Claus Assmann <[email-masked]>
Date: Sat, 10 Jul 2021 07:41:51 +0200

> Maybe we should request two, one for SMTP and one for SUBMIT.

Is it worth the hassle? What problem does that solve?  Isn't one
for SMTP enough to resolve the potential protocol attacks?

-- 
Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.

---

From: "John Levine" <[email-masked]>
Date: 10 Jul 2021 17:43:56 -0400

>for SMTP enough to resolve the potential protocol attacks?

I dunno.  It's not immediately obvious what the problem would be
to share the same ALPN among all four mail applications, SMTP,
SUBMIT, IMAP, and POP.

---

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

> to share the same ALPN among all four mail applications, SMTP,

I think having separate allocations for them would be clean design.

However, ALPN seem to be intended for multiple protocols sharing the 
same IP/port. This doesn't seem to apply to SMTP/SUBMIT/IMAP/POP. Or am 
I missing the point of ALPN?

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 28 Jul 2021 14:25:48 +0100

On 28/07/2021 14:14, Alexey Melnikov wrote:
> However, ALPN seem to be intended for multiple protocols sharing the same IP/port. This doesn't seem to apply to SMTP/SUBMIT/IMAP/POP. Or am I missing the point of ALPN?

At least one use, tangential to that RFC-suggested is protection
against malware.  I am already logging rejections by an MTA on 465
of connections attempting to use a non-mail-related ALPN.

I agree that implementing such checking does not require a
formal allocation of an ALPN for mail - but allocating one
would not preclude it either.
-- 
Cheers,
   Jeremy

---

From: Claus Assmann <[email-masked]>
Date: Wed, 28 Jul 2021 19:26:31 +0200

> I think having separate allocations for them would be clean design.

Stupid question: what are the differences in the actual protocol
between SMTP and SUBMIT?

> However, ALPN seem to be intended for multiple protocols sharing the same
> IP/port. This doesn't seem to apply to SMTP/SUBMIT/IMAP/POP. Or am I missing
> the point of ALPN?

A possible hack is to redirect a HTTP connection to an SMTP server:
different ports / different protocols.
ALPN is supposed to prevent such "cross protocol" attacks.

Hence my question above: if there's no difference at the protocol
level, what would we gain having two different ALPN ids for SUBMIT
and SMTP?

Has anyone already applied at least for an id for SMTP?

Would it be as simple as this:

To: [email-masked]
Subject: Request to register value in TLS Extensions: SMTP for ALPN

Please add SMTP to the list of
TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
(this might have been requested by someone already?)

See also:

---

From: "John R Levine" <[email-masked]>
Date: 28 Jul 2021 14:00:16 -0400

> IP/port. This doesn't seem to apply to SMTP/SUBMIT/IMAP/POP. Or am I missing 

I took another look and as far as I can tell, ALPN does two things.  The 
original motivation was to allow http/1 and http/2 on the same port even 
though http/2 isn't backward compatible with /1.  The ongoing motivation 
is to allow every possible protocol to run on port 443 so they can get 
through firewalls.

I think an ALPN for SUBMIT would make sense since it is somewhat common to 
run a submit-ish server on a non-standard port when your mail server is 
behind a spam filtering proxy or the like.  Since SMTP only does STARTTLS, 
by the time there was an ALPN negotiation it's too late.

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

---

From: "John Levine" <[email-masked]>
Date: 28 Jul 2021 23:07:40 -0400

>Stupid question: what are the differences in the actual protocol

The port numbers, and the fact that 465 does TLS on connnect.  Other than that, nothing.

Since SMTP doesn't do TLS on connect I have trouble imagining an attack that an ALPN
wouldn't 

>ALPN is supposed to prevent such "cross protocol" attacks.

You can certainly point a browser at http://your.ser.ver:25/something but again
I have trouble imagining an actual threat, and even more trouble imagning
one where an ALPN would make any difference.

R's,
John

---

From: Claus Assmann <[email-masked]>
Date: Thu, 29 Jul 2021 06:46:32 +0200

> one where an ALPN would make any difference.

Isn't this what "ALPACA" is about?
htttps://alpaca-attack.com/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Jul 2021 08:39:08 +0200

On Thursday 29 July 2021 06:46:32 CEST, Claus Assmann wrote:
> htttps://alpaca-attack.com/>

ALPN defends against that attack by making other ALPNs different from what 
code running on the VM inside a web browser requires.

In this case, we're talking about whether there is one different ALPN or 
four. Either case suffices to protect email servers from being involved in  
attacks against web browsers.

Four means that a malevolent server cannot fool code that expects to 
connect to an IMAP server into connecting to an SMTP server and revealing 
secrets (e.g. by sending an APPEND command). But IMAP clients don't run 
server-supplied code, and don't contain VMs that could protect against 
malevolent server-supplied code by checking ALPN.

I like having one ALPN identifier rather than four, since it requires a 
smaller change to email clients that share/reuse code for using TLS within 
different protocols,

Arnt

---

From: Claus Assmann <[email-masked]>
Date: Thu, 29 Jul 2021 09:02:30 +0200

> four. Either case suffices to protect email servers from being involved in

Since there are already IDs for IMAP and POP3, it seems we are down to
3 (+SMTP) or 4 (+SUBMIT) unless we want to break existing applications?

> smaller change to email clients that share/reuse code for using TLS within

In my code it's just some "context" that is passed to the proper
functions. The "main" problem is to select the right context, esp.
if things are highly configurable (some people might want to run
smtps on a different port).

---

From: "John Levine" <[email-masked]>
Date: 29 Jul 2021 14:57:12 -0400

>3 (+SMTP) or 4 (+SUBMIT) unless we want to break existing applications?

Given that clients often don't know whether they're talking to an SMTP or a submission
server, and servers don't know which one they are or maybe both, one ALPN would be plenty.

It's still pretty common for a server to offer SMTP on port 25, which turns into submission
if the client authenticates.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Jul 2021 00:46:09 -0400

> >3 (+SMTP) or 4 (+SUBMIT) unless we want to break existing applications?

I'd prefer to see "SUBMIT" as a separate ALPN value from "SMTP".

> server,

In fact they almost always do, because "SUBMIT" generally requires
authentication, and SMTP relay does not, and the separate ports also
help.

> and servers don't know which one they are or maybe both, one ALPN would be plenty.

Submission servers are explicitly configured to accept outbound mail,
and it has been best practice for quite some time to not implement
submission on port 25, leaving that to 587, and more recently also 465.

> It's still pretty common for a server to offer SMTP on port 25, which
> turns into submission if the client authenticates.

This is a no longer recommended and diminishing practice.

    - An MUA can always use the "SUBMIT" ALPN value.

    - An occasional MTA that is configured to relay outbound mail
      via a submission server, and has been updated to use ALPN,
      can be configured to use "SUBMIT" when appropriate.

-- 
    Viktor.

---

From: Ned Freed <[email-masked]>
Date: Fri, 30 Jul 2021 06:56:57 -0700 (PDT)

> I'd prefer to see "SUBMIT" as a separate ALPN value from "SMTP".

As would I. A clean separation is always a good idea.

>       can be configured to use "SUBMIT" when appropriate.

I also don't see how this practice, which I agree is diminishing, is especially
relevant to ALPN assignment. If you really want to do this in an ALPN context -
I have no idea why - you can always use the SMTP ALPN to do it.

				Ned