Subject: [Emailcore] Ticket #54 - Authentication and Encryption for A/S - Rev. 4

From: Todd Herr <[email-masked]>
Date: Tue, 22 Mar 2022 10:29:43 -0400

Greetings.

I've reviewed the comments generated by my posting rev 3 here at the end of
January, and I've incorporated some of them.

The one that I didn't incorporate was one that Dave Crocker made to perhaps
discuss the concepts of Channel Security versus Object Security in section
5.5, Message-Level Confidentiality. While I thought the suggestion had
merit on its face, the fact that the section is just a paragraph talking
about how OpenPGP and S/MIME (and similar technologies) are out of scope
for the A/S made me decide not to add more text to this section.

Current revision follows, there's a place in the agenda to discuss it
during Friday's meeting.

=========================== cut here ========================

A/S Proposed Text - Confidentiality and Authentication

5. Confidentiality and Authentication with SMTP

SMTP is specified without embedded mechanisms for authentication or
confidentiality; its traffic is therefore “in the clear”. Years of
operational experience have shown that such transmission exposes the
message to easy compromise, including wiretapping and spoofing. To mitigate
these risks, operation of SMTP has evolved over the years so that it is
used with the benefit of Transport Layer Security (TLS - RFC8446) to
provide both confidentiality and authentication in the transmission of
messages. This section discusses those topics and their most common uses.

It is important that the reader understand what is meant by the terms
“Authentication” and “Confidentiality”, and for that we will borrow
directly from RFC8446.

   -

   Authentication is the process of establishing the identity of one or
   more of the endpoints of a communication channel. TLS only requires
   authentication of the server side of the communication channel;
   authentication of the client side is optional.
   -

   The term “confidentiality” describes a state where the data (i.e., the
   message) is transmitted in a way that it is only visible to the endpoints
   of a communication channel.

It is not uncommon for implementers to use the term “encryption” to mean
“confidentiality”, but this is not quite correct. Rather, encryption using
TLS is the current method by which confidentiality is achieved with SMTP,
but that does not mean that future methods might not be developed.

Note: With typical email use of TLS, authentication only is performed by
the sending client of the target receiving server. That is, it serves to
validate that the connection has been made to the intended server, but does
not validate who initiated it.

5.1 Optional Confidentiality

The most common implementation of message confidentiality is what’s known
as “opportunistic TLS”, which is frequently referred to as “opportunistic
encryption”. With this method, a receiving server announces in its greeting
that it is capable of supporting TLS encryption through the presence of the
“STARTTLS” keyword. The sending client then attempts to negotiate an
encrypted connection, and if successful, transmits the message in encrypted
form; if negotiation fails, the client falls back to sending the message in
clear text.

Opportunistic TLS is confidentiality without authentication, because no
effort is made to authenticate the receiving server, and it is optional
confidentiality due to the ability to fall back to transmission in the
clear if a secure connection cannot be established. That said, most modern
implementations of SMTP support this method, especially at the largest
mailbox providers, and so the vast majority of email traffic is encrypted
during its time transiting from the client to the server.

Note: While TLS provides protection while the message is in transit for a
single SMTP connection, a message that is encrypted for one SMTP hop might
not be encrypted on the next hop and it might not be encrypted within the
MTAs relaying the message or at its destination. In fact, storage in plain
text should be expected!

5.2 Required Confidentiality, with Receiving Server Authentication

Two protocols exist that move message confidentiality from optional to
required (with conditions as noted below) - MTA-STS [RFC8461] and DANE for
SMTP [RFC7672]. While they differ in their implementation details,
receiving servers relying on either protocol are stating that they only
accept mail if the transmission can be encrypted with TLS, and a failure to
negotiate a secure connection MUST result in the sending client refusing to
transmit the message.

These two protocols differ from Opportunistic TLS in that they require
receiving server authentication and there is no fallback to sending in the
clear if negotiation of an encrypted connection fails.

Note: Both protocols mentioned in this section rely not only on the
receiving server but also the sending client supporting the protocol
intended to be used. If the sending client does not implement or understand
the protocol requested by the receiving server, the sending client will use
Opportunistic TLS or clear-text to transmit the message.

5.3 Message-Level Authentication

Protocols exist to allow for authentication of different identities
associated with an email message - SPF [RFC7208] and DKIM [RFC6376]. A
third protocol, DMARC [RFC7489], relies on SPF and DKIM to allow for
validation of the domain in the visible From header, and a fourth, ARC
[RFC8617], provides a way for each hop to record results of authentication
checks performed at that hop.

All of these are outside the scope of this document, as they are outside
the scope of SMTP. They deal with validating the authorized usage of one or
more domains in an email message, and not with establishing the identity of
the receiving server.

5.4 SMTP Authentication

SMTP Authentication, which is often abbreviated as SMTP AUTH, is an
extension to SMTP. Its name might suggest that it would be within scope for
this section of the Applicability Statement, but in fact it’s not.

SMTP AUTH defines a method for a client to identify itself to a Message
Submission Agent (MSA) when presenting a message for transmission, usually
using port 587 rather than the traditional port 25. The most common
implementation of SMTP AUTH is for a person to present a username and
password to their mailbox provider’s outbound SMTP server when configuring
their MUA for sending mail.

5.5 Message-Level Confidentiality

Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist to allow for
message confidentiality outside of the operation of SMTP. That is to say,
using these protocols results in encryption of the message prior to its
being submitted to the SMTP communications channel, and decryption of the
message is the responsibility of the message recipient. There are numerous
implementations of these protocols, too many to list here. As they operate
fully independent of SMTP, they are out of scope for this document.
=========================== cut here ========================

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2022 18:27:57 +0100

Hi Todd,
(With my WG participant hat on)

> On 22 Mar 2022, at 15:31, Todd Herr <todd.herr=[email-masked]> wrote:
> 
> 
> Greetings.
> 
> I've reviewed the comments generated by my posting rev 3 here at the end of January, and I've incorporated some of them.
> 
> The one that I didn't incorporate was one that Dave Crocker made to perhaps discuss the concepts of Channel Security versus Object Security in section 5.5, Message-Level Confidentiality. While I thought the suggestion had merit on its face, the fact that the section is just a paragraph talking about how OpenPGP and S/MIME (and similar technologies) are out of scope for the A/S made me decide not to add more text to this section.
> 
> Current revision follows, there's a place in the agenda to discuss it during Friday's meeting.
> 

Thank you for this text. Minor comments below:

> SMTP is specified without embedded mechanisms for authentication or confidentiality; its traffic is therefore “in the clear”. Years of operational experience have shown that such transmission exposes the message to easy compromise, including wiretapping and spoofing. To mitigate these risks, operation of SMTP has evolved over the years so that it is used with the benefit of Transport Layer Security (TLS - RFC8446) to provide both confidentiality and authentication in the transmission of messages. This section discusses those topics and their most common uses.
> 
> It is important that the reader understand what is meant by the terms “Authentication” and “Confidentiality”, and for that we will borrow directly from RFC8446.
> 
> Authentication is the process of establishing the identity of one or more of the endpoints of a communication channel. TLS only requires authentication of the server side of the communication channel; authentication of the client side is optional.
> The term “confidentiality” describes a state where the data (i.e., the message) is transmitted in a way that it is only visible to the endpoints of a communication channel.
> 
> It is not uncommon for implementers to use the term “encryption” to mean “confidentiality”, but this is not quite correct. Rather, encryption using TLS is the current method by which confidentiality is achieved with SMTP, but that does not mean that future methods might not be developed.
> 
> Note: With typical email use of TLS, authentication only is performed by the sending client of the target receiving server. That is, it serves to validate that the connection has been made to the intended server, but does not validate who initiated it.
> 
> The most common implementation of message confidentiality is what’s known as “opportunistic TLS”, which is frequently referred to as “opportunistic encryption”. With this method, a receiving server announces in its greeting that it is capable of supporting TLS encryption through the presence of the “STARTTLS” keyword. The sending client then attempts to negotiate an encrypted connection, and if successful, transmits the message in encrypted form; if negotiation fails, the client falls back to sending the message in clear text.
> 
> Opportunistic TLS is confidentiality without authentication, because no effort is made to authenticate the receiving server, and it is optional confidentiality due to the ability to fall back to transmission in the clear if a secure connection cannot be established. That said, most modern implementations of SMTP support this method, especially at the largest mailbox providers, and so the vast majority of email traffic is encrypted during its time transiting from the client to the server. 
> 
> Note: While TLS provides protection while the message is in transit for a single SMTP connection, a message that is encrypted for one SMTP hop might not be encrypted on the next hop and it might not be encrypted within the MTAs relaying the message or at its destination. In fact, storage in plain text should be expected!
> 
I think you should move the above note to Section 5, as it applies equally to opportunistic and mandated confidentiality.

> Two protocols exist that move message confidentiality from optional to required (with conditions as noted below) - MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they differ in their implementation details, receiving servers relying on either protocol are stating that they only accept mail if the transmission can be encrypted with TLS, and a failure to negotiate a secure connection MUST result in the sending client refusing to transmit the message. 
> 
> These two protocols differ from Opportunistic TLS in that they require receiving server authentication and there is no fallback to sending in the clear if negotiation of an encrypted connection fails.
> 
> Note: Both protocols mentioned in this section rely not only on the receiving server but also the sending client supporting the protocol intended to be used. If the sending client does not implement or understand the protocol requested by the receiving server, the sending client will use Opportunistic TLS or clear-text to transmit the message.
> 
> Protocols exist to allow for authentication of different identities associated with an email message - SPF [RFC7208] and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies on SPF and DKIM to allow for validation of the domain in the visible From header, and a fourth, ARC [RFC8617], provides a way for each hop to record results of authentication checks performed at that hop.
> 
> All of these are outside the scope of this document, as they are outside the scope of SMTP. They deal with validating the authorized usage of one or more domains in an email message, and not with establishing the identity of the receiving server.
> 
> 5.4 SMTP Authentication
> 
> SMTP Authentication, which is often abbreviated as SMTP AUTH, is an extension to SMTP. Its name might suggest that it would be within scope for this section of the Applicability Statement, but in fact it’s not.
> 
> SMTP AUTH defines a method for a client to identify itself to a Message Submission Agent (MSA) 
> 
While this is the most common use, SMTP AUTH is actually not limited to MSAs.

I would reword the above to say that why SMTP AUTH is defined for both MSAs and MTAs, it is most commonly used with MSAs, and thus it is out of scope for A/S.

> when presenting a message for transmission, usually using port 587 rather than the traditional port 25. 
> 
You need a reference here.
> The most common implementation of SMTP AUTH is for a person to present a username and password to their mailbox provider’s outbound SMTP server when configuring their MUA for sending mail.
> 
> Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist to allow for message confidentiality 
> 
“and integrity”
> outside of the operation of SMTP. That is to say, using these protocols results in encryption of the message prior to its being submitted to the SMTP communications channel, and decryption of the message is the responsibility of the message recipient. There are numerous implementations of these protocols, too many to list here. As they operate fully independent of SMTP, they are out of scope for this document.
> 
> Todd Herr  | Technical Director, Standards and Ecosystem
> e: [email-masked] 
> m: 703.220.4153
> 
> This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
> -- 
> Emailcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emailcore

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Mar 2022 06:04:24 -0700

> authentication of the client side is optional.

Authentication is the process of validating an asserted identity of one or
more of the endpoints of a communication channel. TLS usage typically 
only attempts authentication of the server side of the communication 
channel;
authentication of the client side is optional. Further, 'opportunistic' 
use of TLS offers a somewhat fragile form of authentication.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Pete Resnick <[email-masked]>
Date: Fri, 25 Mar 2022 20:26:35 +0100

On 25 Mar 2022, at 14:04, Dave Crocker wrote:

> Further, 'opportunistic' use of TLS offers a somewhat fragile form of 
> authentication.

I don't think that's quite correct. In one set of cases, opportunistic 
TLS provides absolutely no form of authentication (as the text Todd 
provided explains). In the other set of cases (opportunistic DANE TLS), 
you get solid authentication. Calling that combination "fragile" seems 
inaccurate. I'd rather leave off this extra sentence and leave it to 
sections 5.1 and 5.2 to explain what's available.

pr

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2022 17:19:16 -0400

It appears that Pete Resnick  <[email-masked]> said:
>you get solid authentication.

Don't forget MTA-STS (RFC 8461) which provides more or less the same
thing as DANE TLS in a klunkier way. If you use DANE and MTA-STS in
enforce mode I agree you get solid server authentication, give or take how
widely implemented they are.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Mar 2022 06:43:31 -0400

Todd,

This comment may partially relate to the discussion among Dave,
Pete, and John, but my concern is a bit different.  While
someone who knows what to look for and is reading carefully will
figure it out, I think it is very important that you make two
distinctions explicitly:

(1) Putting S/MIME and PGP aside, none of these techniques, at
least as I understand them, offer user/sender level
authentication.  Those that provide authentication authenticate
hosts, not users, and some provide integrity protection to part
or all of the message (integrity protection is the third part of
the puzzle and should probably be mentioned along with
authentication and confidentiality).  They _may_ authorize
particular users or mailboxes to send mail, but do not
authenticate the users themselves.  These distinctions should be
made clear.

(2) Again putting S/MIME and PGP aside, confidentially for these
methods is strictly hop by hop, with messages in clear on
relays.  Put more strongly, if servers can easily be attacked,
protecting messages in transit between them does not help much.
And these procedures do not provide endpoint to endpoint
confidentiality.

In addition, your Section 5.5 on S/MIME and PGP should note
that, properly used and with the right options, they provide not
only endpoint-to-endpoint confidentiality of message content but
strong authentication of sending users (not just mailboxes) and
message body integrity.

Finally, I question dismissing S/MIME and PGP on the grounds
that they "operate fully independent of SMTP".  Certainly that
is true.  But, when SMTP runs over a security layer (such as TLS
or even SSH) that security layer is operating fully independent
of SMTP too.   I don't have a serious problem with your
explaining them briefly and then saying "out of scope", but I
think you need a better explanation.

   john

--On Tuesday, March 22, 2022 10:29 -0400 Todd Herr
<todd.herr=[email-masked]> wrote:

> Greetings.
> 
> I've reviewed the comments generated by my posting rev 3 here
> at the end of January, and I've incorporated some of them.
> 
> The one that I didn't incorporate was one that Dave Crocker
> made to perhaps discuss the concepts of Channel Security
> versus Object Security in section 5.5, Message-Level
> Confidentiality. While I thought the suggestion had merit on
> its face, the fact that the section is just a paragraph talking
> about how OpenPGP and S/MIME (and similar technologies) are
> out of scope for the A/S made me decide not to add more text
> to this section.
> 
> SMTP is specified without embedded mechanisms for
> authentication or confidentiality; its traffic is therefore
> "in the clear". Years of operational experience have shown
> that such transmission exposes the message to easy compromise,
> including wiretapping and spoofing. To mitigate these risks,
> operation of SMTP has evolved over the years so that it is
> used with the benefit of Transport Layer Security (TLS -
> RFC8446) to provide both confidentiality and authentication in
> the transmission of messages. This section discusses those
> topics and their most common uses.
> 
> It is important that the reader understand what is meant by
> the terms "Authentication" and "Confidentiality", and
> for that we will borrow directly from RFC8446.
> 
>    -
> 
>    Authentication is the process of establishing the identity
> of one or    more of the endpoints of a communication channel.
> TLS only requires    authentication of the server side of the
> communication channel;    authentication of the client side is
> optional.
>    -
> 
>    The term "confidentiality" describes a state where the
> data (i.e., the    message) is transmitted in a way that it is
> only visible to the endpoints    of a communication channel.
> 
> It is not uncommon for implementers to use the term
> "encryption" to mean "confidentiality", but this is
> not quite correct. Rather, encryption using TLS is the current
> method by which confidentiality is achieved with SMTP, but
> that does not mean that future methods might not be developed.
> 
> Note: With typical email use of TLS, authentication only is
> performed by the sending client of the target receiving
> server. That is, it serves to validate that the connection has
> been made to the intended server, but does not validate who
> initiated it.
> 
> The most common implementation of message confidentiality is
> what's known as "opportunistic TLS", which is frequently
> referred to as "opportunistic encryption". With this
> method, a receiving server announces in its greeting that it
> is capable of supporting TLS encryption through the presence
> of the "STARTTLS" keyword. The sending client then
> attempts to negotiate an encrypted connection, and if
> successful, transmits the message in encrypted form; if
> negotiation fails, the client falls back to sending the
> message in clear text.
> 
> Opportunistic TLS is confidentiality without authentication,
> because no effort is made to authenticate the receiving
> server, and it is optional confidentiality due to the ability
> to fall back to transmission in the clear if a secure
> connection cannot be established. That said, most modern
> implementations of SMTP support this method, especially at the
> largest mailbox providers, and so the vast majority of email
> traffic is encrypted during its time transiting from the
> client to the server.
> 
> Note: While TLS provides protection while the message is in
> transit for a single SMTP connection, a message that is
> encrypted for one SMTP hop might not be encrypted on the next
> hop and it might not be encrypted within the MTAs relaying the
> message or at its destination. In fact, storage in plain text
> should be expected!
> 
> Two protocols exist that move message confidentiality from
> optional to required (with conditions as noted below) -
> MTA-STS [RFC8461] and DANE for SMTP [RFC7672]. While they
> differ in their implementation details, receiving servers
> relying on either protocol are stating that they only accept
> mail if the transmission can be encrypted with TLS, and a
> failure to negotiate a secure connection MUST result in the
> sending client refusing to transmit the message.
> 
> These two protocols differ from Opportunistic TLS in that they
> require receiving server authentication and there is no
> fallback to sending in the clear if negotiation of an
> encrypted connection fails.
> 
> Note: Both protocols mentioned in this section rely not only
> on the receiving server but also the sending client supporting
> the protocol intended to be used. If the sending client does
> not implement or understand the protocol requested by the
> receiving server, the sending client will use Opportunistic
> TLS or clear-text to transmit the message.
> 
> Protocols exist to allow for authentication of different
> identities associated with an email message - SPF [RFC7208]
> and DKIM [RFC6376]. A third protocol, DMARC [RFC7489], relies
> on SPF and DKIM to allow for validation of the domain in the
> visible From header, and a fourth, ARC [RFC8617], provides a
> way for each hop to record results of authentication checks
> performed at that hop.
> 
> All of these are outside the scope of this document, as they
> are outside the scope of SMTP. They deal with validating the
> authorized usage of one or more domains in an email message,
> and not with establishing the identity of the receiving server.
> 
> 5.4 SMTP Authentication
> 
> SMTP Authentication, which is often abbreviated as SMTP AUTH,
> is an extension to SMTP. Its name might suggest that it would
> be within scope for this section of the Applicability
> Statement, but in fact it's not.
> 
> SMTP AUTH defines a method for a client to identify itself to
> a Message Submission Agent (MSA) when presenting a message for
> transmission, usually using port 587 rather than the
> traditional port 25. The most common implementation of SMTP
> AUTH is for a person to present a username and password to
> their mailbox provider's outbound SMTP server when
> configuring their MUA for sending mail.
> 
> Protocols such as S/MIME (RFC8551) and OpenPGP (RFC4880) exist
> to allow for message confidentiality outside of the operation
> of SMTP. That is to say, using these protocols results in
> encryption of the message prior to its being submitted to the
> SMTP communications channel, and decryption of the message is
> the responsibility of the message recipient. There are numerous
> implementations of these protocols, too many to list here. As
> they operate fully independent of SMTP, they are out of scope
> for this document.

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2022 10:25:36 -0400

It appears that John C Klensin  <[email-masked]> said:
>of SMTP too.  ...

When the client uses DANE or MTA-STS, it's using TLS to verify that
the SMTP server is the one it expects to be talking to. I don't think
that's outside of SMTP, and it seems quite different from S/MIME.

I do agree that the threats and mitigations could be matched up better.

R's,
John

PS: I suppose I should send text.

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Mar 2022 14:14:31 -0400

--On Saturday, March 26, 2022 10:25 -0400 John Levine
<[email-masked]> wrote:

>> is true.  But, when SMTP runs over a security layer (such as
>> TLS or even SSH) that security layer is operating fully
>> independent of SMTP too.  ...
> 
> When the client uses DANE or MTA-STS, it's using TLS to verify
> that the SMTP server is the one it expects to be talking to. I
> don't think that's outside of SMTP, and it seems quite
> different from S/MIME.

That is fair.  I was thinking much more about backward
(sender-side) authentication (of sending users, and sender-SMTP
hosts) than about forward authentication of receiver-SMTP hosts.
Our apparent disagreement is, IMO, more reinforcement for the
idea that the document should be far more clear about exactly
what it is talking about and where.

> I do agree that the threats and mitigations could be matched

Yeah.

  thanks,
    john

---

From: "John R Levine" <[email-masked]>
Date: 26 Mar 2022 14:42:50 -0400

On Sat, 26 Mar 2022, John C Klensin wrote:
>> that the SMTP server is the one it expects to be talking to. ...
>

I have seen code that does client authentication with client certs, but 
to the extent it even exists, it's definitely submission, not SMTP.

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

---

From: Claus Assmann <[email-masked]>
Date: Sat, 26 Mar 2022 19:25:21 +0000

On Sat, Mar 26, 2022, John R Levine wrote:

> I have seen code that does client authentication with client certs, but to
> the extent it even exists, it's definitely submission, not SMTP.

sendmail can enforce client authentication via certs in SMTP
and it is being used as such (based on data I've seen).

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

---

From: Steffen Nurpmeso <[email-masked]>
Date: Sat, 26 Mar 2022 20:52:08 +0100

Claus Assmann wrote in
 <[email-masked]>:
 |On Sat, Mar 26, 2022, John R Levine wrote:
 |> I have seen code that does client authentication with client certs, \
 |> but to
 |> the extent it even exists, it's definitely submission, not SMTP.
 |
 |sendmail can enforce client authentication via certs in SMTP
 |and it is being used as such (based on data I've seen).

Even though Viktor Dukhovni is here .. i was also using client
certificates with postfix.  (And SMTPS, so it is possible.  In
fact i always have a hard time seeing the difference except for
the dedicated configuration that listens on a dedicated socket.
From my own dumb user point of view i connect to SMTPS:465.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 26 Mar 2022 19:58:33 +0000

On 26/03/2022 19:52, Steffen Nurpmeso wrote:
>  i was also using client
> certificates with postfix.
As can Exim, likewise orthogonal to port number and STARTTLS
vs. on-connect.  So that's a full triple of "the independents".
-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2022 16:18:54 -0400

>and it is being used as such (based on data I've seen).

I believe the code is there and someone is using it, but I'm having trouble
figuring out how one would use it for SMTP rather than submission.  If you only 
accept mail from hosts that provide certs that you like, you're not much of an
SMTP server.

(Note that you can do submission on port 25.)

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 26 Mar 2022 20:29:17 +0000

On 26/03/2022 20:18, John Levine wrote:
> If you only

Maybe you do both forwarding (for a limited set of authenticating senders)
and reception-and-delivery (from anywhere)?

But perhaps you want to declare that the former is submission.  I don't
have the energy to argue.
-- 
Cheers,
   Jeremy

---

From: Steffen Nurpmeso <[email-masked]>
Date: Sat, 26 Mar 2022 21:41:29 +0100

Jeremy Harris wrote in
 <[email-masked]>:
 |On 26/03/2022 20:18, John Levine wrote:
 |> If you only
 |> accept mail from hosts that provide certs that you like, you're not \
 |> much of an
 |> SMTP server.
 |
 |Maybe you do both forwarding (for a limited set of authenticating senders)

The postfix camp says relay policy.

 |and reception-and-delivery (from anywhere)?
 |
 |But perhaps you want to declare that the former is submission.  I don't
 |have the energy to argue.

Aye.

--steffen
|

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2022 20:18:23 -0400

It appears that Jeremy Harris  <[email-masked]> said:
>> accept mail from hosts that provide certs that you like, you're not much of an SMTP server.
>

Good point.  This gets us into nitipicky arguments about submission vs smarthost vs SMTP,
which I think are best discussed not very much.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Mar 2022 21:28:27 -0400

--On Saturday, March 26, 2022 20:29 +0000 Jeremy Harris
<[email-masked]> wrote:

> But perhaps you want to declare that the former is submission.
> I don't have the energy to argue.

Jeremy,

Not to argue (but perhaps to agree instead)... The problem is
that, if the former (or a bunch of other odd cases) are
submission, then we open a can of something nastier than worms.
As you know, issues about port selection, whatever one thinks of
RFC 8314 [1], and other small details aside, the key difference
between submission and "normal" SMTP is that we allow (and
encourage) submission servers to do all sorts of things to fix
up whatever garbage MUAs send them and make the messages fit for
sending across the public Internet... even including potentially
applying S/MIME or PGP.  We forbid all of that to normal SMTP
MTAs, so declaring the kind of forwarding you describe as
submission would be really bad news.

John Levine and others,

One thing that tends to get lost in these discussions is that
there are many uses of SMTP for special applications, even when
those applications run over the public Internet.  If the
operators of a receiver-SMTP (delivery server or not), knows
that it should be receiving traffic only from a restricted set
of sender-SMTP systems and consider the traffic or its possible
consequences at all sensitive, it becomes reasonable and
appropriate for them to insist on more or less strong
authentication of either the sending user (S/MIME or PGP cases,
but they require accepting the message and looking at its
content)  or the previous-hop sender-SMTP.  Over the years I've
seen efforts at authentication of the former using many options
including checking the connection attempt against a list of
permitted IP addresses, magic cookies in the HELO/EHLO command
or tricks with the MAIL command (most often involving use of
trick local-parts), requiring that SMTP run over SSH and doing
some handshaking before the actual mail session is established,
and client cert checking.  

I think it would be unnecessary and unwise for the A/S to
explain those cases in any detail or spend non-trivial time on
them more generally.  But I think it is important that it be
written with enough awareness of them that we do not
accidentally prohibit, or even say nasty things about, cases
that are perfectly reasonable under the right circumstances.
And, repeating something I've tried to say before in the last 48
hours, it is extremely important that the document be very clear
about what it is talking about and, in particular, avoid talking
about authentication without being clear who or what is being
authenticated and to what or who.

best,
   john

[1]  Translation of the implicit snarky comment, noting that
Submission being out of scope for the WG takes 8314 out of scope
too (and IMAP, POP, etc., are even more so):  When the
Submission Server is being run by a conventional MSP on the
public Internet and separated from and serving multiple MUAs,
8314 makes perfect sense.  However, when the two are both
operating on a well-secured enterprise LAN or the connection
between the two is being run over a well-secured connection
(e.g., SSH or even IPv6 link encryption with the server refusing
to accept unencrypted connections), the MSA server sees only
cleartext but forcing running TLS over such connections is
almost certainly going to be a waste of time and energy with
nearly zero improved security.  Similar comments can be made on
the Mail Access (POP/IMAP) side of things.  I'm mentioning this
only because it is another case of assuming that the most common
cases are the only ones and then writing specifications
accordingly.  We really need to be more careful about that.

---

From: Claus Assmann <[email-masked]>
Date: Sun, 27 Mar 2022 05:56:55 +0000

> figuring out how one would use it for SMTP rather than submission.  If you only 

By selectively enforcing it for "well known" hosts (or even domains).
There are different "levels" of requirements, so admins can decide
whether to require a cert that can be "verified", a specific cert
issuer, or even stronger restrictions.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Mar 2022 18:44:57 -0700

On 3/25/2022 12:26 PM, Pete Resnick wrote:
> provided explains).

So, this prompted some exploration, which mostly created more confusion.

My comment came from an extended wg discussion which, I think, produced 
RC 7435 (Opportunistic Security: Some Protection Most of the Time).

I took the goal of such work to be finding ways to get encryption, 
without needing a global cert system.  This would seem to support the 
view that opportunistic encryption, such as with TLS, doesn't do 
authentication.

Opportunistic TLS appears to have two different goals.  One is to invoke 
TLS after the start of the application session, via starttls.  The 
second is the one that lets encryption work without a global cert.

This latter one is what my comment was intended to refer to.  And sure, 
in the abstract, encryption requires a public key for the target, not an 
authenticated identity.

However consider that servers often provide self-signed certs.  These 
are the cases I intended in my comment.  They are offering an identifier 
and they are self-authenticating it.

That is, in practice, my understanding is that TLS provides encryption 
by anchoring it to a proffered identifier.  Even an ad hoc one.

d/