Subject: Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 26 May 2015 05:32:52 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of Daniel
> Kahn Gillmor
> Sent: Saturday, May 23, 2015 12:12 AM
> To: Tim Wicinski; [email-masked]
> Subject: Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls
> 
> On Wed 2015-05-20 10:03:27 -0400, Tim Wicinski wrote:
> > During the previous Call for Adoption a number of participants
> > expressed interest in adopting this work.  WG members felt it needed
> > some improvements, but thought it had potential. The authors addressed
> > the issues and feel it meets what the working group was seeking, and
> > have requested that we initiate a call for adoption.
> >
> > If the working group adopts this document, it only means it wishes to
> > study this solution more carefully.  The working group may still
> > determine to not move forward with it.
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-wing-dprive-dnsodtls/
> 
> I support the WG adopting this document for consideration.
> 
> I'm willing to review.
> 
> Looking at -01 of the draft:
> 
>  Section 3.2:
> 
>    Verifying the server certificate based on fingerprint needs to be
>    spelled out more clearly (what exactly is fingerprinted, how it is
>    fingerprinted).  But i don't think we should be fingerprinting the
>    certificate itself at all in this case.  I think we should be
>    fingerprinting the subject's public key.  The folks working on HTTP
>    Public Key Pinning (HPKP) already went through this discussion, and
>    settled on pinning public keys instead of certificates for good
>    reason: in the pinning case, we want to make sure that we're looking
>    at the same public key, not about the identity material wrapped
>    around it in the cert.  (this also allows them to work with
>    oob-pubkeys, as you recommend in section 7)

Agreed, will update the draft.

> 
> 
>  Section 3.3:
> 
>    This section seems to bundle assumptions about DHCP information and
>    system configuration all together ("an implementation will
>    attempt"). I think we should separate those considerations, and make
>    it clearer that this section is not a normative set of guidelines,
>    but rather a description of common behaviors and choices.

Okay, will update that this section is non-normative. 

> 
> Section 7:
> 
>    "amoritized" should be "amortized".  I'm not convinced by the NOT
>    RECOMMENDED in this section. Especially as the root zone expands, it
>    doesn't look all that much different than any other busy
>    authoritative nameserver.  This sort of SHOULD NOT ought to be backed
>    up by hard data, or some sort of operational characteristics (X
>    number of clients, each querying Y times per day, or something), or
>    else it looks like it would apply to all authoritative nameservers.
>    I understand that we want dprive to focus first on the stub->resolver
>    link, but i don't think we should shoot down using DNSSoD on
>    resolver->authoritative links without more consideration.

Yes, will keep it outside the scope and not soot it down.

Cheers,
-Tiru

> 
> Regards,
> 
>         --dkg
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "Jørgen Hovland" <[email-masked]>
Date: 27 May 2015 18:37:03 +0000 (UTC)

> Any chance you could add in a straight UDP round trip measurement so we have a benchmark to compare like with like?

8,9955 average

8.966 ms
9.020 ms
9.007 ms
8.984 ms
9.011 ms
8.985 ms

using traceroute with also 18 byte data (20 ip + 8 udp + 18 data)

For the crypto/openssl results, the server had CPU AES hardware support (E5-2690 v2) while the client had not (AMD 64 X2 Dual Core 5000+).

At 18:06 27/05/2015 (UTC), Phillip Hallam-Baker wrote:

Any chance you could add in a straight UDP round trip measurement so we have a benchmark to compare like with like?

On Tue, May 26, 2015 at 3:27 PM, Jørgen Hovland <[email-masked]> wrote:

At 03:04 26/05/2015 (UTC), Paul Hoffman wrote:

> Is the latency for an established TLS connection any worse than for a
DTLS connection? It would be good to see numbers if this is the case.

I did a test. The difference seems to be so small that it doesn't matter.

However,
DTLS handshake seems to be a bit slower than TLS handshake (not including TCP connect or DTLS cookie code).
Additionally, if I use the openssl CLI as DTLS server instead of my code, the DTLS handshake increases to around 34ms.
TCP connect takes around 9.1ms between my test-servers.

If you assume that the openssl CLI correctly implements a normal DTLS handshake while my code doesn't (due to no cookie code), TLS is faster than DTLS by around 2ms (8.4%) when a full connect/handshake with one write+read is done.

Server/client 500km apart from each other with simple echo server/round trip test:

TCP data read: 18, time spent write+read: 9.16038ms. Time spent TLS handshake 23.3289ms.
TCP data read: 18, time spent write+read: 9.07797ms. Time spent TLS handshake 21.4217ms.
TCP data read: 18, time spent write+read: 9.10591ms. Time spent TLS handshake 21.
1549ms.

TCP data read: 18, time spent write+read: 9.05283ms. Time spent TLS handshake 21.1289ms.
TCP data read: 18, time spent write+read: 9.02824ms. Time spent TLS handshake 21.2273ms.
TCP data read: 18, time spent write+read: 9.06903ms. Time spent TLS handshake 21.1971ms.
TCP data read: 18, time spent write+read: 9.07378ms. Time spent TLS handshake 21.3058ms.

UDP data read: 18, time spent write+read: 9.02713ms. Time spent DTLS handshake: 23.1482 ms.
UDP data read: 18, time spent write+read: 9.06344ms. Time spent DTLS handshake: 22.3601 ms.
UDP data read: 18, time spent write+read: 8.97628ms. Time spent DTLS handshake: 23.1001 ms.
UDP data read: 18, time spent write+read: 9.14725ms. Time spent DTLS handshake: 22.7562 ms.
UDP data read: 18, time spent write+read: 9.0721ms. Time spent DTLS handshake: 22.0508 ms.
UDP data read: 18, time spent write+read: 9.34728ms. Time spent DTLS handshake: 21.7002 ms.

(disclaimer: I assume my numbers are correct)

At 03:04 26/05/2015 (UTC), Paul Hoffman wrote:

On May 25, 2015, at 6:54 PM, Guangqing Deng <[email-masked]> wrote:

> Resolution latency is very crucial for DNS system and the latency of DNS-over-DTLS is relatively low compared with DNS-over-TLS.

Is the latency for an established TLS connection any worse than for a DTLS connection? It would be good to see numbers if this is the case.

--Paul Hoffman

dns-privacy mailing list

[email-masked]

dns-privacy mailing list

[email-masked]