Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Daniel Kahn Gillmor <[e-mail]>]

Hi all--

I'm disappointed in how long this WG is taking to get
draft-ietf-tls-dnssec-chain-extension out the door.

I agree with both Tom and Viktor that the current draft seems to be
misaligned between the goals and the stated scope.

I wanted the draft to be done by now because i think it will be useful
in "greenfield" scenarios -- ones where the use case itself can mandate
the extension without negotiation, but i understand Viktor's point that
without any sort of negotiated pinning mechanism, the draft is probably
not useful for non-greenfield scenarios (without pinning the existence
of the extension, it cannot reduce the attack surface represented by the
CAs, and instead only represents an additional vector of attack).

I can understand why people want to be able to make this useful for
non-greenfield scenarios, but it appears that we're hung up on the
pinning details.  I actually don't think that extension pinning needs to
be particularly hard, and i don't think it's as dangerous as HPKP's
pinning, but i won't go too far into the weeds here.  Just a quick
summary of my understanding:

 * The existence of a pin only requires that the service operator
   maintain the ability to respond to this extension in the future -- it
   doesn't require specific keys, or even the use of DANE itself.  It is
   not nearly as large a risk as HPKP's pins were.

 * Pinning fears are based on two scenarios: (a) footgun, where the
   service operator makes a mistake, or (b) a malicious pin is set by an
   adversary who has owned your domain.  (a) is overwhelmingly more
   common, and is what we should focus on.  In the (a) scenario, the
   admin has already deployed the extension, so there is no risk.  The
   (b) scenario only matters if a service cannot deploy the extension as
   intended, which is more of a chicken/egg problem of deployment and
   implementation.  I don't think that's a huge risk but if we really
   want to try to cover it, i think there are ways that we could
   minimize it as well.

That said, it sounds like negotiating the details of how to do this
pinning is the main blocker, and i'm sick of this proposal being blocked
(because i want it for "greenfield" implementations last year).

So one way forward would be to complete this extension without the
pinning (explicitly acknowledging that it will not be useful for
non-greenfield implementations on its own) and get it out the door.
Then we can subsequently create a new extension that is only a
"how-to-pin-dnssec-chain-extension".

This is an approach that would expose at the protocol layer the ugly
truth about how hard it is to get something through the IETF process,
but if it helps to break the impasse, i'd be all for it.  I'm willing to
provide text for why this is only useful for greenfield implementations,
if asked.

Alternately, if people could agree on a simple and clear pinning scheme
that we could get out the door all in one piece, i'd be happy with that
too.

I will be sad if we manage to not get anything at all completed for
another year.

   --dkg, tired of waiting