On 5 March 2013 13:29, Viktor Dukhovni <[email protected]> wrote: > Note 1: Such an attacker can subvert all other DNSSEC validated > policy, so if there is anything in DNS published by the compromised > domain that asserts that the domain never issues valid 2/3 TLSA > records and always uses 0/1, this too can be subverted by the > attacker, so it is not clear how say DPF would mattter.
DPF was an example for me, not a lynchpin of my argument, but I'll say that a component of DPF was allowing a policy on a root tld (e.g. .secure) like "only allow Usages 0 and 1, and require TLS 1.1 or above" and a domain in .secure (whether a legitimate or a hacked one) could not override the policy. > Note 2: How many potentially overlapping policy sources do we expect > a DANE-aware client to consult? MUST a DANE-aware MTA also implement > the future DPF, and then later yet another policy source? Surely > complying with the semantics of TLSA records should not be a game > of RFC whack-a-mole! Must I hold-off implementing DANE in Postfix > until DPF is published, what else must I wait for? Of course not. Any security mechanism: DPF, DANE, or TLS is an optional thing for anyone to implement. RFC whack-a-mole is a reality we must live with. TLS, TLS1.1, TLS1.2, AES-GCM, AES-CCM, DANE, HSTS, HPKP, so on and soforth. Caring about security, I'd like everyone to implement all the relevant mechanisms as soon as possible, but it's always been the prerogative for implementers to ignore or alter standards in their implementations. The goal is for you to see value in a standard and want to implement it. If you don't see value, we've failed as standards-creators or as evangelists. DPF could complement DANE by removing components of it that people feel nervous about, just as it could complement TLS by removing components people feel nervous about (requiring strict revocation checking, requiring TLS >1.1, etc). But I would never imply that it is a MUST-implement for a DANE (or anything-else) compliant implementation. I don't think formal proofs work well in things aside from math, because we'll wind up arguing over what is a valid assumption and what is not. > 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. 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.) > 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. > > Gut feeling is sometimes just indigestion. :-) What rational basis > do we have to exclude this and other related use-cases? 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. 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]. There are a multitude of ways to allow those machines to interoperate with the businesses that violate standards or best practice - such as disabling certificate validation entirely. I think this is another example. [0] pardon the expletive, I just wanted to use a domain I actually control On 2 March 2013 13:20, Viktor Dukhovni <[email protected]> wrote: > In both usage 3 and usage 1 the TLSA RR specify the end-entity > (leaf) certificate deployed on the server. Once a particular > certificate is explicitly bound to the server via a TLSA RR, there > is no point in comparing the server name with the content of the > certificate, we already have a binding and name checks We have ONE binding (DNSSEC) we do not have ALL the bindings for option 1: the valid Certificate Authority check. Checking the name is a required part of being "valid according to CAs rules". > One simple design rule I try to adhere to is: "don't fail when > success is an option". I try to adhere to the opposite when regarding network protocols: assume malice and untrustworthiness until proven otherwise. On 5 March 2013 15:00, Viktor Dukhovni <[email protected]> wrote: > 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. > At the very least, I hope updated dane-srv and dane-smtp drafts > and final RFCs will not mandate name checks for "TLSA 3 x y", so > this thread won't be entirely hot air. I agree, they should not. I'll try to state my point succinctly, and leave it at that... 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. -tom _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
