Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

[Daniel Margolis <[e-mail]>]

Of course a smart attacker who can MITM insecure DNS can spoof reports (and
optionally MITM the DKIM lookup to make the reports look valid). So it's
sort of turtles all th way down, no?

On Tue, Mar 28, 2017 at 12:38 PM, Federico Santandrea <
[e-mail]> wrote:

> On 27/03/2017 13:41, Daniel Margolis wrote:
>
>> Anyway, I'm very open to suggestions on how to make this more
>> transparent within the scope of TLSRPT, but I don't love the idea of
>>  adding policy complexity by letting recipients specify what to do in
>>  this scenario.
>>
>
> To allow the receiving domain owner to spot abnormal situations without
> complicating the report, we could add semantics to the date-range.
>
> The draft says:
>
>    o  "date-time": The date-time indicates the start- and end-times for
>       the report range.  It is provided as a string formatted according
>       to Section 5.6, "Internet Date/Time Format", of [RFC3339].  The
>       report should be for a full UTC day, 0000-2400.
>
> If we replace that with something along the lines of:
>
>    o  "date-time": The date-time indicates the start- and end-times for
>       the report range.  It is provided as a string formatted according
>       to Section 5.6, "Internet Date/Time Format", of [RFC3339].
>       "start-datetime" should be 0000 UTC of the relevant day or the
>       first time a policy was discovered, whichever comes last.
>       "end-datetime" should be 2400 UTC of the relevant day or the
>       time the last cached policy did expire, whichever comes first.
>
> Then one would normally see reports for one whole day, except when one
> first publishes a policy and in abnormal situations where a policy
> has been allowed to expire with no new one available.
>
> In that case it will be clear that for some part of the day no policy
> was considered, which can be expected (if the domain doesn't publish a
> policy anymore) or unexpected (network problems/attacks on the sending
> MTA or, if the problem is widespread across senders, possible
> misconfiguration of denial of service on records or endpoints).
>
> If in the same day a policy is discovered again after a previous one
> has expired, then we would have more than one report for that day:
> for instance, one from 0000 to the time the policy had expired, and
> another one from the time a new policy had been discovered to 2400.
> So the gap during which no policy applied would be evident.
>
> --
> Federico
>
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>