Subject: [Uta] Updated SMTP STS Draft

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 25 Apr 2016 13:29:35 +0000

Hello,

We've incorporated much of the feedback we've received from the community, and would like to present updated drafts. 

* One of the most evident changes is that we've split the draft into two separate documents; one for the STS policy, and one for the TLS reporting.  These are meant to replace the original SMTP STS draft (https://datatracker.ietf.org/doc/draft-margolis-smtp-sts-00).
* We've altered the name a bit from "SMTP STS" to "MTA STS" to be more in line with DEEP, and have also added elements for the DEEP registry.  
* After some deliberation amongst the authors, we've also decided to remove the DNSSEC-related options for the STS policy, which should simplify work for those wishing to deploy STS validation.  
* Within the TLS reporting, we've explicitly mentioned several failure modes, including those specifically relating to DANE and MTA STS.  
* We've also altered the report syntax to use JSON instead of XML.  

Please see drafts here:

https://datatracker.ietf.org/doc/draft-brotman-mta-sts/

And

https://datatracker.ietf.org/doc/draft-brotman-smtp-tlsrpt/

We'd like others to review and encourage further discussion relating to these drafts.  Thank you for your time.

--
Alex Brotman
Engineer, Anti-Abuse
Comcast

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Apr 2016 15:37:42 +0200

> * We've also altered the report syntax to use JSON instead of XML.  

Thanks,

In BA there was consensus (pretty strong at that) to adopt this draft as
a WG document.

This starts an adoption call for adoption as a WG document. Please
indicate your support or objection (with motivation) for WG adoption
no later than EOB (any TZ) May 1st

	Cheers Leif

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

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Apr 2016 15:49:18 +0200

> In BA there was consensus (pretty strong at that) to adopt this draft as

s/this draft/these drafts/

This is 2 (two) separate consensus calls. Please express your support
or objection for either/both documents going forward as WG documents.

---

From: Mark Risher <[email-masked]>
Date: Mon, 25 Apr 2016 12:21:05 -0700

Hi all
We tried to constrain our edits here to only those topics discussed at the
Argentina face-to-face, as Alex summarized in his overview. Hopefully these
documents will look entirely familiar to anyone who reviewed
draft-margolis-00

I vote for both to join the working group.

Thanks for your help, everyone,
/m

---
Mark Risher | Google | 650-253-3123
On Apr 25, 2016 6:49 AM, "Leif Johansson" <[email-masked]> wrote:

> >> We've incorporated much of the feedback we've received from the
> community, and would like to present updated drafts.
> >>
> >> * One of the most evident changes is that we've split the draft into
> two separate documents; one for the STS policy, and one for the TLS
> reporting.  These are meant to replace the original SMTP STS draft (
> https://datatracker.ietf.org/doc/draft-margolis-smtp-sts-00).
> >> * We've altered the name a bit from "SMTP STS" to "MTA STS" to be more
> in line with DEEP, and have also added elements for the DEEP registry.
> >> * After some deliberation amongst the authors, we've also decided to
> remove the DNSSEC-related options for the STS policy, which should simplify
> work for those wishing to deploy STS validation.
> >> * Within the TLS reporting, we've explicitly mentioned several failure
> modes, including those specifically relating to DANE and MTA STS.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 26 Apr 2016 09:51:16 +0700

> On 25 Apr 2016, at 20:37, Leif Johansson <[email-masked]> wrote:
> 

I support adoption of these drafts as WG documents, they will need some further work though. I'm of course reviewing and will provide feedback both on list and have been talking with (some of) the authors backchannel as well.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 30 Apr 2016 18:14:18 +0700

Hi,

I'm now specifically reviewing the STS reporting draft. We currently have a
discussion on file formats within STLE/LE/Certbot. I think CBOR would be a
nice format if things get bigger. I'm aware you just switched to JSON and
in your specific use-case JSON will probably suffice. The
future-work/forensic-reporting mode is something I'd be specifically
interested in in that regard. Once these reports get big, JSON might be
suboptimal.

What's the WGs opinion on that?

Aaron

On Tue, Apr 26, 2016 at 9:51 AM, Aaron Zauner <[email-masked]> wrote:

> I support adoption of these drafts as WG documents, they will need some
> further work though. I'm of course reviewing and will provide feedback both
> on list and have been talking with (some of) the authors backchannel as
> well.
>
> Aaron
>

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2016 16:33:58 -0000

>What's the WGs opinion on that?

DMARC reports are XML and I don't know anyone who finds them too big
to handle.  So long as you use the application/gzip compression that
I arranged for DMARC reports, the size of the messages should be
about the same no matter what the encoding is.

XML and JSON have the advantage that there are zillions of existing
libraries that people already know how to use, and you can look at the
reports in a text editor while you're debugging your code.  I would
encourage leaving well enough alone.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2016 19:37:13 -0000

>We'd like others to review and encourage further discussion relating to these drafts.  Thank you for your time.

I'm quite uncomfortable with the bit that says you look up the policy
at https://policy._mta_sts.example.com/current

By my reading of RFC 3986 which defines URIs, that's not a URI.
Section 3.2.2. does have ABNF which allows underscores in the host
part, but it then has text on page 21 that says that names looked up
in the DNS are RFC 1123 hostnames that are letter, digit, hyphen
only.  It says the underscores are intended for names looked up in
other ways.

My CA (Startcom) won't sign names with underscores, and I doubt that
other CAs will, which makes them rather unappealing.

I have two suggestions, a reasonable one and a gross kludge.

The reasonable one is to use SRV, so it'd be like this:

 _sts._tcp SRV 0 0 443 sts-policy.example.com.

Bad guys could spoof your SRV record without DNSSEC, but they can also
spoof the A record for policy._mta_sts.example.com so that horse left
the barn.  You could require that the target of the SRV has to be a
subdomain of the original domain which, along with the signed SSL
certificate, would limit the scope of evil.  This proposal has the
advantage of being built on top of well established standards, and the
disadvantage that looking up SRV records is still alleged to be hard
in some contexts (but I don't think ones that matter here.)

The gross kludge is to use xn--sts0 as the tag, e.g.

 https://policy.xn--sts0.example.com/current

The string "sts0" is deliberately invalid punycode, so while xn--sts0
is a valid hostname label, it's not an A-label and will never appear
in an IDN hostname, Hence it's very unlikely to collide with other
uses.  I hope I don't have to explain why it's a kludge.  My CA will
sign it. I checked.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 30 Apr 2016 22:00:40 +0000

> at https://policy._mta_sts.example.com/current

That's surely a mistake.  It should have been a ".well-known"
URI at the domain with no prefixes.

>  _sts._tcp SRV 0 0 443 sts-policy.example.com.

No, SRV records break the security model, because untrusted DNS
now supplies the reference identifier.  The URI needs to be
entirely determined from the nexthop domain with no insecure
inputs.

> uses.  I hope I don't have to explain why it's a kludge.  My CA will

This is not a good idea, such names will be rejected by some systems. 

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2016 22:29:30 -0000

>URI at the domain with no prefixes.

We talked about this at great length over dinner in Buenos Aires.
Demanding a web server at the same domain name used in e-mail
addresses is operationally a non-starter for large organizations.

> No, SRV records break the security model, because untrusted DNS now
> supplies the reference identifier.  The URI needs to be entirely
> determined from the nexthop domain with no insecure inputs.

In the absence of DNSSEC, there's *always* insecure inputs, such as
the A or AAAA records that point to the web server.

As the next two sentences said:

  certificate, would limit the scope of evil. 

>This is not a good idea, such names will be rejected by some systems. 

Got any examples?  I haven't looked very hard either way.  Note that
nothing should be trying to turn it into a U-label.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 May 2016 01:19:36 +0000

> addresses is operationally a non-starter for large organizations.

STS is primarily for the large email providers authoring the draft,
for whom this is not a real obstacle.  Making it convenient for
all other domains might be nice, but is less important.  Not all
domains will adopt STS regardless of the specification.

> the A or AAAA records that point to the web server.

Spoofing of A records are irrelevant, the WebPKI certificate binds
the name, and assures the client that the correct server has been
reached.

>   the barn.

Spoofing of A records is irrelevant, the client detects the forgery
when the certificate fails to match.  Not so with SRV records,
because (presumably) the reference identifier becomes the target
hostname from the SRV record.

>   You could require that the target of the SRV has to be a

This does not adequately address the problem, domains do not
generally control (or trust) all the content hosted by their
sub-domains.  This is why a well known URI anchored at the
original domain is needed.

> nothing should be trying to turn it into a U-label.

No example at my fingertips.  All kinds of software performs hostname
validation, whether there's a conversion to U-labels or not.  It
is not a good idea to tempt fate with invalid inputs.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 1 May 2016 01:26:33 -0000

>for whom this is not a real obstacle.

They were there at dinner Buenos Aires, and that is most definitely
not what they said.  Perhaps they'll chime in when they get to work
on Monday.

Indeed, it's pretty much the opposite -- on my tiny FreeBSD box I can
set up the web servers to do whatever I want, but at big organizations
the mail and web operators are often in different silos.

R's,
John