Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Martin Thomson <[e-mail]>]

On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey <[e-mail]> wrote:
> 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)?

I don't think that pinning is a good idea.  We've experience that
suggests that it's more of a footgun than a useful mechanism.  That
isn't to say that there isn't a domain where it makes sense.

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?

No.  We need fewer extension points, not more.  It's already hard
enough to ensure that the ones we have remain usable.  ekr's
suggestion to reduce the number of *types* of extension point would be
a compromise position here, but I don't think that's the best outcome.

If we mess this one up, we can make another extension, or use another
extension to fix it if that makes more sense.  Yes, that's messy, but
the above assessment supports the notion that we won't need v2.

> 3.  Do you support the proof of denial of existence text in the revision?

Allowing denial of existence in the extension is fine.  It somewhat
depends on having a prior expectation of having some form of DNSSEC
record there, which hits all the concerns above, so I'm not sure what
concrete value it provides.  I see no harm in allowing it though.

> 4.  Do you support the new and improved security considerations?

I have to confess, I had a lot of trouble reading the new text.  It's
good, and contains much of what is needed, but it's very wordy.  I
think another iteration or two would help.

If I can summarize:

We consider the case where DANE is considered stronger than PKIX or a
valuable addition to PKIX, because this extension is only of use in
those circumstances.  If an attacker can compromise PKIX, then they
can just not send the DANE extension.  With prior knowledge, a relying
party might know to expect DANE, but that isn't always possible,
especially when this mechanism is introduced into a PKIX-only
ecosystem.  A relying party can't assume that use of DANE with one
connection implies that other connections to the same peer will also
be secured with DANE.

There's a lot of extra words around that message, and I fear that the
message will be lost as a result.