Subject: [Uta] Benjamin Kaduk's No Objection on draft-ietf-uta-mta-sts-17: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 09 May 2018 10:31:09 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-uta-mta-sts-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the well-written document!  Other people have noted some things already,
so I can only add small things.

Section 3.1

Did you consider ABNF that would let new versions be defined without
having to redefine the ABNF?

Section 3.2

   When fetching a policy, senders SHOULD validate that the media type
   is "text/plain" to guard against cases where webservers allow
   untrusted users to host non-text content (typically, HTML or images)
   at a user-defined path.  All parameters other charset=utf-8 or
   charset=us-ascii are ignored.

Nit: "other than"

Section 5

Should the "enforce" text also mention the STARTTLS requirement from
Section 4?

Section 7.2

It's probably better to cite this as BCP 195 than RFC 7525 directly.

Section 8.1

   Recipients should also prefer to update the HTTPS policy body before
   updating the TXT record; this ordering avoids the risk that senders,
   seeing a new TXT record, mistakenly cache the old policy from HTTPS.

It seems like this risk would be mitigated if the "id" value from
the TXT record was required to also appear in the policy body as an
identifier.  But presumably that would cause issues elsewhere, as it
is not the case in the current document.

---

From: [email-masked]
Date: Wed, 09 May 2018 11:43:50 -0700 (PDT)

> having to redefine the ABNF?

First, since the cost of "redefinition" is a single line of ABNF:

  sts-version    =/ %s"v=STSv2"

it's hardly high cost. As for the corresponding code, in my implementation it
would correspond to a single line change. Again, hardly high cost.

Second, this approach is used in numerous other specifications in the email
space, so it is hardly obscure. What would be obscure is some other sort of
extension mechansism. We've tried other mechanisms on several past occasions,
including the original MIME specificaiton, and the results have been poor.
Those experiences have led to the current approach.

Third, the only reasons I can think of for a version change would be to change
either some aspect of the syntax or some basic semantics of the record/object.
Those changes are almost certainly going to be a lot more difficult than
supporting an additional version number.

> It's probably better to cite this as BCP 195 than RFC 7525 directly.

Given the liklihood of BCP 195 being upgraded to TLS 1.3 at some point without
full consideration of the impace on email infrastructure,  I'm by no means sure
that's the case.

Or, to put this another way, if you want to reference a changing set of secure
substrate best practices here, that in turn imposes a requirement on future
versions of those best practices to give full consideration to email
infrastructure realities.

As the wise man once said, "Are you sure this is what you want?"

> is not the case in the current document.

The problem with including the id in the policy is that now you have a gap
no matter how you order the update.

				Ned

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 May 2018 17:37:18 -0500

> First, since the cost of "redefinition" is a single line of ABNF:
[...]

("Yes" would have sufficed.)

> As the wise man once said, "Are you sure this is what you want?"

It seems rather inherent that when one is using the phrase
"infrastructure realities" in this sort of context, it will be in
conflict with "best current practice", because if there was no
conflict, it wouldn't be worth talking about.  So if this is simply
a matter of giving a more direct pointer to the conflict between
deployed reality and (ideal) best practices, yes, I'm fine with
that.

I also expect that a hypothetical rev of BCP 195 to include TLS 1.3
will take into account all consumers of TLS, and not limit itself to
just the Web ecosystem, since TLS is a general-purpose protocol.

> no matter how you order the update.

Right.

-Benjamin

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 10 May 2018 16:49:36 +0200

On Thu, May 10, 2018 at 12:38 AM Benjamin Kaduk <[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Yes, but an alternate approach is to have the "id" in the TXT become a part
of the policy URI--e.g.

.well-known/mta-sts-$id.txt

We chose not to do this because it seemed like greater complexity with
little benefit; in general, it's not hard advice to tell people to publish
the policy body first, and fixed paths seem a bit more coherent to me. But
I thought I'd call that out for interest's sake.

>
> -Benjamin
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>