Some minor comments: Section 1: "It also requires that the SMTP server advertise that it also supports REQUIRETLS, in effect promising that it will honor the requirement to require STARTTLS and REQUIRETLS for all onward transmissions of messages specifying that requirement." "
The part about "promising" does not seem to go together with the optional parameter in section 2 about onward transmission. Section 3.1 - tagging: I am wondering if an email header should be defined to carry this data, which would also allow for auditing by the receiver. Sort of similar to the SPF/DKIM headers used today. Section 3.4 - delivery: It is unclear what "delivery" means here, especially considering that SMTP may relay messages to another server, perhaps reference RFC 5598? Also, the parts in section 1 and the optional parameter in section 2 should play together with this, perhaps by requiring TLS in IMAP, etc. or not. Either way, this may need clarification. Section 5: What are the actual added codes? I believe 5.7.10 already exists. Section 6: Maybe reference RFC 4949 for terminology? One other comment - perhaps some sort of limiting digital signatures for headers only like DKIM can be employed by the receiving MTA to certify that the receipt and transmission was effective? I am thinking along the lines of Received headers or DKIM headers, which would allow traceability. Yakov On Sun, Feb 14, 2016 at 2:55 PM, Jim Fenton <[email protected]> wrote: > Hi, > > I thought I would point out this draft on the perpass list, because its > primary purpose is to give email senders some degree of control over whether > their messages are sent between MTAs using TLS -- and therefore how > susceptible messages are to pervasive passive surveillance. > > Discussion of this draft has thus far been on the ietf-smtp list. > > -Jim > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-fenton-smtp-require-tls-01.txt > Date: Sat, 13 Feb 2016 15:36:57 -0800 > From: [email protected] > To: Jim Fenton <[email protected]> > > > A new version of I-D, draft-fenton-smtp-require-tls-01.txt > has been successfully submitted by Jim Fenton and posted to the > IETF repository. > > Name: draft-fenton-smtp-require-tls > Revision: 01 > Title: SMTP Require TLS Option > Document date: 2016-02-13 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-fenton-smtp-require-tls-01.txt > Status: > https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls/ > Htmlized: https://tools.ietf.org/html/draft-fenton-smtp-require-tls-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-fenton-smtp-require-tls-01 > > 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 > delivery 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 > > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
