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

[Warren Kumari <[e-mail]>]

Thanks everyone who responded.

We see there being support for adoption. We would also like to appoint the
current set of authors as authors of the adopted document (assuming they
are willing to continue authoring) - please resubmit as
draft-ietf-dprive-dnsodtls (or similar).

Shane raises an interesting point about it combining a mix of idea / tones
- it is possible that this may end up being split into a few more focused
documents.

Also (because it looks like we forgot to include this when starting the
CfA):

Dear DPRIVE WG participants,

We would like to check
whether there are claims of Intellectual Property Rights (IPR) on the
document that need to be disclosed.

Are you personally aware of any IPR that applies to
this document?  If so, has this IPR been disclosed in
compliance with IETF IPR rules?  (See RFCs 3979, 4879, 3669, and 5378
for more details.)

If you are a document author or listed contributor on this document,
please reply to this email message regardless of whether or not you
are personally aware of any relevant IPR.  We might not be able to
advance this document to the next stage until we have received a
reply from each author and listed contributor.

If you are on the DPRIVE WG email list but are not an author or listed
contributor for this document, you are reminded of your opportunity
for a voluntary IPR disclosure under BCP 79.  Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<http://www.ietf.org/ipr/file-disclosure>.

Thanks,
W
(as DRPIVE WG co-chair)



On Wed, May 27, 2015 at 2:37 PM Jørgen Hovland <[e-mail]> wrote:

> > 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 <[e-mail]
> <http://mail?p=compose&to=[e-mail]>> 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 <[e-mail]
>> <http://mail?p=compose&to=[e-mail]>> 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
>> [e-mail] <http://mail?p=compose&to=[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>>
>> _______________________________________________
>> dns-privacy mailing list
>> [e-mail] <http://mail?p=compose&to=[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>>
>  _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>