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

Federico Santandrea <federico.santandrea@diennea.com> Tue, 28 March 2017 10:38 UTC

Return-Path: <federico.santandrea@diennea.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CF3129353 for <uta@ietfa.amsl.com>; Tue, 28 Mar 2017 03:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKugykPXvr6u for <uta@ietfa.amsl.com>; Tue, 28 Mar 2017 03:38:27 -0700 (PDT)
Received: from mail3.informatica.it (mail3.informatica.it [151.99.189.163]) by ietfa.amsl.com (Postfix) with ESMTP id 0F617129893 for <uta@ietf.org>; Tue, 28 Mar 2017 03:38:26 -0700 (PDT)
From: Federico Santandrea <federico.santandrea@diennea.com>
References: <d42e535b43f14fc68b9b3e22cdff2e51@EXC01-Arezzo.diennea.lan> <BF2CE255-261C-4006-B8C9-9D9518EF258F@dukhovni.org> <CANtKdUffuLwo--4KY7XL3NsZanUcjat1MUmZF7-H_UYBergdSA@mail.gmail.com>
To: uta@ietf.org
Message-ID: <8a9cd559-d27f-c245-bfb4-2bc2ecea6ea1@diennea.com>
Date: Tue, 28 Mar 2017 12:38:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CANtKdUffuLwo--4KY7XL3NsZanUcjat1MUmZF7-H_UYBergdSA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-GatewayId: federico.santandrea=2.601301300016063333123308@diennea.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/mSRgxV13EYv813OwrN5QZDx-Tac>
Subject: Re: [Uta] Comments on draft-ietf-uta-mta-sts-03
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 10:38:29 -0000

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