Re: [dns-privacy] Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt

[Petr Špaček <[e-mail]>]

On 11.4.2017 20:39, Mike Bishop wrote:
> Looks great – I’m excited to have another concrete application profile
> we can look at.
> 
>  
> 
> As a side note, I think 4.4 mischaracterizes any recent draft of
> HTTP/QUIC.  An HTTP server does explicitly need to listen for
> client-initiated streams opening; there’s no announcement of this
> happening on Stream 3 as you describe.  The main effect of choosing to
> have no control stream is that there can be no reliable session-level
> application context, since data on any stream can be lost via a stream
> reset at the wrong time. 
> 
>  
> 
> 5.2.2 is an example of this issue – how will the SERVFAIL be reliably
> delivered if the stream is reset?  You probably need to either define
> error codes for DNS/QUIC and replace SERVFAIL with those, or reliably
> deliver the SERVFAIL (somehow – by never resetting streams?).

Let me express support for Mike's comment above. Current text is
confusing when it comes to SERVFAIL.


Ad 6.4.  DNS Message IDs:
I'm in favor of the two blocks of proposed text:

   When sending multiple
   queries over a QUIC connection, clients MUST NOT reuse the DNS
   Message ID of an in-flight query on that connection in order to avoid
   Message ID collisions.

   Clients MUST match outstanding queries using the
   Message ID and if the response contains a question section, the
   client MUST match the QNAME, QCLASS, and QTYPE fields.


Reasoning:
There are various DNS proxies which change transport protocol between
UDP/TCP/TLS/HTTP on fly, without client knowing. We do not know how this
landscape will evolve so it is IMHO better to specify the same behavior
for message IDs and query matching regardless of transport to avoid
problems with tricks we do not see today.

The same applies to 6.3.  Response Sizes. For now I propose to keep the
same limitations for response sizes regardless of transport.


Thank you for writting this down!
Petr Špaček  @  CZ.NIC


> *From:*QUIC [mailto:[e-mail]] *On Behalf Of *Christian Huitema
> *Sent:* Monday, April 10, 2017 10:23 AM
> *To:* [e-mail]; [e-mail]
> *Subject:* Fwd: Fwd: New Version Notification for
> draft-huitema-quic-dnsoquic-00.txt
> 
>  
> 
>  
> 
> FYI: Just published this draft describing transport of DNS over a
> dedicated QUIC connection.
> 
> -- Christian Huitema
> 
> -------- Forwarded Message --------
> 
> *Subject: *
> 
> 	
> 
> New Version Notification for draft-huitema-quic-dnsoquic-00.txt
> 
> *Date: *
> 
> 	
> 
> Mon, 10 Apr 2017 09:45:37 -0700
> 
> *From: *
> 
> 	
> 
> [e-mail] <mailto:[e-mail]>
> 
> *To: *
> 
> 	
> 
> Melinda Shore <[e-mail]> <mailto:[e-mail]>, Sara
> Dickinson <[e-mail]> <mailto:[e-mail]>, Christian
> Huitema <[e-mail]> <mailto:[e-mail]>, Allison
> Mankin <[e-mail]> <mailto:[e-mail]>,
> Janardhan Iyengar <[e-mail]> <mailto:[e-mail]>, Jana Iyengar
> <[e-mail]> <mailto:[e-mail]>
> 
>  
> 
> A new version of I-D, draft-huitema-quic-dnsoquic-00.txt
> 
> has been successfully submitted by Christian Huitema and posted to the
> 
> IETF repository.
> 
>  
> 
> Name:          draft-huitema-quic-dnsoquic
> 
> Revision:      00
> 
> Title:         Specification of DNS over QUIC
> 
> Document date: 2017-04-10
> 
> Group:         Individual Submission
> 
> Pages:         18
> 
> URL:            https://www.ietf.org/internet-drafts/draft-huitema-quic-dnsoquic-00.txt
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-huitema-quic-dnsoquic-00.txt&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=QxDgeYj6NMHseVKcgY%2Fv8pgLqj09avV1PnGaOJv7%2B3c%3D&reserved=0>
> 
> Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-huitema-quic-dnsoquic%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=c7MuOxq2w3L2jz3MWcwA96gCJq8l3ckGjnCF6fHJfNk%3D&reserved=0>
> 
> Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-huitema-quic-dnsoquic-00&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=i4nBJms1WZwRo78vAZWFSAlfuH49H8zD2WjQIu2Gqwc%3D&reserved=0>
> 
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-huitema-quic-dnsoquic-00&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C5df00a51bfe64b16ca4b08d480363ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636274417782332222&sdata=JywZYehy3Axc7sDXskM2mGeW4kdiiPBSMZlbicD1N58%3D&reserved=0>
> 
>  
> 
>  
> 
> Abstract:
> 
>    This document describes the use of QUIC to provide transport privacy
> 
>    for DNS.  The encryption provided by QUIC has similar properties to
> 
>    that provided by TLS, while QUIC transport eliminates the head-of-
> 
>    line blocking issues inherent with TCP and provides more efficient
> 
>    error corrections than UDP.  DNS over QUIC has privacy properties
> 
>    similar to DNS over TLS specified in RFC7858, and performance similar
> 
>    to classic DNS over UDP.
> 
>  
> 
>                                                                                   
> 
>  
> 
>  
> 
> Please note that it may take a couple of minutes from the time of submission
> 
> until the htmlized version and diff are available at tools.ietf.org.
> 
>  
> 
> The IETF Secretariat