Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC

Jim Fenton <fenton@bluepopcorn.net> Fri, 02 March 2018 18:45 UTC

Return-Path: <fenton@bluepopcorn.net>
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 98AAC12E8CD for <uta@ietfa.amsl.com>; Fri, 2 Mar 2018 10:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 xQ_fZdqxhSAA for <uta@ietfa.amsl.com>; Fri, 2 Mar 2018 10:45:08 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D4012E8D2 for <uta@ietf.org>; Fri, 2 Mar 2018 10:45:07 -0800 (PST)
Received: from steel.local (sfosf0017s350801.wiline.com [64.71.6.2] (may be forged)) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w22Ij5ZA002398 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <uta@ietf.org>; Fri, 2 Mar 2018 10:45:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1520016306; bh=5ZcP7yAKhQ7pUY0K1xgY59DRHHVMhD13nD+oKXzagEI=; h=Subject:To:References:From:Date:In-Reply-To; b=a5rZehw/vQKBXqVoJKsh1PHHWyR60x80F7DwnMtF5oPzBHlt6xkeQLa+82reKTB/r E/B+CKmM47czKE9WU9pXGU2VM6iHRAmH5Zzb91Uy48wkc2nifwJItq3nWTyMQhePBb YVcNdfHQIiXOQxkGjWUpWY3nFOYFpCIozPV7rlPo=
To: uta@ietf.org
References: <03d601d3aadb$1833bd00$489b3700$@smyslov.net> <e65d33c4-7156-ce55-65b7-b62bd91fb029@bluepopcorn.net> <033301d3b21e$e5aefd90$b10cf8b0$@gmail.com>
From: Jim Fenton <fenton@bluepopcorn.net>
Message-ID: <fb4d7550-bc69-0826-72d4-ed5b40ac3c73@bluepopcorn.net>
Date: Fri, 02 Mar 2018 10:45:00 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <033301d3b21e$e5aefd90$b10cf8b0$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/gTQ7rKOLq_qd5N6ZXYeTAIPN4hw>
Subject: Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
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: Fri, 02 Mar 2018 18:45:18 -0000

On 3/2/18 4:06 AM, Valery Smyslov wrote:
> Hi Jim,
>
> just one comment:
>
>> Section 5.3 paragraph 3: "MUST match the value found in the filename"
>> but the value in the filename is only a recommendation (section 5.1). I
>> continue to lean toward not depending on values in other than the
>> message body (single source of truth).
> I believe that this section describes how the "TLS-Report-Submitter" is filled in
> by sender, not how it is checked by the receiver. Section 5.6. already states
> that the report body is the only authoritative source for receiver. 
> I agree that the current wording is a confusing and can be improved. For example:
>
>    When constructed the "TLS-Report-Submitter" value MUST match the value in the
>    filename (if it is present there) and the [RFC5321] domain from the "contact-info" from the
>    report body.  These message headers MUST be included and should allow
>    for easy searching for all reports submitted by a report domain or a
>    particular submitter, for example in IMAP [RFC3501]:

My opinion is that since section 5.6 effectively says the filename (and
therefore the TLS-Report-Submitter) doesn't matter because only the body
is authoritative, the MUST requirements are excessive. I do see the
value of the TLS-Report-Submitter header field as a convenience feature
for the IMAP search usage that was mentioned, so I would say that it
SHOULD match the body.

I agree with Viktor's comment that the filename should be treated as an
opaque string. Setting specific requirements for it only makes the
protocol more brittle, and as he points out, how and whether the
filename is used is implementation-dependent anyway.

-Jim