Re: [Uta] Comments on STS Strict Transport Security

[Daniel Margolis <[e-mail]>]

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

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