Re: [Uta] Comments on STS Strict Transport Security

[Daniel Margolis <[e-mail]>]

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 <[e-mail]> wrote:

> 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
>
>
>
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>
>