Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-23.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 14 June 2018 19:16 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 E3EEE130EED for <uta@ietfa.amsl.com>; Thu, 14 Jun 2018 12:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 UvQMBKq1NVup for <uta@ietfa.amsl.com>; Thu, 14 Jun 2018 12:16:07 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBC9130EE0 for <uta@ietf.org>; Thu, 14 Jun 2018 12:16:06 -0700 (PDT)
Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D9CBE7A330D for <uta@ietf.org>; Thu, 14 Jun 2018 19:16:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <m38t7hur3m.fsf@carbon.jhcloos.org>
Date: Thu, 14 Jun 2018 15:16:04 -0400
Content-Transfer-Encoding: 7bit
Reply-To: uta@ietf.org
Message-Id: <EC082EFE-C1C9-496B-B8EE-B49FDDD7B4A6@dukhovni.org>
References: <152897880480.441.9920870371227371865@ietfa.amsl.com> <bef3efbe-0bec-9725-b7a2-224d6bbab24b@isode.com> <m38t7hur3m.fsf@carbon.jhcloos.org>
To: uta@ietf.org
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/6G2TcqHgcGr2cEHiLOsFA_N7Q7E>
Subject: Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-23.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 14 Jun 2018 19:16:09 -0000


> On Jun 14, 2018, at 3:04 PM, James Cloos <cloos@jhcloos.com> wrote:
> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-23
> 
> Some newlines got lost in that update.
> 
> The diff makes it easy to see.
> 
> Also, the new copy needs:
> 
>  s/by and Adler-32/by an Adler-32/
> 
> Otherwise it looks good.

I am surprised to see the security considerations refer to
multi-file gzip inputs, and processing of the filename
metadata inside the gzip stream.  I've never seen anyone
do that.  In practice 'gzip' archives are assumed to
contain just one "file", and the name from the gzip
metadata is ignored, instead the user specified where
to write the output.

I rather think it makes more sense here to specify that
the "+gzip" MIME sub-type always holds exactly one
compressed object, and that the filename hint in
the compressed stream should be ignored.

By far the more interesting issue with compressed
content, is potential DoS, because small inputs
can uncompress to unreasonably large outputs.
Applications might want to set limits on the amount
of data they're willing to extract from the compressed
stream.

-- 
	Viktor.