Subject: [Uta] Comments on STS Strict Transport Security

From: Neil Cook <[email-masked]>
Date: Tue, 22 Mar 2016 09:12:53 +0000

Some feedback on this draft:

1) The language around policy authentication vs validation vs application is very confusing to me. The terms “authentication” and “validation” seem to be used in a variety of contexts with different meanings.

For example in "3.3.  Policy Authentication"

   The security of a domain implementing an SMTP STS policy against an
   active man-in-the-middle depends primarily upon the long-lived
   caching of policies.  However, to allow recipient domains to safely
   serve new policies _prior_ to the expiration of a cached policy, and
   to prevent long-term (either malicious or active) denials of service,
   it is important that senders are able to validate a new policy
   retrieved for a recipient domain.  There are two supported mechanisms
   for policy validation:

So the draft talks about authentication, and then immediately starts talking about being able  to “validate” new policies. I think this should be “authenticate”.

   When fetching a new policy when one is not already known, or when
   fetching a policy for a domain with an expired policy,
   unauthenticated policies MUST be trusted and honoured.

Back to the use of “unauthenticated” here. Even though authentication hasn’t really been defined yet, or least distinguished from validation.

When fetching  a policy and authenticating it, as described in detail in _Policy_
   _Application_, policies will be authenticated using the mechanism
   specified by the existing cached policy.

And here.

   Note, however, as described in detail in _Policy_ _Application_, that
   new policies MUST NOT be considered as valid if they do not validate
   on first application.  That is, a freshly fetched (and unused) policy
   that has not successfully been applied MUST be disregarded.

Here validation seems be being used as meaning “parsing and applying successfully”.

Also, it’s confusing to me that this paragraph talk about policy validation, but instead refers the reader to the “Policy Application” section, rather than the “Policy Validation” section.

I think the terms should be used as follows (and please correct me if I’m misunderstanding the draft):

- “authentication” refers to the concept of “trusting” that a retrieved policy is the policy actually intended by the remote domain and not a malicious policy inserted through DNS spoofing or whatever, and should be used in the this context. Since STS is ‘trust-on-first-use’, this means that authentication is normally a no-op, except in the case of retrieving a new policy when a cached policy is already in operation.
I’d like to see the section on Policy Authentication reworded so that this is clearer, by moving the language "When fetching a new policy when one is not already known…” to the start of this section, and stating that such policies are thus implicitly authenticated. Explicit authentication happens when a new policy is retrieved and authenticated according to the two mechanisms shown in “Policy Authentication”, based on the “a" field from the already cached policy.

- The section “Policy Validation” actually refers to certificate validation, based on the “c” field in the cache policy. This seems to be different to policy validation to me, which should mean a well-formed and parseable policy. The section “Policy Validation” actually seems to me to just be the first step in policy “application”.

- “application” should refer to the process of applying an authenticated and valid policy.

2) The logic as to when to use the “authentication” mechanism as described by the “a” field seems strange to me. The draft states that policies should be cached until the expiration time (which is implicitly the longer of the TTL and the “e” field). It also states that the only time the authentication method specified in the “a” field should be used is when the applied policy is invalid and the policy specifies rejection (step 4 of Policy Application).
The draft also states:
   With these two mechanisms and the procedure specified in step 4,
   recipients who publish a policy have, in effect, a means of updating
   a cached policy at arbitrary intervals

I don’t get this, because it seems to me that if a domain with a valid policy wishes to change their policy *before* the end of the expiration period, then nobody will see that new policy until *after* the expiration period because sending MTAs will cache the policy until after the expiration period, and should never invoke step 4 because they shouldn’t see a validation failure and/or reject action. This doesn’t seem consistent with “updating a cache policy at arbitrary intervals”?

"Understanding the details of step 4 is critical to understanding the behaviour of the system as a whole.”

I have to say I don’t understand step 4 at all, so maybe someone can explain it to me? :) The whole authentication system seems designed for a tiny use-case, i.e. validation failure and reject action. If this is designed to stop malicious behaviour, why only concentrate on non-validating policies, surely there are use-cases where an attacker has spoofed the recipient DNS records (cache poisoning etc.) and thus has control over both the DNS STS record and the DNS record for the HTTPS server, and thus could present a valid policy?

Neil

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 22 Mar 2016 11:24:42 +0100

Heh, thanks for the feedback.

I will try to make sure we used consistent language. In specifics, my
intended meanings:

* authentication: determining that the policy is published by the domain
owner (either because it was delivered over DNSSEC or because it was
delivered over HTTPS with a trusted cert)
* validation: on a given mail delivery attempt, determining that the MX is
the "right" MX (i.e. that its identity and certificate match what the
authenticated policy specifies)
* application: determining what to do when a policy validates or does not
validate (the latter of course being the interesting case)

"Application" is more than just "validation" for two reasons. First,
because a policy might be "report only" and thus a failure to validate does
not result in a delivery failure. Second, because of this slightly
complicated dance to get the latest policy in the case of a failure.

The central idea here is that if a policy fails to validate on a given
delivery attempt, the sender should try to get a new *authenticated* policy
to ensure it's using the most up-to-date revision. This allows recipients
to set a long expiration on the policy without chaining themselves to their
current MX records, provider, etc. So this answers your question of when
senders will see the new policy: they will refresh the policy if the old
policy is no longer valid.

An attacker who can present a valid policy (by e.g. controlling both DNS
and a valid CA-signed cert for the recipient domain) can typically do a lot
of other nasty things as well, like MITM client connections to the IMAP or
webmail server, so we consider this attack out of scope for now (though
potentially a good application of public key pinning, CT, or similar).

In the section you quote from 3.3, I think that should refer to
"authentication", not "validation." :)

Dan

On Tue, Mar 22, 2016 at 10:12 AM, Neil Cook <[email-masked]> wrote:

> 1) The language around policy authentication vs validation vs application
> is very confusing to me. The terms “authentication” and “validation” seem
> to be used in a variety of contexts with different meanings.
>
> So the draft talks about authentication, and then immediately starts
> talking about being able  to “validate” new policies. I think this should
> be “authenticate”.
>
> Back to the use of “unauthenticated” here. Even though authentication
> hasn’t really been defined yet, or least distinguished from validation.
>
> Also, it’s confusing to me that this paragraph talk about policy
> validation, but instead refers the reader to the “Policy Application”
> section, rather than the “Policy Validation” section.
>
> - “authentication” refers to the concept of “trusting” that a retrieved
> policy is the policy actually intended by the remote domain and not a
> malicious policy inserted through DNS spoofing or whatever, and should be
> used in the this context. Since STS is ‘trust-on-first-use’, this means
> that authentication is normally a no-op, except in the case of retrieving a
> new policy when a cached policy is already in operation.
> I’d like to see the section on Policy Authentication reworded so that this
> is clearer, by moving the language "When fetching a new policy when one is
> not already known…” to the start of this section, and stating that such
> policies are thus implicitly authenticated. Explicit authentication happens
> when a new policy is retrieved and authenticated according to the two
> mechanisms shown in “Policy Authentication”, based on the “a" field from
> the already cached policy.
>
> - The section “Policy Validation” actually refers to certificate
> validation, based on the “c” field in the cache policy. This seems to be
> different to policy validation to me, which should mean a well-formed and
> parseable policy. The section “Policy Validation” actually seems to me to
> just be the first step in policy “application”.
>
> 2) The logic as to when to use the “authentication” mechanism as described
> by the “a” field seems strange to me. The draft states that policies should
> be cached until the expiration time (which is implicitly the longer of the
> TTL and the “e” field). It also states that the only time the
> authentication method specified in the “a” field should be used is when the
> applied policy is invalid and the policy specifies rejection (step 4 of
> Policy Application).
> The draft also states:
> I don’t get this, because it seems to me that if a domain with a valid
> policy wishes to change their policy *before* the end of the expiration
> period, then nobody will see that new policy until *after* the expiration
> period because sending MTAs will cache the policy until after the
> expiration period, and should never invoke step 4 because they shouldn’t
> see a validation failure and/or reject action. This doesn’t seem consistent
> with “updating a cache policy at arbitrary intervals”?
>
> I have to say I don’t understand step 4 at all, so maybe someone can
> explain it to me? :) The whole authentication system seems designed for a
> tiny use-case, i.e. validation failure and reject action. If this is
> designed to stop malicious behaviour, why only concentrate on
> non-validating policies, surely there are use-cases where an attacker has
> spoofed the recipient DNS records (cache poisoning etc.) and thus has
> control over both the DNS STS record and the DNS record for the HTTPS
> server, and thus could present a valid policy?
>
> Neil
>
>
>
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Neil Cook <[email-masked]>
Date: Tue, 22 Mar 2016 11:56:43 +0100

Thanks for the clarification on step 4.

However I’m still confused by the language "Enforced: In this mode, sending MTAs SHOULD treat STS policy failures, in which the policy action is “reject”"

I may be missing something obvious, but I don’t see any way to specify a policy action of “reject” in the draft. The only thing I see is the “to” field, which I guess implicitly sets the policy action to “reject” if it is set to “true". If so, then the draft language should just refer to the “to” field being true rather than refer to a policy action of “reject”.

Also, “to: TLS-Only (plain-text, required).  If "true," the receiving MTA
      requests that messages be delivered only if they conform to the
      STS policy.  If "false," the receiving MTA requests that failure
      reports be delivered, as specified by the "rua" parameter."

Although the above doesn’t explicitly state it, I presume reports can be sent even when “to” is set to “true”? If so the draft should be explicit about this. If not, why not?

Neil

> On 22 Mar 2016, at 11:24, Daniel Margolis <[email-masked]> wrote:
> 
> I will try to make sure we used consistent language. In specifics, my intended meanings:
> 
> * authentication: determining that the policy is published by the domain owner (either because it was delivered over DNSSEC or because it was delivered over HTTPS with a trusted cert)
> * validation: on a given mail delivery attempt, determining that the MX is the "right" MX (i.e. that its identity and certificate match what the authenticated policy specifies)
> * application: determining what to do when a policy validates or does not validate (the latter of course being the interesting case)
> 
> "Application" is more than just "validation" for two reasons. First, because a policy might be "report only" and thus a failure to validate does not result in a delivery failure. Second, because of this slightly complicated dance to get the latest policy in the case of a failure.
> 
> The central idea here is that if a policy fails to validate on a given delivery attempt, the sender should try to get a new *authenticated* policy to ensure it's using the most up-to-date revision. This allows recipients to set a long expiration on the policy without chaining themselves to their current MX records, provider, etc. So this answers your question of when senders will see the new policy: they will refresh the policy if the old policy is no longer valid.
> 
> An attacker who can present a valid policy (by e.g. controlling both DNS and a valid CA-signed cert for the recipient domain) can typically do a lot of other nasty things as well, like MITM client connections to the IMAP or webmail server, so we consider this attack out of scope for now (though potentially a good application of public key pinning, CT, or similar).
> 
> In the section you quote from 3.3, I think that should refer to "authentication", not "validation." :)
> 
> Dan
> 
> On Tue, Mar 22, 2016 at 10:12 AM, Neil Cook <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>
> 
>

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 22 Mar 2016 12:46:40 +0100

Right. to=true is what we mean by "reject." We should probably clarify
this. (As you can imagine, there have been a lot of revisions to the
syntax, so, you know, my apologies for old terminology that was not updated
adequately and so forth! A fresh set of eyes really helps here.)

We should be explicit that reports can be sent even when "to" is "true." I
will add this to my to-do list. ;)

Thanks again.

On Tue, Mar 22, 2016 at 11:56 AM, Neil Cook <[email-masked]> wrote:

> However I’m still confused by the language "Enforced: In this mode,
> sending MTAs SHOULD treat STS policy failures, in which the policy action
> is “reject”"
>
> I may be missing something obvious, but I don’t see any way to specify a
> policy action of “reject” in the draft. The only thing I see is the “to”
> field, which I guess implicitly sets the policy action to “reject” if it is
> set to “true". If so, then the draft language should just refer to the “to”
> field being true rather than refer to a policy action of “reject”.
>
> Although the above doesn’t explicitly state it, I presume reports can be
> sent even when “to” is set to “true”? If so the draft should be explicit
> about this. If not, why not?
>
> Neil
>
>> I’d like to see the section on Policy Authentication reworded so that
>> this is clearer, by moving the language "When fetching a new policy when
>> one is not already known…” to the start of this section, and stating that
>> such policies are thus implicitly authenticated. Explicit authentication
>> happens when a new policy is retrieved and authenticated according to the
>> two mechanisms shown in “Policy Authentication”, based on the “a" field
>> from the already cached policy.
>>
>> 2) The logic as to when to use the “authentication” mechanism as
>> described by the “a” field seems strange to me. The draft states that
>> policies should be cached until the expiration time (which is implicitly
>> the longer of the TTL and the “e” field). It also states that the only time
>> the authentication method specified in the “a” field should be used is when
>> the applied policy is invalid and the policy specifies rejection (step 4 of
>> Policy Application).
>> The draft also states: