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

[[e-mail]]

> > On Jun 14, 2018, at 3:04 PM, James Cloos <[e-mail]> 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.

If you are registering a media type suffix you have to cover all of the
format's capabilities. What has or has not been used in the past is irrelevant.

> 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?

> 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.

That's covered in the format's security considerations, but of course it could
be repeated here if you think it's important to do so.

				Ned