Subject: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-08.txt

From: [email-masked]
Date: Tue, 15 Aug 2017 10:04:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

        Title           : SMTP TLS Reporting
        Authors         : Daniel Margolis
                          Alexander Brotman
                          Binu Ramakrishnan
                          Janet Jones
                          Mark Risher
	Filename        : draft-ietf-uta-smtp-tlsrpt-08.txt
	Pages           : 23
	Date            : 2017-08-15

Abstract:
   A number of protocols exist for establishing encrypted channels
   between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE
   [RFC6698], and MTA-STS (TODO: Add ref).  These protocols can fail due
   to misconfiguration or active attack, leading to undelivered messages
   or delivery over unencrypted or unauthenticated channels.  This
   document describes a reporting mechanism and format by which sending
   systems can share statistics and specific information about potential
   failures with recipient domains.  Recipient domains can then use this
   information to both detect potential attackers and diagnose
   unintentional misconfigurations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-08
https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-08

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: James Cloos <[email-masked]>
Date: Wed, 16 Aug 2017 15:12:58 -0400

One thought:

The https section should specify a recomendation of what the web site
should return when it sees a POST, and what if anything the generator
should do if the web site replies that the report is not to spec.  Ie,
bad syntax or bad contents or the like.

It probably should be json and could be as simple as {true} or {false}.

Any uri which just accepts reports w/o trying to verify would then be
expected to give the ok reply.

OTOH, if the reporters SHOULDN'T care at all about whether the uri
accepted its report, and should just drop the socket as soon as the
packets are ACKed, then the document should specify that.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6