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

ned+uta@mrochek.com Sun, 17 June 2018 15:31 UTC

Return-Path: <ned+uta@mrochek.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 12466130EB9 for <uta@ietfa.amsl.com>; Sun, 17 Jun 2018 08:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 9ZBveiFPPZeD for <uta@ietfa.amsl.com>; Sun, 17 Jun 2018 08:31:53 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 33F61130E99 for <uta@ietf.org>; Sun, 17 Jun 2018 08:31:53 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QTT3BXJHWG011KPX@mauve.mrochek.com> for uta@ietf.org; Sun, 17 Jun 2018 08:26:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1529249209; bh=XoNQjkQnYo/+IFDdqJ4J8ec0Ya9LJyUzNrd4WCrMf+w=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=gx/SbBaIIQHHVHn19vE0A2crSVVvxBiNDrKKJb0CjndkXnqOU60NHhD2wmcxSJ8O8 JYty6jHWfG54V7jrexW1B8ty1pVbuMGPJvO0HZ4ACGoOvSYeZj+24Mhd7eTtsiDkFN F+51sXuE6l/qigYyU9oTHR5Cm+tyd7BpzrLL19Hc=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QTQJ594ZB4010GDE@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for uta@ietf.org; Sun, 17 Jun 2018 08:26:46 -0700 (PDT)
From: ned+uta@mrochek.com
Cc: uta@ietf.org
Message-id: <01QTT3BVJBDE010GDE@mauve.mrochek.com>
Date: Sun, 17 Jun 2018 08:10:42 -0700
In-reply-to: "Your message dated Sat, 16 Jun 2018 22:14:18 -0400" <1E504B81-B7C0-4641-BB3F-FA6740D31509@dukhovni.org>
References: <152897880480.441.9920870371227371865@ietfa.amsl.com> <bef3efbe-0bec-9725-b7a2-224d6bbab24b@isode.com> <m38t7hur3m.fsf@carbon.jhcloos.org> <EC082EFE-C1C9-496B-B8EE-B49FDDD7B4A6@dukhovni.org> <01QTS8QK3Z50010GDE@mauve.mrochek.com> <1E504B81-B7C0-4641-BB3F-FA6740D31509@dukhovni.org>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/DcQpiUKc-1IxxWQbz1YDiJgocWE>
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: Sun, 17 Jun 2018 15:32:05 -0000

> > On Jun 16, 2018, at 8:48 PM, Ned Freed <ned.freed@mrochek.com> wrote:
> >
> >> 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.
> >
> > It's not a subtype, it's a suffix that applies to all future uses of gzip
> > in any future media type. Are you completely confident that this will in fact
> > be the right choice for all future uses?

> Well, if this is to be a "+gzip" suffix, it presumably represents a
> compressed form of the base media type,

This is just not how media type suffixes work. There is no "base media type"
the suffix modifies - for example, if the suffix is +xml or +ber, what's the
type underneath the XML or BER representation supposed to be?

And in the case of +zip - which is widely used - it is the rule, not
the exception, for there to be multiple "files" present, and in some
cases even a directory structure.

> which might reasonably be expected to be a single object.

No, not really.

> Certainly in the case of the motivating use-case (tlsrpt). 

That's true, but you're not defining a suffix for a single use-case. You're
defining a suffix for all future cases as well. And as I said before, are you
prepared to *guarantee* that nobody will ever use +gzip as a container for
multiple "files" - epsecially since there's running code sayng that other
similar media type suffixes are used this way all the time?

> Though, admittedly, this not a proof that some media type might not in its gzip
> incarnation become multiple compressed streams. If there is a plausible
> use-case for such a thing, then the recommendation to ensure that only one
> stream be present would apply to various specific use-cases, such as "tlsrpt",
> but not generally.  Feel free to ignore or use these and the previous remarks
> as you see fit...  They are not blocking objections.

Whereas in my capacity as media type suffix reviewer, it's my responsibility
to make sure that security considerations cover the full range of possible
isssues. As such, coverage of an obvious one, especially given the current
widespread attacks on similar formats, is a requirement for my approval of
the registration.

				Ned