[Uta] Comments on STS Strict Transport Security

[Neil Cook <[e-mail]>]

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