Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Benjamin Kaduk <[e-mail]>]

On Mon, Nov 05, 2018 at 09:00:29AM -0500, Viktor Dukhovni wrote:
> > On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk <[e-mail]> wrote:
> > 
> > Once we start talking about pinning of any sort, we move from this
> > extension just being "transport some DNS records" into conveying some
> > sort of additional semantics.
> 
> Transporting some bits *always* carries additional semantics, otherwise

Of course!  But if we don't precisely specify those semantics, we expect
to get DISCUSS positions at IESG evaluation (as "not interoperably
implementable").

> why carry the bits.  For example, already in -07 there is clear text
> specifying that the transported records can be cached for their DNS TTL,
> and that once delivered DANE records should not be ignored on failure.
[...]
> That rather looks like semantics to me, much more than transport some bits.

Is it new semantics for this TLS extension, or just the semantics of "you
have a DANE record; this is what you do with it"?

> > It seems that we have not really had a structured discussion about what
> > semantics and information flows we might or might not want to convey in
> > this extension (in one or both directions!), and I'm reluctant to consider
> > adding such semantics without such a discussion.
> 
> I really don't think that at this juncture it is productive to wipe the
> slate clean and consider all possible proposals, even ones that nobody
> has put forward as yet.  Why would we want to do that.  There is clearly

When we do work at the IETF, proposals are not presented as a "take it
or leave it" option -- usually, they are starting points for further
analysis and discussion: "is this optimal?", "is it better if we tweak
it in this way?", etc.  I am presenting a framework in which to try to
answer these questions, starting from the proposal on the table.

In other words, I am pointing out that there is a process step that
needs to happen before this draft can be published.  This need not start
from a "clean slate", but we do need to be confident that we understand
what we are publishing.

> just one primary contentious issue to resolve, and I rather think your
> train of thought is a distraction from the issue at hand.

The IETF process requires reaching a consensus understanding of the
technical facts of an issue.  My train of thought is an effort to seek
that understanding in the area of downgrade countermeasures, since in my
judgement it has not been achieved by the previous WG discussions.  If
we have no WG consensus understanding of pinning, we cannot publish
pinning.  That could mean not publishing at all, or publishing something
that lacks pinning.  The latter would of course not preclude other work on
pinning by interested parties.

> > If we accept the premise that the intention of DANE as relevant in this
> > space is to allow the server to convey to the client the server's
> > preferences for how the client should authenticate the server, we may also
> > want to consider the case where a server operator wants to eventually get
> > to a DANE-only state where it can ignore the web PKI.
> 
> Nobody is looking for this.  There's no point.  WebPKI certificates are
> free (and worth every penny).  DANE adoption is far too light to even
> begin to contemplate abandoning WebPKI, and we're probably two decades
> away from being able to do that, by which point the quantum computer
> apocalypse may have made many of the current designs moot.

That's good input; thanks.

> > (There may not be
> > many or any servers that actually end up wanting to do this, but it's not
> > unreasonable to consider the possibility.)
> 
> It seems unreasonable to me, because no such signalling was for example
> proposed for raw public keys or various PSK methods, etc.  And of course
> the server operator can log the use of the extension and draw conclusions
> about client support based on that, and the overall technology landscape.
> There's no need to include this in the discussion.

The chairs should feel free to shut this down if needed.
But I'll note that the server's logging is not going to get any signal
from clients that can get DANE records via their normal resolver, with
the current proposal.

> > Similarly, the server may want to indicate things like:
> > 
> > (a) the server wants to be authenticated via DANE (yes, this is just the
> >    contents of the DNS)
> 
> And any client with a decent network environment can just query the
> DNS directly, and never use the extension and have the record hot
> in the local cache.  So there's no need for anything too complicated
> here.  We just need to provide as much of the downgrade-resistance
> that DNSSEC gives automatically, also to clients that for some time

I think I'm confused about what you mean by "the downgrade-resistance
that DNSSEC gives automatically".

> will be able to do DNSSEC.
> 
> > I deliberately am not trying to come to a conclusion in this message, as I
> > am not confident that I have even come up with all the potential semantics
> > worth thinking about, and I think that any motion in this space should only
> > be taken with WG consensus.
> 
> I think at this point hypothetical semantics is not a helpful direction.

I'm sorry you feel that way.  We've seen a few participants raise a
specific pinning proposal but they seem to have squelched discussion of
any other pinning options.  It seems that in any case the semantics are
hypothetical until we have a consensus and/or deployment experience.

> If you have a concrete proposal, that has merit in addition to or in
> place of what has been proposed, please explain.  If there are problems
> or lack of clarity with what has been proposed, please explain.

I have made my proposals to the list.  The WG as a whole does not have
consensus on a conclusion or the relative merits of the concrete
proposals that have been made to the list.

> I very much fear that the only possible outcome of sky's-the-limit
> brainstorming is paralysis.  Please try and focus on actual proposals.

My original mail, trimmed in your response, did list actual proposals.
Some of them are probably easy to find flaws in, which is the sort of
response I was asking for.  Having a written record of what has been
proposed and how the various proposals compare on a technical basis is
very helpful when judging consensus.

> > I would love to hear others' thoughts on what I am missing from the above
> > lists, reasoning for/against including protocol elements to indicate
> > the listed semantics, and whether/which existing protocol elements already
> > convey which of the enumerated semantics.
> 
> The proposal on the table is to a minimal form of time-limited commitment
> to the extension by mutual agreement between client and server, to address
> downgrade attacks via extension stripping by attackers with unauthorised
> WebPKI credentials.  This is need because while DNS lookups either deliver
> the relevant DNSSEC data or clearly fail, the extension is optional and
> failure to deliver it is a-priori not in any way anomalous.
> 
> We're just trying to address that gap.  If you can make a strong case
> for addressing some additional gaps, or addressing this gap in a better
> way, please do.  Once again, I'm very concerned that the direction you're
> setting out on is counter-productive.

I, on the other hand, am very concerned that you are pushing for the WG
to publish a solution without proper discussion of its merits and
potential alternatives.  I am trying to help you frame such a discussion
and come to a consensus conclusion following IETF process, and you are
avoiding a technical discussion.  Continuing down your path is likely to
either cause the document to die or to revert to the previous consensus
"HTTPS" use case, leaving any particular pinning policy to be determined
outside this TLS extension, whether at the application protocol layer or
in the implementation.

If you believe that I, acting as Area Director, am attempting to abuse
process to stymie consensus work, you have various appeal and recall
options available.  I'm happy to chat further with you about those
options if you want.