Victor,
We appreciate your time and effort reviewing our draft.Lately we had some
discussions related to policy cache and refresh in GitHub. One proposal was not
to depend on DNS beyond initial discovery. We have some flow diagrams (#72) in
the below links that provide some insights to what I'm referring to.
https://github.com/mrisher/smtp-sts/issues/72https://github.com/mrisher/smtp-sts/issues/62
thanks,-binu
From: Viktor Dukhovni <[email protected]>
To: [email protected]
Sent: Thursday, 11 August 2016 10:46 AM
Subject: Re: [Uta] review of mta-sts-01
On Thu, Aug 11, 2016 at 05:59:08PM +0200, Daniel Margolis wrote:
> > Should this still apply when the names are DNSSEC validated? Or
> > should clients that obtain DNSSEC "secure" MX RRsets (or denial
> > of existence) skip the MX constraints in the STS policy, whose
> > primary purpose is to harden STS against DNS reply forgery?
> >
>
> When would you want to do this but use STS instead of TLSA for the actual
> cert validation? Conceivably if your MX domain isn't your mail To domain
> and only the latter supports DNSSEC, I suppose. So I can see an argument
> for it.
The domain owner may have DNSSEC-validated MX RRs pointing to an
MX provider whose zone is unsigned, or in any case one that does
not publish TLSA records. The provider's MX hosts may have usable
PKIX certs.
> On the other hand, wouldn't a lot of senders have a stub resolver that
> doesn't know the validation status for DNSSEC (as the recursive resolver is
> the validating resolver)? In that case, how would this work? I guess if
> this is a MAY or a SHOULD that's still OK...
The question applies to senders (really SMTP clients) whose stub
resolver is either validating or security-aware (via the AD bit of
a trusted iterator). If the MX RRset is adequately protected,
should the "mx" attribute from the policy be strictly enforced?
(One could just log a warning and/or generate a report, but deliver
anyway, based on the validated MX RRset).
> > Consequently, a better design is to publish multiple matching "id" values
> > in the HTTPS policy which can list a few recently published DNS "id"
> > values, in particular at least the current one published in the
> > authoritative DNS zone, and typically also the previous that may still be
> > present in some DNS caches.
> >
> > The recommended update process woud then be to update the HTTPS policy
> > "<id1>,<id2>" -> "<id2>,<id3>" and then update the DNS TXT record from
> > "<id2>" -> "<id3>". Clients that still have "<id2>" in their cached DNS
> > record would then accept the new policy as fresh since it still matches
> > "<id2>".
>
> I notice that you and Stephen both caught this issue. We had been
> discussing it recently among the authors as well. Stephen's suggestion, in
> comparison:
>
> > Why not fetch ".well-known/mta-sts/<id>" where <id> is
> > what I got from the TXT RR?
This has a fundamental weakness. The "id" in the DNS TXT record
is untrusted data. Attackers can redirect the client to a stale
id, or to an ID that returns "404". Since IMHO "404" should signal
policy revocation, (otherwise there's no timely way to revoke a
policy) this is a problem.
> Any concerns (Viktor, or anyone else) with Stephen's suggestion? It seems
> like the smallest possible fix for this issue, and a very coherent one.
> Once the TXT update is out for >DNS TTL, of course, admins can remove the
> old JSON policy files to avoid a DNS MITM serving an old policy (for
> whatever gain).
See above.
> > > To consider the policy as valid, the policy_id field in the policy MUST
> > > match the id field in the DNS TXT record under _mta_sts.
> >
> > s/_mta_sts/_mta-sts/ Also update for multi-valued "id" in the policy.
> > Finally, no "MUST"s here, if the HTTPS id does not match the DNS, the
> > policy is still valid, but now the client will check for updates as
> > frequently as the client implementation allows since the DNS always seems
> > to indicate a requisite refresh. DNS is not authoritative here, and a
> > freshly retrieved and authenticated HTTPS policy holds regardless of any
> > "id" values in DNS.
> >
>
> I think you missed the point of the directive (which is fairly easy to do,
> because on rereading this sentence is worded completely incorrectly!).
More than "easy to do", the sentence simply does not say anything along the
lines of what you suggest below.
> My point here was actually that a policy *once fetched MUST be applied to
> at least one message to one MX* before it is cached as valid. The reasoning
> here is to prevent caching and perma-DoS'ing someone who just serves up a
> totally broken policy. So we want to not only require the HTTPS fetch to
> succeed and the policy to fetch, but the policy to actually *work*. This is
> a higher burden on implementors (who must now cache the "success bit" per
> policy), but it seems worth it, I think. Thoughts?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
