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