On Mon, Jun 2, 2014 at 12:20 PM, Stephen Kent <[email protected]> wrote: >> On Thu, May 22, 2014 at 1:48 PM, Stephen Kent <[email protected]> wrote: >> I take it you concede that lack of name constraints isn't the only >> reason to want CT. > > agreed. > >> I'll concede that CT for DNSSEC might not be a good idea. Did I ever >> say it is? I started the discussion with an inference: CT is for >> PKIs, DNSSEC is a PKI, therefore CT fits DNSSEC, discuss. > > I thought you did. I think CT for the Web PKI needs is missing an arch > doc, and absent that doc it's now clear how good CT is for that case. > This I consider it premature to suggest CT for DNSSEC si an obvious next > step, > as some have suggested.
I posted today providing my take as to one aspect of the CT architecture: http://www.ietf.org/mail-archive/web/trans/current/msg00315.html As I've understood it CT is partly about CA reputation. As such CA failures [to not MITM] should be handled asynchronously. I think this is an important consideration because it speaks to when the client (and domain owners, and auditors) should do the hard work of checking the CT logs. > The experimental RFC does not provide a comprehensive problem statement, > a clear description of all of the elements of a proposed solution, an > explicit discussion of all of the assumptions that appear to underlie the > design, i.e., what must happen for CT achieve its goals, and an > analysis of what happens if some (implicit) assumptions are not satisfied. > > I'm going to develop what I see as the missing arch doc, to elicit feedback > from > the WG and the RFC authors. The WG can decide whether this is necessary, but > I > believe the exercise will, in any case, be useful. I agree that CT is missing this. That doesn't (and shouldn't) keep one from asking if CT is applicable to DNSSEC, and if so what that might look like. Hand-waving a bit, if a) CT is a keep-CAs-honest mechanism in addition to enabling domain owners to find out about erroneous certificate issuance for their domains, b) CT applies to PKI in general (not just PKI as in RFC5280), and c) DNSSEC is a PKI, then d) it's a fair inference that CT ought to apply to DNSSEC. The three conditions seem to be true. It's not a fair inference that CT ought to be applied to DNSSEC, of course. Even if CT can be applied to DNSSEC and even if it is desirable to do so for many, there are still possibly strong arguments to make against it. For example, domain owners might object to yet another "tax" on them: there's domain registrar fees, CA fees, and now log fees paid indirectly. And then auditing costs (probably outsourced). I'm sympathetic to such an argument. Add to that a proper the benefit side of a proper cost/benefit analysis... For the TLS PKI case the benefit is: - mitigates the lack of name constraints - detects MITMing CAs For DNSSEC the only benefit is the MITM detection one. Assuming that detections will be of a) errors by registrars, and b) political/legal actions that we can't do much more about than detect... is this enough value to justify the additional costs? This is a value judgement to be made by the market. Nico -- _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
