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

[Viktor Dukhovni <[e-mail]>]

> On Oct 16, 2018, at 6:16 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> 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.

Thanks, that summary looks quite accurate.

> 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).

To be fair, the present delays date back to just March/April.  Until
that time the draft was blocking waiting for TLS 1.3 to be finished
first.  So it has only been a few months.

> 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".

At this point, I think that would be a mistake. The draft still needs
much work.  Though pinning has been a blocker, it has many other smaller
defects that have to be addressed, now that it is back for revision.

The draft fails to specify correct semantics for SNI, and leaves out
the port number from the client extension, but it is needed.

The draft fails to explain the server's responsibility to decrement
RRset TTLs if the server is providing previous cached data.

The draft fails to describe how virtual hosting should be handled.
The RRset ordering is unnecessary, and complicates the exposition.

Bottom line, there isn't a document that can (or at least should)
land back in the IESG queue with minimal changes.  It needs a bunch
of changes, and so we should really also resolve the pinning issue,
it is NOT that difficult.  It has been a series of misperceptions
all along.

> 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.

The proposed extension lifetime field is all it takes, there is no
feasibility or need for a testing mode (because there's no way to
authenticate such a mode, or else we again lose downgrade protection,
and the analogy with HTTP STS is imperfect, and does not carry over).

There's also no need for "reporting URIs", failure signaling is
much better done in-band, via a suitable TLS alert.

All that's left to iron out is the maximum duration for the pin
lifetime, and whether we need to gradually scale it up as a function
of RFC lifetime, giving sites more protection from hijack DoS (if
that's really considered important enough to complicate the design).

-- 
	Viktor.