Re: [Uta] Comments on STS Strict Transport Security

[Neil Cook <[e-mail]>]

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