On Tue, Mar 05, 2013 at 10:40:54PM -0500, Tom Ritter wrote: > > 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. > > [...] > > > 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!
Yes, some common ground, which is good. Though I must admit that with the logical bases for our positions established, and a judgement call required to assess the pros/cons of the implied trade-offs, I see the DPF rationale as a somewhat nebulous corner-case that could apply to a small set of domains that migrate into a walled-garden gTLD. For the bulk of .com and .net domains, no protections against DNSSEC compromise will be available in the form of constraints on DANE 2/3 from a parent domain. If this is the strongest reason to impose a MUST name check on clients, and as a result one can no longer extend the utility of an existing CA certificate when ones needs change in early in the certificate's lifetime, where I at the WG meeting, I'd try to hold my ground if there was some hope of getting support. I'm not sensing much support here for my "static check" argument, so I guess I'm done. Thanks letting me air my views, I hope the WG will use whatever useful insigths I may have provided for some good. > 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. Thanks, I hope to have working code by June and a Postfix snapshot release some time after Wietse's had a chance to adopt it. As for SMTP and SRV records, given the observations about unavoidable reliance on DNSSEC security in choosing which names to check against the certificate, I still contend that in protocols that choose their peer indirectly, there is no reason to check names in 1/3, and so https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-7.3 should be revised to no only require name checks for 0/2 and to suggest that clients accept the implied name binding via DNSSEC TLSA for 1/3 without second-guessing it with certificate content checks. The fallback position which is less controversial is to at least exempt 3. Thanks again to Tony Finch for bringing the drafts to my attention, I hope he is not sorry he did so (i.e. feel free to blame him for my rants :-). If Tony or anyone else wishes to discuss the specific use case of SMTP+DANE or more generally SRV+DANE, I won't object to off-list email. I am happy to comment on proposed draft language, since I have a stake in the outcome. -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
