Re: [Trans] DNSSEC also needs CT

[Nico Williams <[e-mail]>]

On Mon, Jun 2, 2014 at 12:20 PM, Stephen Kent <[e-mail]> wrote:
>> On Thu, May 22, 2014 at 1:48 PM, Stephen Kent <[e-mail]> 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
--