> On Apr 10, 2018, at 8:17 PM, Melinda Shore <melinda.sh...@nomountain.net> > wrote: > > There's an unfortunate number of IETF protocols that > people worked on for years and that never saw implementation, and > it seems to me that we ought to be trying to minimize the chances > of that happening with the protocols we're working on.
Exactly, which is why we need to make sure that the protocol does not fail to address its natural use-cases. This is a protocol for stapled DANE in TLS, and many potential applications will run in mixed WebPKI + DANE environments and will need to be able to do DANE *when possible*, in a downgrade-resistant manner (in this case after first contact). > I haven't seen > anything in this discussion that leads me to believe that the > extension as specified is fundamentally broken or insecure for its > intended use. The intended use in the introduction does not preclude Web browser HTTPS, JMAP, IMAP, POP, NNTP, SMTP Submission, XMPP, ... with only statically configured DANE for DPRIV in scope. DPRIV may well be the application that's ready now, but closing the door on others is surely unwise. > I'm good with adding clarifying text or scoping it > more clearly, but beating this thing to death for a use case that > nobody intends to implement seems a bit misguided to me. It is a mistake to confuse lack of immediate adoption plans with evidence that no such implementations will ever happen, and should be precluded at the outset. I had no idea DANE existed (too busy implementing comprehensive TLS support in Postfix to follow IETF work) when the DANE WG concluded work on RFC6698. 8 months later Tony Finch brought DANE to my attention, and I began implementation at that time. My implementation was the first non-toy implementation of DANE that got used in real systems. Was I ready to implement in August of 2012? No. Did I then never implement? Of course not, indeed we'd not be talking about DANE at all (it would be dead) if it were not for that work, and subsequent work to eliminate hurdles in the form of buggy authoritative servers at some major providers, integration into OpenSSL, Exim, ... The arguments against the proposal continue to ignore the technical issues and focus on perceived delay. If you really want to avoid delay, let's adopt the changes, and we'll be done. If there are technical flaws in the cost/benefit analysis that motivates the changes, please address those in detail. I see nothing in the draft that justifies limiting its scope to just a narrow application profile in which DANE is statically mandated by client policy. That limitation fails to scale. Even with DPRIV it should be possible for a server that no longer has TLSA records to provide a denial of existence proof (thus at least option (A) from the consensus call message) and employ PKIX instead (a domain may become unsigned if they change their mind about implementing DNSSEC). Option (B) supports incremental adoption, and provides downgrade protection after first contact, dramatically increasing the applicability. The changes are small, but needed to not preclude further implementation work in new application areas. There may not be implementors right away, but we should leave the door open for when they are. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls