On 5 March 2013 20:27, Viktor Dukhovni <[email protected]> wrote: > Is this > essentially the actual rationale, or a retroactively plausible one?
Not retroactive, I am really concerned about situations where another security policy (DPF, or organisationally local) trim what is 'acceptable' for DANE to 0&1. Furthermore, I'll say specifically that I have argued because my interpretation has been while you obviously are interested in the mailserver side of things, that the argument applied to all DANE checks... > 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? I will be the first to admit I'm not an expert in mail systems, and will also add that you definitely know more about them than me. In this case, from what you're describing and from what I know (which is limited) - it makes sense. I obviously don't have to give you permission in any case - I much prefer to say "Now that we're talking specifically about mailservers, I don't know enough about it to give an informed opinion in this matter." > Is the model you present in fact expected to gain some traction? > Do we expect browsers to consult DPF? DPF is fledgling. I *hope* DPF will be created and I *hope* browsers will consult it. I am also friends with the guy who's pushing DPF and another venture (.secure). They integrate well together, and while I suspect you and a lot of folks won't like .secure (you can ping me off list if you'd like to debate the merits) - I think DPF is cool, and I am for it. > 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? I have *no idea*. I couldn't even conjecture intelligently. Sorry. When that stage is reached, we'd love to get input on it. >> 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. That's all I was arguing. Whoo-hoo! Common ground! > 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, ... I am all for opportunistic encryption of SMTP, and I think any DANE entry (1 or 3) goes a very, very long way towards securing it.[0] Thank you for working on it. -tom [0] http://ritter.vg/blog-no_email_security.html _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
