Subject: [Uta] REQUIRETLS: another SMTP TLS mechanism

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Mar 2016 19:12:43 -0700

Not to distract from the STS discussion, but I thought I'd point out
another approach to SMTP TLS 'encouragement' that I submitted a few
weeks ago: draft-fenton-smtp-require-tls-01. There has been some
discussion of this draft, primarily on the ietf-smtp mailing list and a
little on the perpass list.

REQUIRETLS is an SMTP service extension that allows an SMTP client to
specify (via a MAIL FROM option) that a given message must be sent over
a TLS protected session with specified security characteristics. Options
allow the specification of allowable methods of server certificate
verification, including web-PKI and DANE. In advertising its support for
REQUIRETLS, the SMTP server is promising to honor that requirement.

The idea here is that REQUIRETLS allows the SMTP client to override the
default "deliver even if you can't do it securely" behavior of SMTP. The
philosophy is that the sender of the message (SMTP client) is in the
best position to know if a given message should only be sent via TLS,
either based on some information it has about the sensitivity of the
message or based on the client's local policy.

I plan on giving a short talk on REQUIRETLS (remotely) at the BA UTA
meeting.  Questions or comments are of course welcome, either here or on
ietf-smtp.

-Jim

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 25 Mar 2016 13:09:30 +0100

> On 25 Mar 2016, at 03:12, Jim Fenton <[email-masked]> wrote:
> 

This sounds very similar to what DEEP is trying to achieve, can you highlight important differences?

Aaron

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 25 Mar 2016 13:45:48 +0000

> This sounds very similar to what DEEP is trying to achieve, can you highlight important differences?

As I read them:

REQUIRETLS covers an entire chain of to-MTA hops (by requiring not only
TLS but also REQUIRETLS on a forwarding hop, or bounce).  It would
presumably cover the MUA-MSA hop (as DEEP does) when SMTP was used
there.  It SHOULD's secure access by the destination MUA (though that
will be hard, in many implementations, as it requires implementation
in a separate lump of software).  It works on a per-message basis.

DEEP talks in terms of per-mail-account configuration.  It deals with
both submission and access,  It talks about UI presentation of
security status.  It does not cover beyond the MSA or MDA.

-- 
Cheers,
  Jeremy

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 25 Mar 2016 14:24:08 +0000

On 25/03/16 02:12, Jim Fenton wrote:
>  draft-fenton-smtp-require-tls-01

> message or based on the client's local policy.

- The draft does not mention alias-style forwarding done by an MTA;
  perhaps it could?  A 1-1 alias would seems to be easily covered,
  but 1-to-many (mail-exploder) aliases may need more thought.

- I assume that mailing-list forwarding is not intended to be covered.
  Perhaps that should be explicit.
-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2016 15:47:24 -0000

>  but 1-to-many (mail-exploder) aliases may need more thought.

The whole draft presumes that intermediate hops will follow
instructions from the sender, without providing any benefit to those
intermediate hops.

Experience suggests this is not a great model.

R's,
John

---

From: "Orit Levin (CELA)" <[email-masked]>
Date: Fri, 25 Mar 2016 16:29:58 +0000

Thank you, Jim. Definitely should be a part of the conversation.
You are on the Agenda!
Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Jim Fenton
> Sent: Thursday, March 24, 2016 7:13 PM
> To: [email-masked]
> Subject: [Uta] REQUIRETLS: another SMTP TLS mechanism
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 25 Mar 2016 18:24:26 +0000

> little on the perpass list.

Parallel discussion is not unprecedented on IETF lists...

> REQUIRETLS, the SMTP server is promising to honor that requirement.

Section 2. 

    <quote>
       o  DNSSEC - The server MUST confirm that any MX record or CNAME
	  lookup used to locate the SMTP server must be DNSSEC [RFC4035]
	  signed and valid.
    </quote>

    Does requiring DNSSEC cover just the MX RRset, or also the
    address records of the individual MX hosts.  I ask because
    in Section 3 you say:

    <quote>
       o  Look up the SMTP server to which the message is to be sent.  If
	  the DNSSEC option is included in the message tag, all lookups in
	  this process MUST use DNSSEC verification and the response MUST be
	  DNSSEC-signed.
    </quote>

    If the entire goal is to ensure the integrity of the RFC 6125
    "reference identifier" used to authenticate the nexthop SMTP
    server, then it is perhaps a good idea to say so explicitly.

    <quote>
       The CHAIN and DANE parameters are additive; if both are specified,
       either method of certificate validation is acceptable.  If neither
       CHAIN nor DANE is specified, the certificate presented by the SMTP
       server is not required to be verified.
    </quote>

    This is reasonably clear, either suffices when both are specified.
    I am concerned that giving the user the choice to specify either
    alone, rather than just a single "AUTHENTICATED" (or similar)
    keyword, may be too much rope.  The "REQUIRETLS" service
    extension, just by requiring authenticated TLS on every single
    hop, is already typically equivalent to "BOUNCEME", and making
    delivery even less likely by giving the sender control over
    the authentication mechanism is I believe counterproductive.

    If STS enters the mix, would that need to be added as yet
    another keyword?  Would STS be an alternative to DNSSEC (to
    protect the reference identifiers via its MX host constraints)
    or an alternative to CHAIN/DANE?

    The reason I mention this, is to illustrate that this level of
    specificity in the client's REQUIRETLS request is IMHO unwise.

    A much more pragmatic approach (at the cost of some uncertainty
    about which mechanisms are used on any given hop) is to leave
    the authentication details unspecified.  Given how little
    experience and deployment we have for authenticated MTA-to-MTA
    SMTP, I strongly suggest a more "generic" approach to
    authentication.

Section 3.4.  Delivery of REQUIRETLS messages

    <quote>
       Messages are usually delivered to end users using protocols other
       than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems.
       Mail delivery agents supporting REQUIRETLS SHOULD require that
       message delivery take place over authenticated, encrypted channels.
    </quote>

    Terminology problem.  This confuses delivery protocols with
    access protocols.  IMAP and POP are not delivery protocols.
    The only IETF delivery protocol is LMTP.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Mar 2016 12:03:36 -0700

> security status.  It does not cover beyond the MSA or MDA.

That's basically correct. REQUIRETLS is strictly an SMTP mechanism; it's
mostly about MTA-MTA hops but since message submission sometimes
(often?) happens via SMTP, it's usable for MUA-MSA hops using SMTP as
well. I haven't dug into DEEP very far yet, but it is primarily about
MUA-MSA and MUA access of the message store and about UI. They may be
complementary in emphasizing different parts of the mail path.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Mar 2016 12:12:48 -0700

>   but 1-to-many (mail-exploder) aliases may need more thought.

REQUIRETLS is about satisfying the sender's expectations about how
onward transmission of the message takes place. As a sender, my
expectations wouldn't change if an MTA forwarded the message to more
than one recipient, so I would want REQUIRETLS to be applied to all of
the onward forwards. I agree, this could be more explicit.
>   Perhaps that should be explicit.

We had a little discussion about mailing lists and REQUIRETLS on the
ietf-smtp list. Mailing lists (as distinct from mail
forwarders/exploders, above) originate a new message from the mailing
list. So I would expect REQUIRETLS from a mailing list to be at the
option of the list operator, although it would be a good practice in
many cases to follow the REQUIRETLS practices of the incoming message. 
Agree on making this more explicit, too.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Mar 2016 12:35:02 -0700

>     server, then it is perhaps a good idea to say so explicitly.

The primary purpose was indeed to ensure the integrity of the reference
identifier; this is discussed in the Security Considerations (section
6.2, paragraph 3). The rationale is that the address records are less of
a concern because the client will be verifying the server's certificate.
But that won't always be the case, so I'm on the fence about whether to
require address verification or not. If the MX record points to an
address in the same DNS zone, it'll be covered by DNSSEC, of course, but
MX records often point off to a service provider, and requiring DNSSEC
there might be an additional barrier to deployment.

>     the authentication mechanism is I believe counterproductive.

I'm chuckling about calling it BOUNCEME, but it's an apt description at
present, since there is no REQUIRETLS deployment and the messages will
be bounced for that reason alone.

By not using the CHAIN and DANE options, certificate verification is not
required, so if too many messages are being bounced with those options,
they'll not see use. But without those options, we're limiting the
effectiveness of REQUIRETLS to passive attacks only; MITM attacks will
still be possible.

I have received suggestions that there also be options to require
specific TLS version, cipher suites, PFS, etc. as well, and my gut feel
is that's getting too specific.

>     SMTP, I strongly suggest a more "generic" approach to

I have had some discussions with the STS folks and have been thinking
about ways the two proposals might be complementary. Using REQUIRETLS to
require the use of TLS, and STS to specify the type of authentication,
is an interesting idea along those lines.
>     The only IETF delivery protocol is LMTP.

Good observation; thanks.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 25 Mar 2016 22:19:39 +0000

On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote:

> 6.2, paragraph 3).

If so, with DNSSEC validation required, CNAMEs need only be secured
to the extent that they affect "reference identifier" selection.

    *  CNAME/DNAMEs between the MX qname and the owner domain of
       the ultimate MX RRset definitely need to be validated.

    * For domains with no MX RRset, the absence of the MX RRset
      would potentially need to be DNSSEC validated.

    * Otherwise, CNAMEs only need to be validated to the extent
      that (e.g. following RFC 7672) the ultimate "reference
      identifier" is determined in whole or in part based on
      the result of the CNAME lookup.

> >     keyword, may be too much rope.
> 

NOTE:  I am not suggesting that REQUIRETLS should not be able to
require authenticated TLS.  Rather, I am (strongly) suggesting that
such a requirement needs be mechanism-neutral, and should not be
so specific as to be able to specify the use of DANE, WebPKI or
some future alternative.

> is that's getting too specific.

Don't let this be over-engineered.  That's a guaranteed way to fail
to produce a workable protocol.  Of course it is clear that even
a simple REQUIRETLS can gain sufficient traction, but to the extent
that you want this to have a fighting chance you should resist all
calls for overly-specific policy.

-- 
	Viktor.

---

From: Chris Newman <[email-masked]>
Date: Fri, 25 Mar 2016 15:59:42 -0700

On March 24, 2016 at 12:42:07 , Jim Fenton ([email-masked]) wrote:

I plan on giving a short talk on REQUIRETLS (remotely) at the BA UTA 
meeting. Questions or comments are of course welcome, either here or on 
ietf-smtp. 
Having a protocol that allows a client to request that a particular SMTP security policy be applied to all hops is an interesting idea. However, I consider it important that we have a single extensible security policy model and syntax if possible. Can you change your proposal to reference the security policy model and syntax in DEEP (which includes extensibility)? If not, can you propose changes to DEEP that would help align these proposals?

I’d like to avoid having different ways to specify SMTP security policy in different places (syntax variations are annoying, semantic variations are a concern).

  https://tools.ietf.org/html/draft-ietf-uta-email-deep-04

		- Chris

---

From: Jim Fenton <[email-masked]>
Date: Sun, 27 Mar 2016 20:17:28 -0700

>       the result of the CNAME lookup.

Sounds right to me.  Thanks for spelling it out.  I'll get it into the
next revision.

> calls for overly-specific policy.

I'm sensitive to over-engineering this.  That said, there are mail
senders who might consider their threat model to include an actor that
has control over a commonly-accepted root certificate (as some
nation-states do).  Much of the motivation behind the CHAIN and DANE
options was to allow such senders to be more specific about what forms
of certificate verification they consider acceptable.

This is probably a narrow use case, but perhaps very important for these
senders. Let's see what the rough consensus is.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Mar 2016 20:09:21 +0000

On Sun, Mar 27, 2016 at 08:17:28PM -0700, Jim Fenton wrote:

> > to produce a workable protocol.  Of course it is [not] clear that even

So just to be clear, my view is that allowing the sender to specify
the authentication mechanism that is to be used along the entire
delivery chain is a non-starter.  

If I ever get around to implementing this specification in Postfix,
I would most likely ignore any specific authentication mechanism,
and, when authentication is requested, deliver via whichever of
WebPKI, DNSSEC/DANE (or perhaps STS, ...) happens to work.

An initial implementation of this specification would likely also
include controls to downgrade the requested TLS security for trusted
relay hops, so that Internet-facing border MTAs can terminate
REQUIRETLS and deliver without authentication or in the clear to
internal mail servers.

-- 
	Viktor.