[Last-Call] Secdir last call review of draft-ietf-dmarc-aggregate-reporting-23

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Phillip Hallam-Baker
Review result: Serious Issues

The draft describes a mechanism for reporting the results of applying DMARC
policy on mail received at one or more domains.

While reading the document, it was rather difficult to follow because fields
are mentioned in the text by identifier'p', 'sp' but the only indication of
what the identifier stands for comes in a comment in the schema. All fields and
their purpose should be explicitly addressed either in the text itself or by
reference to another source.

Given that this specification is describing an infrastructure whose entire
purpose is resisting hostile attack, the Privacy Considerations have direct
effect on Security and there should be at least a mention of them in the
Security Considerations section which should be a 'one stop' shop for all
things security.

It probably makes best sense to do the incorporation by reference of this and
draft-ietf-dmarc-dmarcbis in the first paragraph of the SC.

The current SC section has bullet points that look like they are placeholders.
It would probably help to separate out the concerns according to CIA,

Some of the confidentiality concerns are covered in the privacy section but
there should be consideration of the possibility that revealing which emails
were rejected would assist a spammer. For instance, it would be a really bad
idea to tell senders how much of their messages are getting through filtering.
While the current spec doesn't seem to address that right now, it doesn't warn
people not to extend it to do that later.

On the integrity side, there might be some leverage for an attacker in filing
bogus reports if their objective was to cause the sender to change their
outbound email configuration in some fashion. For example, to purchase an
expensive mail delivery reliability product.

On the availability side, automating response to receipt of the reports could
well allow a service attack besides the resource exhaustion attacks described.
This is alluded to in the second bullet but this is not called out as a
service/availability issue.



-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux