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