Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Benjamin Kaduk <[e-mail]>]

On Tue, Apr 10, 2018 at 06:53:21PM -0500, Nico Williams wrote:
> On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote:
> 
> Assertion of facts not in evidence.  We're here because there is a

That argument cuts in many directions, of course.

> question as to consensus (and/or process).  We need to address that.

I don't really agree with that characterization.  To state my understanding,
as responsible AD, of the status of this document: this document is in the
RFC Editor's queue being processed.  The WG is being asked if the late-breaking
issues, raised after consensus was determined, are severe enough to merit
clawing the document back from the RFC Editor to make further changes.
This is, in effect, asking the WG to overturn a previous consensus, which
requires a stronger bar than obtaining an initial consensus from vacuum.

[takes AD hat off]

> I'll be blunt: I do not care about how long it's taken and neither
> should anyone else (besides, it will take longer on the RFC-Editor queue
> anyways; as an RFC author myself, I know this all too well).  I care
> about the quality of the end result, and so should you, and so should
> the WG, IETF, and IESG.
> 
> There is bug in the spec.

This appears to be an assertion of fact without (immediately local) supporting
evidence.  :)

You believe there is a bug in the details of the spec, sure, and I suspect that
this follows naturally from your related belief that there is a bug in the
target scope of the spec.  If we don't agree on what the target scope of the
document should be, then it's unsurprising that we will fail to agree on the
protocol details.

> > Another important facet of this debate that so far has not surfaced
> > on recent mailing list discussions is an assessment of the relative
> > benefits of webpki versus dane, and the recognition that there are
> > strongly divergent views on this topic. [...]
> 
> This is not the subject matter of this LC.

You say this, but to me it seems a relevant factor when determining the
target scope for the spec.  That is, if some individual believes that
DANE is amazing and the Web PKI is crap, then that individual is likely
to want to see DANE take over for the Web PKI in authenticating Web TLS
connections, and as such see that as a vital motivating factor for
any work involving bundling DANE records in the TLS handshake.  Someone
who is less keen on DANE over the Web PKI may not share that enthusiasm
or confidence for focusing the scope on that use case.

> > Viktor has asserted that no-one will be motivated to deploy DANE
> > without protection against PKIX downgrade, because there is no
> > compelling enough additional gain of security. He may be right or
> > wrong, but I've already heard several web folks disagree with him.
> > [...]
> 
> You're not addressing the glaring downgrade attack.

I think this argument would be more compelling if phrased differently.
(N.B. that I don't know *how* compelling it would be, and whether that
would be *sufficiently* compelling to effect change; I just think it could be
more compelling than this phrasing makes it.)

In particular, the question of scope arises again.  My impression is
that at least some proponents of the document as-is want to treat the
scope as something like "we allow for the transport of DNSSEC records over
channels where they were not previously available in a useful fashion" (whether
due to actual blocking or latency considerations), in particular, leaving
the question of how those records are used at the endpoing as out of scope.
You want to bring in the downgrade attack as being a significant risk/drawback
for several, not necessarily all, potential use cases for consumers of the
transport.  The question in this framing then becomes a balance between the
potential/expected scale and importance of the affected use cases and the
unaffected use cases.  This ties in nicely to your new argument about the cost/risk
tradeoff being considered.  To you, the "affected use cases" are potentially
huge (e.g., "all web TLS connections"), and even if someone thinks that the
chance of that happening is somewhat small, the risk of it happening but being
broken by the downgrade attack is magnified by the scale into something that
merits consideration now.  This is to be balanced against
more-certain/more-expected use cases that might be perceived as more "fringe"
and probably as smaller in scale than "all web connections".

I don't expect to get unanimous agreement about the potential scale and likelihood
of various perceived use cases, but would hope that people will consider the
tradeoff to be made, as you have framed it.

-Ben