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

[Tim Wicinski <[e-mail]>]

My question would be "what will the HTTP community do if they find this
whole process unwieldy and long"?
Answer  They will come up with a solution that does nothing with DANE.

is that an excuse to do something less than perfect for the better good, or
do we live in the world of smug satisfaction of being perfect?

Sorry, from reading this discussion that's my simple minded view.

Tim


On Tue, Nov 6, 2018 at 11:07 PM Benjamin Kaduk <[e-mail]> wrote:

> 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.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>