Benjamin Kaduk has entered the following ballot position for draft-ietf-uta-smtp-tlsrpt-18: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Alexey et al for following up on the secdir review thread. Some other notes: In the Abstract: Is it "potential attackers" or "potential attacks" that can be detected? Section 1.1 o MTA-STS Policy: A definition of the expected TLS availability, behavior, and desired actions for a given domain when a sending MTA encounters problems in negotiating a secure channel. This description of the policy doesn't make it seem like a definition of those elements, rather a statement or listing of them. Section 3 o "v": This value MUST be equal to "TLSRPTv1". How about something like "This document defines version 1; other versions may be defined in later documents"? Additionally, text later in this section aboud discarding records that do not begin with "v=TLSRPTv1;" and the pruned list not having exactly one element is not friendly to future version negotiation. On a more meta level, do we really need both versioning and extensions? SMTP deliveries can go in the clear, but what about https reports? What do we do if the TLS handshake fails for a non-certificate-validation reason? Section 4 [...] Reporters may report multiple applied policies (for example, an MTA-STS policy and a DANE TLSA record for the same domain and MX); even in the case where only a single policy was applied, the "policies" field of the report body MUST be an array and not a singular value. The confusion caused by misreading the semicolon as a comma is pretty large; maybe start a new sentence with "Because of this possibility, even in the case [...]"? Section 4.4 Is the ABNF for IPv4address really supposed to be line-wrapped like that? Section 7 I'm not sure I correctly understand the reasoning for the statement about using a large TTL for the TLSRPT TXT records -- it seems like the idea is that if the consumer has already received the record once, a large TTL will reduce the frequency at which the consumer seeks to refresh their view of the record, so there are numerically fewer DNS requests that could be intercepted by an attacker? But it seems like if the attacker can intercept the first request and insert their spoofed response, the large TTL doesn't help at all (and in fact could use their own large TTL to preserve the bogus record for a long time). So it's not really clear that there's much of a difference, on first glance. Also, this seems somewhat related to Ben's DISCUSS. I wonder if this document could benefit from a Privacy Considerations section. While it is true that the intent is to transmit aggregate statistics from MTA to MTA, and MTAs are inherently at well-known public locations, if any given data point in the report has only a small number of occurrences, that could potentially reveal information about an individual or small group of individuals. On the other hand, if an outlier data point indicates an attack, then it should not be suppressed from the report! So while there may not be much guidance to give to implementors, it would be reassuring to know that the topic has been given some thought. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
