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