Subject: [Uta] review of draft-ietf-uta-mta-sts-07

From: "Chris Newman" <[email-masked]>
Date: Thu, 20 Jul 2017 18:02:00 +0200

Overall, I find the document hard to read and the structure problematic. 
If I'm verifying STS policy, I want to know how to fetch the policy, 
then I want to know what to fetch. The document structure is awkward for 
that goal. And if I want to publish STS policy, I want to know where I 
publish it and then what I need to publish. An editorial pass to 
reorganize the document to be more useful and clear for an implementer 
would be helpful. There's also an overuse of "quotes" around terminology 
which is problematic in a document with JSON strings which need to be 
quoted in the context of protocol examples.

It'd be helpful to have an example workflow, possibly early in the 
document. Something like:

Example:
  recipient: [email-masked]
  Determine policy domain [section reference], in this case example.com
  Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record in 
policy domain). [section reference].
  If failure or invalid record, stop.
  If valid cached policy record, skip forward to SMTP connection.
  Connect to https server at mta-sts.example.com (mta-sts host in policy 
domain). [section reference]
  Verify HTTPS TLS certificate as matching domain mta-sts.example.com 
[section reference].
  Fetch policy from /.well-known/mta-sts.json [section reference].
  Connect to SMTP server according to SMTP standard.
  Perform STARTTLS
  Verify TLS negotiation and hostname matches STS policy [section 
reference].

> transmission into authenticated, downgrade-resistent encrypted
> tarnsmission.

Fix spelling: resistent->resistant, tarnsmission => transmission

> sts-version     = %x76 *WSP "=" *WSP %x53 %x54       ; "v=STSv1"
>                   %x53 %x76 %x31

I recommend you improve ABNF readability by referencing RFC 7405.

  std-version    = %s"v=STSv1"

>   The policy itself is a JSON [RFC7159] object served via the HTTPS 
> GET

This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or 
you need to explicitly require use of UTF-8 charset, or reference I-JSON 
(RFC 7493). With RFC 7159 there's a requirement to support and detect 
UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other 
Unicode encodings) that I find highly problematic for interoperability.

>   When fetching a new policy or updating a policy, the HTTPS endpoint
>   MUST present a X.509 certificate which is valid for the "mta-sts"
>   host (as described below), chain to a root CA that is trusted by the

After reading the document, I'm not sure I understand how to construct 
the DNS FQDN that I need to pass to the TLS API in order to validate the 
mta-sts host. In the example workflow above, I made a guess. But the 
document presently never says how to construct the FQDN explicitly.

>   The certificate MAY be checked for revocation via the Online
>   Certificate Status Protocol (OCSP) [RFC2560], certificate revocation
>   lists (CRLs), or some other mechanism.

Is there a reason this is a MAY rather than a SHOULD?

> 3.4.  Policy Selection for Smart Hosts and Subdomains

It's confusing to group two very different aspects of mail operations 
into a single section. I'd suggest making this two sections.

>   certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a

The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it to 
subjectAltName which does appear.

>   DNS-ID matching the "mx" pattern.  The MX's certificate MAY also be
>   checked for revocation via OCSP [RFC2560], certificate revocation
>   lists (CRLs), or some other mechanism.

Is there a reason this is a MAY rather than a SHOULD?

>   New fields are added to this registry using IANA's "Expert Review"
>   policy.

Please add some guidance to the expert reviewer on the criteria that 
should be met when registering new fields. You can leave the reviewer 
some wiggle room, but having guidance sets expectations for the person 
registering the new field, the expert reviewer and for any IESG appeal 
that might result from a disagreement.

> 8.  Security Considerations

One more security consideration:

This mechanism causes an MTA (an automated system) to adopt the role of 
an HTTPS client in a scenario where the HTTPS server may be hostile to 
operation of the MTA. A full HTTP stack is a large amount of code that 
may contain coding errors that expose the MTA to new implementation 
vulnerabilities. This threat can be partially mitigated by using a 
hardened HTTPS client library that has been tested against a fuzzing 
HTTPS test server. This threat can also be partially mitigated by 
isolating the HTTPS code into a separate process that does not have 
access to the normal MTA machinery and making sure the MTA machinery 
gracefully handles a wedged HTTPS client. Sites that are evaluating the 
cost/benefit of this functionality may wish to compare the new attack 
surface of this mechanism with the new attack surface of alternate 
mechanisms such DANE [RFC7672].

		- Chris

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 20 Jul 2017 20:54:51 +0200

Hey, Chris,

Thanks for the thorough review. A few inline comments off the cuff; others
we will have to address in the draft.

On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman <[email-masked]>
wrote:

> If I'm verifying STS policy, I want to know how to fetch the policy, then I
> want to know what to fetch. The document structure is awkward for that
> goal. And if I want to publish STS policy, I want to know where I publish
> it and then what I need to publish. An editorial pass to reorganize the
> document to be more useful and clear for an implementer would be helpful.

Do you have any suggestions of a restructuring? The current structure is
(of course) _intended_ to be natural, in that we start with how to discover
a policy (i.e., for senders, how to publish a policy), then how to validate
a policy (i.e., for senders, how to decide what should go in your policy),
then how to apply a policy (i.e. what the different "mode" options mean and
how they affect delivery).

I'm not at all averse to changing it, but it would help us a bit to have
more specific suggestions, if you have any. I and the other authors
obviously intended this to be a natural flow, so we may not be in the best
position to see what is awkward about it. :)

> There's also an overuse of "quotes" around terminology which is
> problematic in a document with JSON strings which need to be quoted in the
> context of protocol examples.
>

I think Appendix 2 covers more or less this, but in pseudocode. Are you
suggesting that it would be better to have that be textual rather than
pseudocode, be in-document rather than an appendix, or both?

>   The policy itself is a JSON [RFC7159] object served via the HTTPS GET
>>
>
> UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode
> encodings) that I find highly problematic for interoperability.
>
> After reading the document, I'm not sure I understand how to construct the
> DNS FQDN that I need to pass to the TLS API in order to validate the

Yes. The security value of OCSP is contentious (e.g.
https://www.imperialviolet.org/2014/04/19/revchecking.html) and support for
it in HTTPS client libs is (AFAICT) haphazard; e.g.
https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.htmlhttps://stackoverflow.com/questions/25803455/how-to-add-ocsp-support-into-python-requests-library.
Making OCSP a MUST seems to make implementation harder for questionable
gain.

> It's confusing to group two very different aspects of mail operations into
> a single section. I'd suggest making this two sections.

> should be met when registering new fields. You can leave the reviewer some
> wiggle room, but having guidance sets expectations for the person
> registering the new field, the expert reviewer and for any IESG appeal that
> might result from a disagreement.
>
> This mechanism causes an MTA (an automated system) to adopt the role of an
> HTTPS client in a scenario where the HTTPS server may be hostile to
> operation of the MTA. A full HTTP stack is a large amount of code that may
> contain coding errors that expose the MTA to new implementation
> vulnerabilities. This threat can be partially mitigated by using a hardened
> HTTPS client library that has been tested against a fuzzing HTTPS test
> server. This threat can also be partially mitigated by isolating the HTTPS
> code into a separate process that does not have access to the normal MTA
> machinery and making sure the MTA machinery gracefully handles a wedged
> HTTPS client. Sites that are evaluating the cost/benefit of this
> functionality may wish to compare the new attack surface of this mechanism
> with the new attack surface of alternate mechanisms such DANE [RFC7672].
>
>                 - Chris
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 21 Jul 2017 10:16:23 +0200

On 20 Jul 2017, at 20:54, Daniel Margolis wrote:
>> then I

I can't work through more precise suggestions at the moment.

> pseudocode, be in-document rather than an appendix, or both?

Both.

>> Unicode

I never suggested MUST OCSP, I suggested SHOULD implement some mechanism 
to check certificate revocation. From my perspective, it doesn't have to 
be any mechanism in particular, but having no way to revoke certificates 
is a problem. There have been real world cases where certificate 
revocation was needed. It's possible software update mechanisms have 
been more effective than other revocation mechanisms in practice, so 
that may be sufficient to meet the recommendation.

		- Chris

>> into
>> some
>> hardened

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 21 Jul 2017 11:36:34 +0200

> I can't work through more precise suggestions at the moment.

OK. I'll take another look at it with your suggestions in mind, but I'd
also like feedback from you or others on the list. Since we're quite a few
revisions in, I hesitate to make really large scale stylistic or editing
changes without broader feedback on what they should be--that's a bit of
trying to hit a target in the dark.

>>> the
>> https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.html
>> https://stackoverflow.com/questions/25803455/how-to-add-ocsp
>> -support-into-python-requests-library.
> to check certificate revocation. From my perspective, it doesn't have to be
> any mechanism in particular, but having no way to revoke certificates is a
> problem. There have been real world cases where certificate revocation was
> needed. It's possible software update mechanisms have been more effective
> than other revocation mechanisms in practice, so that may be sufficient to
> meet the recommendation.

I'm OK with a SHOULD for generic "revocation support," but this feels like
it strays outside the scope of the spec (insofar as this isn't an issue
specific to STS's use of HTTPS with web PKI). Maybe instead something to
call out in Security Considerations?

>>> an
>>> may

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Jul 2017 11:39:43 +0200

> also like feedback from you or others on the list. Since we're quite a
> few revisions in, I hesitate to make really large scale stylistic or
> editing changes without broader feedback on what they should be--that's
> a bit of trying to hit a target in the dark. 
>  

Thx Daniel. Lets see where we are after you've spun out the post-WGLC
draft. At that point we really need more concrete text suggestions to
be able to address reviewer issues.

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Jul 2017 15:19:27 +0000

On Thu, Jul 20, 2017 at 06:02:00PM +0200, Chris Newman wrote:

> It'd be helpful to have an example workflow, possibly early in the document.
> Something like:
> 
> Example:

This introduces a downgrade attack on already cached data.  The
TXT record alone cannot suppress already cached policy.

>  If valid cached policy record, skip forward to SMTP connection.

Any cached data is used unless a TXT record indicates a different
policy id than the one cached.  In which case an attempt is made
(perhaps in the background) to obtain a fresh policy.

> ...

This sort of thing was supposed to be covered in the state machine
description at the end...

> This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or you
> need to explicitly require use of UTF-8 charset, or reference I-JSON (RFC
> 7493). With RFC 7159 there's a requirement to support and detect UTF-16LE,
> UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode encodings)
> that I find highly problematic for interoperability.

No non-ascii data is presently anticipated, but for future proofing
the encoding should be assumed UTF-8.

> DNS FQDN that I need to pass to the TLS API in order to validate the mta-sts
> host. In the example workflow above, I made a guess. But the document
> presently never says how to construct the FQDN explicitly.

There is no single FQDN.  The certificate is matched against any
of the names in the "mx" attribute.  The SNI should be taken from
the MX hostname.

> Is there a reason this is a MAY rather than a SHOULD?

Postfix will not implement either CRL checks (reliably maintained
CRLs are an exotic beast) or OCSP.  We could implement support for
stapled OCSP, but I am not aware of much support for that on the
server side.

> subjectAltName which does appear.

I prefer "subject alternative name (SAN)" and then "SAN" thereafter.
A "terminology" section entry may be appropriate.

> Is there a reason this is a MAY rather than a SHOULD?

See above.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 31 Jul 2017 12:04:12 -0400

> description at the end...

I thought it was covered by that. Like I said above, I'm happy to introduce
bigger changes, but I'd want more specific feedback and broader feedback
from the rest of the WG due to the fairly late stage of the draft.

> mta-sts

I think you are talking about two different things. Chris is referencing
the validation requirement when fetching the policy, not for the MX host
validation itself. In the former case, the validation should be against the
"mta-sts" host at the target domain (so the FQDN is "mta-sts.example.com"
or whatever); the latter case as Viktor described.

I think Chris's confusion was over whether "'mta-sts' host" refers to the
hostname (it does) or is a term of art referring to some specific host,
and, if so, what is the identity to validate. Rephrasing this to something
like,

"which is valid for the 'mta-sts' host at the policy domain, e.g. '
mta-sts.example.com'"

would probably clear that up. :)

> stapled OCSP, but I am not aware of much support for that on the

Right. I expect widespread non-adoption of such a SHOULD, but maybe it's
worth instead calling it out in Security Considerations.