> On Jun 14, 2018, at 3:04 PM, James Cloos <[email protected]> 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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
