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
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Reply via email to