> On Oct 11, 2014, at 7:25 PM, John Heidemann <[email protected]> wrote:
>
>> On Thu, 09 Oct 2014 20:01:47 -0400, Warren Kumari wrote:
>> Hi there all,
>>
>> So, DPRIVE should be meeting in Hawaii, either as a fully fledged
>> working group, or like a BoF that we are planning on running like a WG
>> session.
>> ...
>>
>> One agenda request -- is there anyone who is knowledgeable on DNSCurve
>> and can explain clearly and in baby words (suitable for the likes of
>> me) why this doesn't solve all our problems? Perhaps we can be the
>> worlds shortest WG :-)
>
> We talk about this issue, comparing DNSCurve and DNSCrypt [*] in a
> section 3.2 of our tech report about T-DNS (one of the DNS-over-TLS
> proposals). (The tech report is at
> http://www.isi.edu/~johnh/PAPERS/Zhu14b/ .)
>
> My summary of what we wrote there:
>
> My biggest concern is that dnscurve/dnscrypt are bespoke for DNS.
>
> That's good and bad. The good is that it is very focused and has no
> "fat" for DNS.
>
> But for a long-lived standard, I think one wants something that lets you
> choose the crypto protocols, and change that choice with relative ease
> in the future. (Without taking a position on ECC here, I'm saying that
> NO single protocol should be locked in.) [**]
>
> Given the subtlety of crypto design and implementation issues, I also
> think using an off-the-shelf design (like TLS) and with multiple, mature
> implementations has a big advantage over rolling one's one. [***]
>
> Finally, dnscurve requires that the key go in the hostname of the
> server. For some, that's a downside, ranging from unpleasant to perhaps
> operationally impossible.
>
> There are also a bunch of pragmatic questions: are there draft specs for
> dnscrypt and dnscurve? multiple implementations? has IETF documented
> ECC yet? These can all be fixed with work, but it's not just
> off-the-shelf.
>
> But to me the core question is: is DNS really so special we
> want have design our own, new, protocol? Or can we follow what HTTP and
> SMTP and POP and IMAP do?
>
I totally disagree
TLS is a very complex protocol and designed for a completely different
application.
I use TLS to secure the key exchange. But not client resolver messages. The TLS
framing is designed for TCP and reuse really does not give any useful benefit.
Framing is easy to get right.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
