ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] [Uta] New Version Notification for draft-levine-additional-registered-clauses-00

2019-01-28 20:38:06
On 24 Jan 2019, at 11:56, John R Levine wrote:
Apropos of recent discussions about SNI logging, here's a draft that adds an SNI clause to Received: headers, and per Chris Newman's suggestion, changes the registry criteria to Expert Review so you don't need to publish an RFC merely to register a new clause.

I have some different comments about this. Sometimes thinking through the consequences of a seemingly simple suggestion makes it less simple... Sorry 'bout that.

1. I don't believe a stable reference should be required. In many cases, a single paragraph of text that can live in the IANA registry is sufficient to precisely document the semantics of a Received clause. The expert reviewer can validate if the provided text is sufficient. If references are provided, it's desirable for them to be stable, but I don't see why it should be a strict requirement -- we don't have such a requirement for vendor/private media types and having those types registered provides benefits to the community even without a stable reference.

2. The "additional registered clauses" is presently a sub-registry of the "Mail Transmission Types" registry within the "mail parameters" registry category. I suggest we rename this to "additional registered Received clauses" and make it a top-level registry in the "mail parameters" category -- this should make it easier to find on the iana.org web page.

3. Rather than having to go read section 8 of RFC 5321 to know how to register one of these, I suggest we copy the text from that section relevant to this registry so it's all in one specification.

4. The expert reviewer should verify that the syntax of the clause value is well-defined and complies with the "received-token" syntax in RFC 5322.

5. Noting an appropriate mailing list where public review of a proposal is appropriate can be helpful for expert review registration procedures.

6. I believe a consequence of making the registry expert review rather than IESG action is that we should add an item to the registration template of "privacy/security considerations". I believe the discussions the media types reviewer has with the authors of media type specifications have a generally positive effect on the resulting technology and are much less of a burden than a full standards process. I recommend using text from the media types registration procedures (RFC 6838 section 4.6) as a starting point.

7. Unfortunately, the perspective the IETF (and the industry) has towards privacy/security considerations has evolved since the considerations in RFC 2821 / 5321 were written. As a result, I think RFC 5321 section 7.6 is no longer adequate by itself. I think this document is a good place to provide the additional security considerations for Received headers that weren't covered in that section.

Here's a first attempt:

===
Additional Security Considerations for trace Headers

The security considerations in section 7.6 of RFC 5321 are updated to include this additional information:

Trace information in email headers is normally disclosed when stored email is disclosed. Stored email has additional attack vectors that are not present for in-transit email. As a result, information in trace header fields that would not otherwise be available to the recipient of the email, such as the domain and IP address of hosts involved in the transfer, may have privacy implications. On the flip side, compromised client accounts, abuse, and phishing (as defined in RFC 5901) are serious security threats for email. As a result, server software is encouraged to provide configuration settings such that privacy-sensitive service providers can hide more information and attack-sensitive service providers can record more information in trace headers.

The source host and IP address of the initial submission client can be particularly sensitive from a privacy perspective. A submission server [RFC 6409] SHOULD offer an operational mode such that the mandatory "from" clause contains "omitted.invalid" as the domain name, the IP address is omitted from the "from" clause, and the ID clause contains an identifier that can be used to retrieve that information from server logs for the server's configured log retention period when necessary to mitigate abuse attacks, compromised client credentials, or similar attacks. The identifier used for this purpose should be generated using a mechanism, such as a secure hash function, that does not disclose additional information.
===

other suggestions/word-smithing are welcome.

I'm opposed to having any discussion of ESNI in this document prior to the publication of an ESNI RFC. One option to reduce the controversy would be to simply remove the SNI-related clauses from this RFC and make them the first exercise of the new registration process.

                - Chris

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp