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