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

From: [email-masked]
Date: Thu, 14 Jun 2018 05:20:04 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.

        Title           : SMTP TLS Reporting
        Authors         : Daniel Margolis
                          Alexander Brotman
                          Binu Ramakrishnan
                          Janet Jones
                          Mark Risher
	Filename        : draft-ietf-uta-smtp-tlsrpt-23.txt
	Pages           : 32
	Date            : 2018-06-14

Abstract:
   A number of protocols exist for establishing encrypted channels
   between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
   MTA-STS.  These protocols can fail due to misconfiguration or active
   attack, leading to undelivered messages or delivery over unencrypted
   or unauthenticated channels.  This document describes a reporting
   mechanism and format by which sending systems can share statistics
   and specific information about potential failures with recipient
   domains.  Recipient domains can then use this information to both
   detect potential attacks and diagnose unintentional
   misconfigurations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-23
https://datatracker.ietf.org/doc/html/draft-ietf-uta-smtp-tlsrpt-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-23

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Jun 2018 13:50:47 +0100

>     detect potential attacks and diagnose unintentional
This version updates Security Considerations for +gzip Media Type 
suffix, based on feedback from the Media Suffix Designated Expert.

---

From: James Cloos <[email-masked]>
Date: Thu, 14 Jun 2018 15:04:45 -0400

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

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Jun 2018 15:16:04 -0400

> On Jun 14, 2018, at 3:04 PM, James Cloos <[email-masked]> wrote:
> 

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.

---

From: James Cloos <[email-masked]>
Date: Thu, 14 Jun 2018 15:31:19 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

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

That did also surprise me, but the rfc makes it clear that it is
permitted and thus one must assume that bad actors would try that
as an attack.  Since the update came from a media-type expert, it
is probably something he thinks all GZIP uncomressors should
keep in mind.

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

That idea has value.

VD> By far the more interesting issue with compressed
VD> content, is potential DoS, because small inputs
VD> can uncompress to unreasonably large outputs.

Another attack vector everyone needs to expect.

VD> Applications might want to set limits on the amount
VD> of data they're willing to extract from the compressed
VD> stream.

Good advice.

-JimC

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Jun 2018 10:28:23 +0100

> Some newlines got lost in that update.
Yes, I already told RFC Editors. They can fix it before publication.
>    s/by and Adler-32/by an Adler-32/
Thanks.

---

From: [email-masked]
Date: Sat, 16 Jun 2018 17:48:05 -0700 (PDT)

> metadata is ignored, instead the user specified where

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.

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

> of data they're willing to extract from the compressed

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Jun 2018 22:14:18 -0400

> On Jun 16, 2018, at 8:48 PM, Ned Freed <[email-masked]> wrote:
> 

Well, if this is to be a "+gzip" suffix, it presumably represents a compressed form of the base media type, which might reasonably be expected to be a single object.  Certainly in the case of the motivating use-case (tlsrpt).  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.

-- 
	Viktor.

---

From: [email-masked]
Date: Sun, 17 Jun 2018 08:10:42 -0700 (PDT)

> 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