On Mon, Oct 20, 2014 at 10:11 AM, Phillip Hallam-Baker <[email protected]> wrote: > > > On Mon, Oct 20, 2014 at 10:02 AM, Paul Hoffman <[email protected]> > wrote: >> >> > On Oct 20, 2014, at 1:25 AM, Stephane Bortzmeyer <[email protected]> >> > wrote: >> > >> > On Tue, Oct 14, 2014 at 10:04:14AM -0400, >> > Paul Wouters <[email protected]> wrote >> > a message of 80 lines which said: >> > >> >> I understand your wish for dnscurve to be useful, but it is >> >> unfortunately not more than that. dnscurve authenticates and >> >> encrypts traffic from stub to auth servers. It's core to its >> >> design. If you take that away, you are left with "some specific ECC >> >> curve encryption". >> > >> > I disagree here. The work to "port" DNScurve to the stub-to-resolver >> > link has already been done. It is called DNScrypt >> > <http://dnscrypt.org/>. It is actually deployed >> > <http://www.opendns.com/about/innovations/dnscrypt/> >> >> And, after many attempts by people here, it is still undocumented. The is >> a bit of a protocol description, but it is fairly incomprehensible, other >> than "we're using great crypto!". > > > +1 > > The task here isn't to produce a great protocol. It is to document a great > protocol in such a fashion that others can produce interoperable > implementations with minimal effort and confusion. > > And by great we mean that it is efficient and secure, but also it should > follow a design pattern that is compatible with the IETF approach. > > Designing a crypto protocol is not the difficult part, documentation and > deployment are. > > > By compatible with IETF approach I don't necessarily mean 'follow existing > practice' but any new approach should have clear advantages over existing. > So in TRANS, the spec is built into PKIX and uses ASN.1 where this is > appropriate. But noting that TLS is built on a different encoding and schema > language which is better (in the same way that stopping hitting yourself on > the head with a hammer is better than continuing), TRANS uses the TLS > approach rather than ASN.1. > > I don't see using DNSCurve as it is to be an option. At minimum we would > need thorough documentation.
Ok, so how about we say that it isn't a solution that we are currently considering, but if folk fully document dnscurve / dnscrypt in a draft, and bring it to the IETF / DPRIVE we will might consider it (and, obviously if it becomes a WG item, change it to meet the our requirements...) This has been (IMO) a really interesting / useful conversation (and I've been suitably hit with the cluebat^w^w^w^w educated), but let's also have a look at Stephane's "DNS privacy considerations" - https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy/ This technically in a Call for Adoption till Friday, but it is fairly clear that it will be adopted. So, let's start beating on the doc -- AFAICS, it looks about baked (I have an edit buffer with some tiny nits), and complete. Anyone have any substantive issues or changes that they'd like made? W > But I think we would also want to align > DNSCurve with the rest of the IETF infrastructure. In particular consider > using existing DNSSEC or TLS or PEM code points to describe algorithms. > > Once you get into documenting a protocol, the need for a schema language > becomes clear. In the 18 years its been public I have never once heard > anyone say that the TLS schema or encoding was problematic in any way. It > certainly makes the spec a lot easier to follow. > > People can of course argue that the logical conclusion of being IETF > compatible would be to 'simply' use DTLS. But that is only the easiest > approach if you are already committed to having a TLS library. Which is fine > for a desktop but a really bad commitment for an embedded device. My > proposal does cheat by reusing TLS right now and that is a completely > defensible long term strategy for desktops, mobile devices etc. I do not > think that is a defensible long term choice for DNS which needs to be a very > simple protocol that can be implemented in a few thousand lines. > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
