On Tue, Mar 05, 2013 at 06:40:36PM -0500, Tom Ritter wrote:
> > Corollary. Any justification for name checks must assume the attacker
> > is not able to generate fraudulent TLSA records for the target
> > domain. Therefore, in any attack thwarted by name checks the client
> > acts on authentic (possibly stale, but not yet expired) TLSA records
> > for the target domain.
>
> I do not assume that, I assume the attacker CAN generate fraudulent
> TLSA records, but is constrained by a higher-level Domain Policy that
> disallows usages 2 & 3. He can repoint the A record, he can make a
> new TLSA record, and he can create a Usage 2 & 3 but those won't be
> accepted.
If that's a real concern, and what we're getting from "1" is
verification of the endpoint in the face of a compromised DNSSEC,
when we can somehow securely obtain policy records that prohibit
2/3, then OK, this is a rationale for name checks in 1. Is this
essentially the actual rationale, or a retroactively plausible one?
We should consider what the above implies in the context of dane-srv
and dane-smtp. Given that the DNSSEC controlling attacker can
freely change the name that is going to be verified, that is the
name of the MX host or SRV host:
example.secure. IN MX 0 example.evil.
example.evil. IN TLSA 1 1 1 <public key digest>
the name the client is going to look for in the CA-issued certificate
(example.evil) is now under the control of the attacker. Can we
statically optimize out name checks in this case?
> The attacker is not able to compromise a CA. With name checking the
> attack is thwarted, without it is not. Q.E.D. (Or something.)
With say, HTTP where the user entered the https://example.secure/
URL directly and something like the DPF policy you describe exists,
and ideally also constrains or specifies the trust anchors for the
gTLD.
> > I don't see any reason for DANE to prevent the domain owner from
> > binding the still valid mail.example.com certificate to the new
> > mx.example.com (split-off host) via a 1/1/1 TLSA record.
>
> My rational basis is that a certificate for mail.example.com is not a
> valid, CA signed certificate for mx.example.com. It may be a valid
> CERTIFICATE for the domain, but it is not a valid CA-signed
> certificate.
If we believe that the purpose of "1" is to thwart DNSSEC compromise
when the client is armed with additional policy that rejects 2/3
DANE certificate usages for the destination domain, OK, in that case
name checks for "1" make some sense, provided there are no pesky MX
or SRV records.
> To claim it is would be to state something untrue, just
> as if I were to say that my certificate for ritter.vg is a valid CA
> signed certificate for https://fuckyoulookatthiskitten.com[0].
In my threat model, game over when DNSSEC is compromised, so the
certificate was signed by you at some point, and if that's the CA
certificate you want to use at https://FULATK.COM you're free to
do so. You paid the cert and get the benefits of the CA's certificate
revocation services. It should not be DANE's job to protect the
CA's revenue stream by ensuring that a certificate for server X is
never deployed in server Y.
Is the model you present in fact expected to gain some traction?
Do we expect browsers to consult DPF?
How will DPF interact with SRV and MX records? Will ".secure" gTLD
domains be constrained to never generate SRV or MX records that
point outside the sandbox?
> > Is it reasonable to continue to advocate my interpretation based
> > on logic and consideration of security models? Or is it the group's
> > view that structural similarity to existing legacy CA PKI practices
> > trumps logical analysis?
>
> We disagree, but I resent being told my arguments are not logical.
> Your arguments make excellent sense, I just think you're dismissing
> something I care about.
You just gave a logical argument. Thanks. I don't recall seeing
anything as specific upthread. If I missed it, apologies to the
poster.
> Although DANE mechanisms 2 & 3 allow bypassing CA checks, an alternate
> security policy may disallow usages 2 & 3 and require 0 or 1.
> Eliminating name checking for usage 1 nullifies the point of usage 1,
> because it is trivial to get a valid CA-signed cert for *some* domain
> - it is equivalent to usage 3 at that point. I see no reason to
> require name checking for usage 3.
If this is protecting against DNSEC subversion in the presence of
policy that partly overrides DANE, I agree. If this is protecting
against compromised server private keys, ... then the value of the
CA is just revocation support, in which case the name check is
redundant and can be performed statically by the domain owner.
So for Postfix (MTA to MTA SMTP), since we don't yet have DPF (and
may not in any case benefit from it given MX record indirection),
and don't have or plan to offer revocation checks or OCSP, the plan
is to simply ignore the CA bit and to treat each of 0/2 and 1/3 as
equivalent sources of either a trust anchor or an end-point
certificate. This will substantially improve the security of email
delivery without substantially increasing the risk of email disruption
because the receiving domain's issuing CA is not locally trusted,
or some name check failed when the EE cert is available, ...
If it were up to me, I'd go further and in dane-smtp recommend that
administrators publish "TLSA 3 1 1" records (as in the case of
netlabs.nl) as the most likely to improve security without causing
delays from some senders due to verification glitches. In some
cases the "3 1 1" cert may in fact be CA-issued, and some senders
will validate them via legacy PKI policy rather than DANE.
Since I'm sensing little support from this group for dropping name
checks in the "TLSA 1 1 1" use-case, email administrators will not
be able to leverage "TLSA 1 1 1" for revocation services, but this
is not a big loss, since few if any MTAs do revocation checks or
OSCP (most don't even offer correctly implemented name checks).
Thanks for your attention.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
