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

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Apr 2017 10:22:32 -0700

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: 	[email-masked]
To: 	Melinda Shore <[email-masked]>, Sara Dickinson
<[email-masked]>, Christian Huitema <[email-masked]>, Allison
Mankin <[email-masked]>, Janardhan Iyengar <[email-masked]>,
Jana Iyengar <[email-masked]>

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
Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/
Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-quic-dnsoquic-00

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Apr 2017 21:18:24 +0100

Great to see this. I hope it gets traction and am willing
to read comment etc if this gets adopted somewhere.

Cheers,
S.

On 10/04/17 18:22, Christian Huitema wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 11 Apr 2017 06:43:19 +0000

Hello Christian,

great to see this – i remember when i mentioned QUIC as an option during the DNS-over-HTTP Bar BoF in Seoul i got quite a few weird looks :). I like this. It looks like a logical choice somewhere „between“ TLS and DTLS.

I have some background on Section 6.5 (Padding) – back when we specified DNS over TLS, we had a similar discussion whether to pad on the DNS or the transport (TLS, in that case) layer. We decided in that case that padding on the DNS layer is preferred, since it allows for greater control by the application. This was actually the reason RFC 7830 was created in the first place.

The situation might be different for QUIC as there’s a tighter coupling between transport and application, though padding on the DNS layer would allow re-using the ongoing research and specification work in DPRIVE. (Disclaimer: I know little about the current state of such research for QUIC).

best,
Alex

Von: dns-privacy [mailto:[email-masked]] Im Auftrag von Christian Huitema
Gesendet: Montag, 10. April 2017 19:23
An: [email-masked]; [email-masked]
Betreff: [dns-privacy] Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt [x_phishing]

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:

[email-masked]<mailto:[email-masked]>

To:

Melinda Shore <[email-masked]><mailto:[email-masked]>, Sara Dickinson <[email-masked]><mailto:[email-masked]>, Christian Huitema <[email-masked]><mailto:[email-masked]>, Allison Mankin <[email-masked]><mailto:[email-masked]>, Janardhan Iyengar <[email-masked]><mailto:[email-masked]>, Jana Iyengar <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:     00

Pages:        18

Abstract:

   to classic DNS over UDP.

The IETF Secretariat

---

From: "Marco Davids (IETF IMAP)" <[email-masked]>
Date: Tue, 11 Apr 2017 13:28:38 +0200

> dedicated QUIC connection.

I like it.

I see why port 953 was chosen. But it is also a longtime de facto
default for the rndc communications channel of BIND.

--
Marco

---

From: Ray Bellis <[email-masked]>
Date: Tue, 11 Apr 2017 12:33:36 +0100

> default for the rndc communications channel of BIND.

Yes, it is.

I am trying to make that formal rather than de facto with IANA at the
moment.

Ray

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Apr 2017 10:51:45 -0700

On 4/10/2017 11:43 PM, Alexander Mayrhofer wrote:
>
> Hello Christian,
>
>  
>
> great to see this – i remember when i mentioned QUIC as an option
> during the DNS-over-HTTP Bar BoF in Seoul i got quite a few weird
> looks :). I like this. It looks like a logical choice somewhere
> „between“ TLS and DTLS.
>
>  
>
> I have some background on Section 6.5 (Padding) – back when we
> specified DNS over TLS, we had a similar discussion whether to pad on
> the DNS or the transport (TLS, in that case) layer. We decided in that
> case that padding on the DNS layer is preferred, since it allows for
> greater control by the application. This was actually the reason RFC
> 7830 was created in the first place.
>
>  
>
> The situation might be different for QUIC as there’s a tighter
> coupling between transport and application, though padding on the DNS
> layer would allow re-using the ongoing research and specification work
> in DPRIVE. (Disclaimer: I know little about the current state of such
> research for QUIC).
>
>  
>
The situation is different in QUIC, because a single QUIC packet may
carry several DNS packets, using separate STREAM-DATA frames to carry
the content of different streams. Of course, the DNS application does
not know whether the QUIC transport will in fact pack data from several
streams in a single packet, so what we need here is some kind of API
contract.

The efficient solution would be to instruct the transport to perform a
particular padding strategy, similar to the padding strategies developed
for DNS. This would cover many applications, not just DNS. Failing that,
padding at the DNS layer has the advantage of being easy to implement.

-- Christian Huitema

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Apr 2017 18:39:36 +0000

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?).

From: QUIC [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Monday, April 10, 2017 10:23 AM
To: [email-masked]; [email-masked]
Subject: Fwd: Fwd: New Version Notification for draft-huitema-quic-dnsoquic-00.txt

-------- Forwarded Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      00

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:

   to classic DNS over UDP.

The IETF Secretariat