Re: [Trans] DNSSEC also needs CT

[Phillip Hallam-Baker <[e-mail]>]

On Thu, May 22, 2014 at 2:12 PM, Stephen Kent <[e-mail]> wrote:
> PHB,
>
>> On Thu, May 22, 2014 at 1:21 PM, Stephen Kent<[e-mail]>  wrote:
>>
>>> PKIX, per se, does not have the trust problems that seem to motivate
>>> CT; the Web PKI does. That PKI has always had a serious problem because
>>> any TA can issue a cert for any Subject, irrespective of the Subject
>>> name.
>>> because DNSSEC intrinsically incorporate the equivalent of PKIX Name
>>> Constraints, it does not suffer from that specific problem. That's not to
>>> say that mis-issuance is not possible in DNSSEC, but rather that its
>>> effects are more limited.
>>
>> On the contrary, it has a rather more severe problem in that the names
>> can be reassigned by the upstream zone.
>
> is that really more "serve" than an ability to issue a credential
> for ANY name, as in the Web PKI?

At least that is a temporary condition.

Any trust infrastructure that ultimately rests on the common sense of
the US Congress and President is doomed in the long run. And there
isn't a better political solution on offer either.

Finding a technical mechanism that reduces the dependence on the
political/policy dimension makes it much easier to address that layer.
If it is possible it is always far easier to eliminate a single point
of failure than to work out policy level controls to prevent abuse.


>> Depending on your application, this might not matter. But if you want
>> to try hooking an enterprise PKI off a DNSSEC system then this matters
>> a great deal. I am sure that Google would not want to find that
>> VeriSign could direct their infrastructure to change configuration by
>> issuing a fraudulent DNSSEC signed zone.
>
> A large, competent enterprise (if that's not an oxymoron) can run its own
> PKI w/o using DNSSEC. This seems like a red herring.

If they already have a PKI then they are probably not interested in
DNSSEC at all because that problem is already solved and DNSSEC is the
red herring.

Unless that is there is an interesting way to use DNSSEC as an
extension of the enterprise PKI. In which case it is critical that the
DNSSEC PKI does not introduce a new point of failure.


>> Don't think of CT in this case being something to solve a problem
>> faced by DNSSEC users, instead think of it as something that enables
>> use for problems where it is otherwise unsuited.
>
> That's a very confusing last phrase.

DNSSEC is still raw technology. Saying that it does not need feature X
before the full set of potential applications is premature. We don't
know what it is useful for yet. That is what we should find out.


>> The other major advantage is that it provides a tool to avoid some of
>> the cryptographic lock in problems that are causing certain countries
>> to cause issues in ICANN. You don't have to agree with their analysis
>> to find value in addressing the concerns.
>
> I understand their concerns. But the lack of a well-articulated architecture
> for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether
> this is a good idea.

I find that looking at an additional field of application is often a
very good way to improve an underspecified architecture.

Trans is rather too closely designed to solve one problem and it is
not even clear that it does that particularly well. There is a lot of
fuzziness in the process by which a relying party decides that a
particular value is the true Merkle tree apex of a particular log.