Subject: [Uta] Fwd: New Version Notification for draft-fenton-smtp-require-tls-02.txt

From: Jim Fenton <[email-masked]>
Date: Tue, 16 Aug 2016 15:09:03 -0700

FYI, I have (finally) updated the REQUIRETLS draft. Significant changes:

  * Specified retries when multiple MX hosts exist for a given domain.
  * Clarified generation of non-delivery messages
  * Specified requirements for application of REQUIRETLS to mail
    forwarders and mailing lists.
  * Clarified DNSSEC requirements to include MX lookup only.
  * Corrected terminology regarding message retrieval vs. delivery.
  * Changed category to standards track.

One change I haven't made yet (suggested by Viktor Dukhovni) is to
eliminate the options to specify specific authentication mechanisms. I
definitely get the argument that this may be over-engineered, but I'm
also concerned that there may be use cases where an attacker (perhaps a
nation-state) might be able to create certificates signed by a
commonly-trusted CA, and the sender might not want those to be used to
authenticate SMTP servers. I'd be interested in how others feel about
that; perhaps it should go away in the next version.

I'm also struggling to figure out how to align this with STS and DEEP so
that we have a "single extensible security policy" as suggested by Chris
Newman. I don't see this as a policy-based mechanism: it's an option for
a single message, not a general policy, isn't published anywhere, and is
expressed on behalf of the sender and not the recipient. It seems like a
complementary mechanism to me.

Any further comments and suggestions are of course welcome.

-Jim

A new version of I-D, draft-fenton-smtp-require-tls-02.txt
has been successfully submitted by Jim Fenton and posted to the
IETF repository.

Name:		draft-fenton-smtp-require-tls
Revision:	02
Title:		SMTP Require TLS Option
Document date:	2016-08-16
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-fenton-smtp-require-tls-02.txt
Status:         https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/
Htmlized:       https://tools.ietf.org/html/draft-fenton-smtp-require-tls-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fenton-smtp-require-tls-02

Abstract:
   The SMTP STARTTLS option, used in negotiating transport-level
   encryption of SMTP connections, is not as useful from a security
   standpoint as it might be because of its opportunistic nature;
   message delivery is prioritized over security.  This document
   describes a complementary SMTP service extension, REQUIRETLS.  If the
   REQUIRETLS option is used when sending a message, it causes message
   transmission to fail if a TLS connection with the required security
   characteristics cannot be completed with the next hop MTA, or if that
   MTA does not also advertise that it supports REQUIRETLS.  Message
   originators may therefore expect transport security to be used for
   messages sent with this option.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 22 Aug 2016 15:53:25 +0100

> Name:		draft-fenton-smtp-require-tls

- Section 2, bullet point discussing the DNSSEC parameter:

  Should the requirement for dnssec to extend also to SRV,
  A and AAAA lookups?

- Section 3.2, last paragraph (onward transmission must use
  REQUIRETLS):

  Should this have a "MUST" ?

- Section 3.3, on introducing the need to REQUIRETLS to a
  message transmission chain:

  Currently the only actor described as having this authority
  is the sourcing MUA.   What about a MAY permitting an MTA to
  either introduce or upgrade the requirement associated with
  a message?   Probably best to also specifically "MUST NOT"
  any downgrade or removal, too.

- Should a receiving MTA be required to mark up the
  Received:  header it adds in some specific way for
  REQUIRETLS messages?

-- 
Cheers,
  Jeremy