Subject: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

From: Tim Wicinski <[email-masked]>
Date: Tue, 3 Nov 2015 21:54:27 +0900

During the meeting on Monday, it was obvious the Working Group wanted to 
make this an official EDNS option.  We reached out to the author and 
while he is traveling for an extended period of time, he is happy to 
work on edits (with a small delay built in, but nothing this impatient 
chair finds too onerous).

This starts a Call for Adoption fordraft-mayrhofer-edns0-padding

The draft is available here:
https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding/

Please review this draft to see if you think it is suitable for adoption 
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends 17 November, 2015 12:00 UTC

Thanks,
tim wicinski

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 3 Nov 2015 09:10:21 -0500

I think is a good document and I support it and will review. 

Olafur

> On Nov 3, 2015, at 7:54 AM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> During the meeting on Monday, it was obvious the Working Group wanted to make this an official EDNS option.  We reached out to the author and while he is traveling for an extended period of time, he is happy to work on edits (with a small delay built in, but nothing this impatient chair finds too onerous).
> 
> Please review this draft to see if you think it is suitable for adoption by DPRIVE, and comments to the list, clearly stating your view.
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "Mankin, Allison" <[email-masked]>
Date: Tue, 3 Nov 2015 14:54:02 +0000

I support the adoption by DPRIVE and I will comment on it and review it.

Initial comment about Section 4:

    However, padded DNS messages MUST NOT exceed the respective
    UDP payload size (see Section 6.2.3 and 6.2.4 of [RFC6891]).

The above text is potentially confusing for when the use of the padding
option will be by a DNS-over-TLS (TCP) request (even though the RFC 6891
reference is very helpful).

Could it be written instead like the below:

    However, padded DNS messages MUST NOT exceed the number of
    octets specified in the requestor¹s Payload Size field encoded
    in the RR Class Field (see Sections 6.2.3 and 6.2.4 of [RFC 6891]).

Tiny nit: ³octets² is spelled ³octects² throughout the draft.

Allison

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Nov 2015 18:58:59 -0500 (EST)

> This starts a Call for Adoption fordraft-mayrhofer-edns0-padding

I support the adoption by DPRIVE and will review it.

> https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding/

Paul

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 04 Nov 2015 09:12:09 -0500

Hi Tim,

On 3 Nov 2015, at 7:54, Tim Wicinski wrote:

> During the meeting on Monday, it was obvious the Working Group wanted 
> to make this an official EDNS option.  We reached out to the author 
> and while he is traveling for an extended period of time, he is happy 
> to work on edits (with a small delay built in, but nothing this 
> impatient chair finds too onerous).
>
> Please review this draft to see if you think it is suitable for 
> adoption by DPRIVE, and comments to the list, clearly stating your 
> view.

I have reviewed this draft, support its adoption and will review.

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Nov 2015 08:49:40 +0900

On Tue 2015-11-03 21:54:27 +0900, Tim Wicinski wrote:
> This starts a Call for Adoption for draft-mayrhofer-edns0-padding
>

I support adoption of this draft.  I have reviewed it and think it is
sensible.

I have also implemented it for queries in the getdns client library, and
it worked fine in communication with servers listening over TLS, making
otherwise-distinguishable queries indistinguishable to a network
observer:

   Table 0. Ethernet Frame sizes for packet containing DNS query

                Transport    |   query to   |     query to
                   used      |  example.com |  www.example.com
   --------------------------+--------------+-------------------
               cleartext UDP |   82 octets  |   86 octets
               cleartext TCP |  108 octets  |  112 octets
                TLS over TCP |  137 octets  |  141 octets
(padded to 512) TLS over TCP |  609 octets  |  609 octets

I used a value from the local/experimental range of DNS options (i chose
65461), but i'd like to move to using a standard EDNS(0) OPT code.  

The registry here:

  https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11

suggests that the registration procedure is "Expert Review", and points
to Olafur, who i'm Cc'ing here.

Can we ask for early codepoint assignment?  The registry has a lot of
space, and the draft is simple and easy to implement.

Regards,

    --dkg

---

From: Tim WIcinski <[email-masked]>
Date: Thu, 5 Nov 2015 09:53:28 +0900

dkg,

I've already reached out for the EDNS Option Code, and it has been 
approved by the ExpertReview and we are awaiting IANA.

tim

---

From: Alex Mayrhofer <[email-masked]>
Date: Thu, 05 Nov 2015 16:50:42 +1300

I've submitted a -00 WG version of the draft, which is now pending WG Chairs approval. 

Hope I got everything right, since the draft was edited from a phone onboard a ferry with crappy wifi and while coloring a pirates book with a 3yo ;-)

Alex

---

From: Kumar Ashutosh <[email-masked]>
Date: Thu, 5 Nov 2015 05:10:14 +0000

Hi
I reviewed the draft and here are a few comments:
“The PADDING octects MUST be set to 0x00.  If a Responder detects non-
   0x00 octects in the padding of a query, a FORMERR (RCODE=1) MUST be
   returned.”

è Is MUST necessary here? There might be existing responders that may be agnostic to this and not parse this option code. They may not return Formerr. For quick adoption changing this to SHOULD or providing option to ignore this will be useful.

è What is the guidance for the proxy systems used in front of DNS servers (load balancer or traffic managers)? Should they be validating this option for correctness or be plain tunnels?

è What if the packet does not have space to pad? Do we have a Padding option with length 0? Or we truncate messages?

The 'Padding'
   option MUST occur at most once per OPT meta-RR.

è Is not there only one OPT RR per packet? There can be multiple option IDs but RR is only one. Just checking if the statement above is semantically correct.

Also, +1 for approval
Thanks
Ashu
Microsoft

From: dns-privacy [mailto:[email-masked]] On Behalf Of Alex Mayrhofer
Sent: Thursday, November 5, 2015 9:21 AM
To: [email-masked]; Tim WIcinski <[email-masked]>
Subject: Re: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

Alex

---- Tim Wicinski schrieb ----

The draft is available here:
https://datatracker.ietf.org/doc/draft-mayrhofer-edns0-padding<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-mayrhofer-edns0-padding&data=01%7c01%7caskuma%40064d.mgd.microsoft.com%7cbb1a31c363bf4815fe0c08d2e59452e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UUwYipRiIk3lqr3B9inboeib9O%2f4UKEZvRqIyOQE5lA%3d>/

Thanks,
tim wicinski

_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fdns-privacy&data=01%7c01%7caskuma%40064d.mgd.microsoft.com%7cbb1a31c363bf4815fe0c08d2e59452e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8tnOYM9kthGyTUJgo9FESY64rdDR64UX8f2%2fTDR9Z%2fo%3d>

---

From: Alex Mayrhofer <[email-masked]>
Date: Fri, 06 Nov 2015 10:43:10 +1300

Hello Ashu,

Thanks for the review - responses as follows: (sorry for the crappy style, this is from mobile) 

- First point: the keywords here are 'if a Responder detects'... Which means that if it's unaware of the option or elects to not check it, it doesn't need to respond with a FORMERR. But if it does check the option, it MUST respond with an formerr.

- Proxies: as far as I understand, EDNS is always hop to hop. So both legs of a proxy could process the option independently. A recursor might want to do padding downstream to stub resolvers, but might not pad upstream to Auth servers.

- One option: I believe this is correct, but I'm happy to be learn more? EDNS options can be used several times in a single opt RR record, so thistext restricts the padding option  use to a single occurrence.

- padding MUST NOT be done if that wounded to truncation. I believe this is stated indirectly  in the draft already. Do you feel this should be expressed differently?

Thanks again for the review!

Alex

---- Kumar Ashutosh schrieb ----

><!-- /* Font Definitions */ @font-face 	{font-family:Wingdings; 	panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face 	{font-family:"Cambria Math"; 	panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face 	{font-family:Calibri; 	panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal 	{margin:0in; 	margin-bottom:.0001pt; 	font-size:12.0pt; 	font-family:"Times New Roman",serif;} a:link, span.MsoHyperlink 	{mso-style-priority:99; 	color:blue; 	text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed 	{mso-style-priority:99; 	color:purple; 	text-decoration:underline;} p 	{mso-style-priority:99; 	mso-margin-top-alt:auto; 	margin-right:0in; 	mso-margin-bottom-alt:auto; 	margin-left:0in; 	font-size:12.0pt; 	font-family:"Times New Roman",serif;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph 	{mso-style-priority:34; 	margin-top:0in; 	margin-right:0in; 	margin-bottom:0in; 	margin-left:.5in; 	margin-bottom:.0001pt; 	font-size:12.0pt; 	font-family:"Times New Roman",serif;} p.msonormal0, li.msonormal0, div.msonormal0 	{mso-style-name:msonormal; 	mso-margin-top-alt:auto; 	margin-right:0in; 	mso-margin-bottom-alt:auto; 	margin-left:0in; 	font-size:12.0pt; 	font-family:"Times New Roman",serif;} span.EmailStyle19 	{mso-style-type:personal-reply; 	font-family:"Calibri",sans-serif; 	color:#1F497D;} .MsoChpDefault 	{mso-style-type:export-only;} @page WordSection1 	{size:8.5in 11.0in; 	margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 	{page:WordSection1;} /* List Definitions */ @list l0 	{mso-list-id:2103380202; 	mso-list-type:hybrid; 	mso-list-template-ids:569944682 1392397606 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;} @list l0:level1 	{mso-level-start-at:0; 	mso-level-number-format:bullet; 	mso-level-text:; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:.75in; 	text-indent:-.25in; 	font-family:Wingdings; 	mso-fareast-font-family:Calibri; 	mso-bidi-font-family:"Times New Roman";} @list l0:level2 	{mso-level-number-format:bullet; 	mso-level-text:o; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:1.25in; 	text-indent:-.25in; 	font-family:"Courier New";} @list l0:level3 	{mso-level-number-format:bullet; 	mso-level-text:; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:1.75in; 	text-indent:-.25in; 	font-family:Wingdings;} @list l0:level4 	{mso-level-number-format:bullet; 	mso-level-text:; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:2.25in; 	text-indent:-.25in; 	font-family:Symbol;} @list l0:level5 	{mso-level-number-format:bullet; 	mso-level-text:o; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:2.75in; 	text-indent:-.25in; 	font-family:"Courier New";} @list l0:level6 	{mso-level-number-format:bullet; 	mso-level-text:; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:3.25in; 	text-indent:-.25in; 	font-family:Wingdings;} @list l0:level7 	{mso-level-number-format:bullet; 	mso-level-text:; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:3.75in; 	text-indent:-.25in; 	font-family:Symbol;} @list l0:level8 	{mso-level-number-format:bullet; 	mso-level-text:o; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:4.25in; 	text-indent:-.25in; 	font-family:"Courier New";} @list l0:level9 	{mso-level-number-format:bullet; 	mso-level-text:; 	mso-level-tab-stop:none; 	mso-level-number-position:left; 	margin-left:4.75in; 	text-indent:-.25in; 	font-family:Wingdings;} ol 	{margin-bottom:0in;} ul 	{margin-bottom:0in;} --> 
>
>Hi 
>

---

From: Kumar Ashutosh <[email-masked]>
Date: Fri, 6 Nov 2015 03:23:33 +0000

Thanks Alex. Would be better to add a line on the truncation. I shall look back again on the next draft.

From: Alex Mayrhofer [mailto:[email-masked]]
Sent: Friday, November 6, 2015 03:13
To: [email-masked]; Tim Wicinski <[email-masked]>; Kumar Ashutosh <[email-masked]>
Subject: AW: RE: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

Hello Ashu,

Alex

---- Kumar Ashutosh schrieb ----
Hi

==> Is MUST necessary here? There might be existing responders that may be agnostic to this and not parse this option code. They may not return Formerr. For quick adoption changing this to SHOULD or providing option to ignore this will be useful.

==> What is the guidance for the proxy systems used in front of DNS servers (load balancer or traffic managers)? Should they be validating this option for correctness or be plain tunnels?

==> What if the packet does not have space to pad? Do we have a Padding option with length 0? Or we truncate messages?

The 'Padding'

==> Is not there only one OPT RR per packet? There can be multiple option IDs but RR is only one. Just checking if the statement above is semantically correct.

Also, +1 for approval
Thanks
Ashu
Microsoft

From: dns-privacy [mailto:[email-masked]] On Behalf Of Alex Mayrhofer
Sent: Thursday, November 5, 2015 9:21 AM
To: [email-masked]<mailto:[email-masked]>; Tim WIcinski <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dns-privacy] Call for Adoption: draft-mayrhofer-edns0-padding

Alex

---- Tim Wicinski schrieb ----

Thanks,
tim wicinski

---

From: Christopher Wood <[email-masked]>
Date: Fri, 6 Nov 2015 20:22:17 -0800

On Tue, Nov 3, 2015 at 4:54 AM, Tim Wicinski <[email-masked]> wrote:
> Please review this draft to see if you think it is suitable for adoption by
> DPRIVE, and comments to the list, clearly stating your view.

I reviewed this draft and support its adoption by DPRIVE. Thanks to
Allison, Kumar, and Alex, I have no additional comments.

> Please also indicate if you are willing to contribute text, review, etc.

I am willing to review it.

Best,
Chris

---

From: Shane Kerr <[email-masked]>
Date: Wed, 11 Nov 2015 16:22:15 +0100

Alex,

On Fri, 06 Nov 2015 10:43:10 +1300
Alex Mayrhofer <[email-masked]> wrote:
 
> - First point: the keywords here are 'if a Responder detects'...
> Which means that if it's unaware of the option or elects to not check
> it, it doesn't need to respond with a FORMERR. But if it does check
> the option, it MUST respond with an formerr.

This might have been your intent, but I read it the same as Ashu did.

Further, I don't think there is any possible benefit for this check.
The most likely result is going to be that implementors will read this
and think that they need code in there to confirm that all bytes are 0.

I feel pretty strongly that this text should be left out.
 
Cheers,

--
Shane

---

From: Alex Mayrhofer <[email-masked]>
Date: Sun, 15 Nov 2015 21:33:25 +1300

---- Shane Kerr schrieb ----

> Alex Mayrhofer <[email-masked]> wrote:

...

> This might have been your intent, but I read it the same as Ashu did.

Ok, I understand that the text seems to be unclear. However, my intentions were actually twofold, namely:

1) A Responder MAY (?... ) check the payload for non-0x00 octets.

2) the error code to use for malformed payload is FORMERR.

I perfectly understand that most Responders will not want to check this ( for performance reasons), and I think the above statements would allow for that.

> Further, I don't think there is any possible benefit for this check.

I think there is. It discourages the use of the payload as a covert channel. While a high performance Auth server might not want to check this, a firewall might definitely want to validate the payload for security reasons.

> and think that they need code in there to confirm that all bytes are 0.

Understood. I mainly wanted to remove ambiguity about the response code to use in this case.

> I feel pretty strongly that this text should be left out.

What about splitting the text into its two logical parts, according to my two points above?  Would that work?

Alex

---

From: Shane Kerr <[email-masked]>
Date: Sun, 15 Nov 2015 11:02:50 +0200

Alex,

At 2015-11-15 21:33:25 +1300
Alex Mayrhofer <[email-masked]> wrote:

> Ok, I understand that the text seems to be unclear. However, my
> intentions were actually twofold, namely:
> 
<
> I perfectly understand that most Responders will not want to check
> this ( for performance reasons), and I think the above statements
> would allow for that.

Okay, I think that this is quite reasonable. Text simply saying that is
fine with me. Perhaps something like:

"A Responder MAY check the payload for non-0x00 octets. If any are
discovered, then this is a malformed payload, and the Responder should
use the FORMERR return code."

> I think there is. It discourages the use of the payload as a covert
> channel. While a high performance Auth server might not want to check
> this, a firewall might definitely want to validate the payload for
> security reasons.

In principle EDNS0 padding is mostly used to prevent attackers from
using packet size as a way to do traffic analysis on queries, right? So
mostly this will be within encrypted packets (or streams), and in
general a firewall or other middlebox will not have access to the
contents of the packet.

Still, I suppose that it is worthwhile documenting that using EDNS0
padding as a covert channel is a Bad Idea(tm) and that Responders may
check this for the purpose of discouraging such usage.

> > The most likely result is going to be that implementors will read
> > this and think that they need code in there to confirm that all
> > bytes are 0.  
> 
> 

Cool.

> to my two points above?  Would that work?

Yes, I think this is reasonable.

Cheers,

--
Shane

---

From: Andreas Gustafsson <[email-masked]>
Date: Sun, 15 Nov 2015 20:27:34 +0200

Alex Mayrhofer wrote:
> channel. While a high performance Auth server might not want to
> check this, a firewall might definitely want to validate the payload
> for security reasons.

The DNS already has other covert channels such as the message IDs.
Since privacy is the goal, having a higher bandwidth one could be
construed as a feature. :)

I'm also wondering if there might be scenarios where the messages are
compressed before encryption.  If that is the case, padding with zeros
is of limited value because they will mostly compress away, and the
ability to send data of similar compressibility to actual payload
data, or data of unpredictable compressibility, would be useful.
-- 
Andreas Gustafsson, [email-masked]

---

From: Shane Kerr <[email-masked]>
Date: Mon, 16 Nov 2015 12:25:32 +0200

Andreas,

At 2015-11-15 20:27:34 +0200
> data, or data of unpredictable compressibility, would be useful.

It's an interesting idea, but I think I'd like to see some solid
research on this. We understand how to add 0 bytes; I don't personally
understand the implications of generating "similarly compressible" data
to prevent attackers from doing traffic analysis.

My own feeling is that we should proceed with 0-padding, and perhaps
consider alternate schemes later if there is good guidance in the area
of non-empty padding.

Surely academics have looked at this! Do you have pointers to some
papers covering this approach?

Cheers,

--
Shane

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 16 Nov 2015 15:41:27 +0200

> consider alternate schemes later if there is good guidance in the area

We can certainly proceed with *sending* 0-padding.  All I'm asking is
for receivers not to reject messages with nonzero padding, so that if
alternate schemes are introduced in future senders, they can
interoperate with existing receivers.

> papers covering this approach?

I'm afraid not.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 16 Nov 2015 10:28:08 -0500

> On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <[email-masked]> wrote:
> 
> Shane Kerr wrote:

+1 All resolvers should ignore the contents padding 

>> papers covering this approach?

Shane, 

There is lots of work in this area, but it is trivial to reason about the issue from DNS perspective
Goal: hide how long the query name is, to defeat traffic analysis. 
 
Padding of the same value in each byte can be compressed to almost nothing ==> same as having no padding, ==> failed to meet goal. 
TLS by default in many cases, compresses before transmission,  ==> DNS padding option must defeat compression

I think the WG should consider if the current text of saying use 0x00 is not good enough, 
there are 3 options, use: 
	- 0x00
        - cheap randomness 
        - real randomness source
 
I think the middle one is good enough, a simple seeded hash function i.e. HMAC  is sufficient or /dev/urandom 

Olafur

---

From: Watson Ladd <[email-masked]>
Date: Mon, 16 Nov 2015 10:31:28 -0500

> TLS by default in many cases, compresses before transmission,  ==> DNS padding option must defeat compression

This is a problem that is easily fixed: turn off compression. TLS 1.3
is eliminating compression for similar reasons.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Bob Harold <[email-masked]>
Date: Mon, 16 Nov 2015 11:11:20 -0500

On Mon, Nov 16, 2015 at 10:31 AM, Watson Ladd <[email-masked]> wrote:

> > Padding of the same value in each byte can be compressed to almost
> nothing ==> same as having no padding, ==> failed to meet goal.

The reason they wanted 0-padding, and to be verified by the receiver is to
prevent that data from being used as a hidden communication channel by
viruses.  Changing that to random, or not checked, is therefore a problem.
But then it is compressible, which is a different issue.  I don't see an
easy solution.

-- 
Bob Harold

---

From: Shane Kerr <[email-masked]>
Date: Mon, 16 Nov 2015 18:32:57 +0200

Olafur,

At 2015-11-16 10:28:08 -0500

> +1 All resolvers should ignore the contents padding 

SHOULD or MUST?

If it is SHOULD, then it makes sense to document what to do if you
check the padding.

Personally I am happy if we decide that padding MUST be ignored (which
was my original suggestion).
   
> I think the middle one is good enough, a simple seeded hash function i.e. HMAC  is sufficient or /dev/urandom 

Probably a paragraph saying "turn off TLS compression" is a better
approach than trying to figure out how to defeat the compression?

I your analysis is slightly incorrect, because DNS packets are highly
compressible. For example each RR includes RTYPE, TTL, and so on, which
will be identical for the entire RRset.

So for 0x00 we end up with the padding being compressed out and
effectively pointless.

For random data (cheap or real), we end up with the padding being not
compressed at all, compared to the actual data, which is highly
compressed. It complicates traffic analysis, but I have faith that the
big data guys at the NSA can still get some probabilistic pattern
matching working. ;)

If we worry about compression, then shouldn't we add entries that
compress "similarly" to actual packet data? That seems hard, hence my
suggestion to simply remind people to turn TLS compression off.

Cheers,

--
Shane

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 16 Nov 2015 16:51:55 +0000

> approach than trying to figure out how to defeat the compression?

Possibly reference the TLS BCP on this:

https://tools.ietf.org/html/rfc7525#section-3.3 <https://tools.ietf.org/html/rfc7525#section-3.3>

Sara.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Nov 2015 07:19:56 +1100

> But then it is compressible, which is a different issue.  I don't see an

And checking helps how?  A virus writer worth their salt will pad
w/ 0 unless they are talking to a known CC server which can be done
by looking at the server's key.  If I can think of how to do this
without detection so can the virus writer.

This attituted to shutdown every possible convert channel makes
developing / extending protocols difficult.  It is also impossible
to do.

Attempting to use a new opcode (15) runs into trouble link this
as shown by testing all the servers in the root zone gives:

[marka@ednscomp ~]$ awk '/dns=/ {print $10}' tld-report/fullreport/full-tld.2015-11-16T00\:00\:00Z  | sort | uniq -c
  37 opcode=formerr
7291 opcode=ok
2133 opcode=timeout
[marka@ednscomp ~]$ 

I haven't deduped by IP address yet.

37 sites with the wrong error code FORMERR (how can you return
	formerr when you don't know the format)
7291 returning NOTIMP
2133 do not respond to the unknown opcode.  (a couple of these will
	be unreachable servers)

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2015 16:05:41 -0500

> approach than trying to figure out how to defeat the compression?

yes, please.  The consensus of the TLS WG is that compression simply
does not belong at the TLS layer, that it was a mistake to put it there
in the first place, and that it will not be supported in the future.

Any attempt at compression needs to happen at the application layer
itself with full knowledge of the risks and tradeoffs. This implies that
if DNS cares about compression, it needs to write DNS-specific
compression rules, and those rules themselves need to clearly grapple
with what to do with packet padding when DNS-specific compression is
used.

I'm not proposaing that the DNS community do any sort of work on
compression right now.  We just need a simple statement that padding is
only expected to be useful against traffic analysis under encrypted
and non-compressed connections.

    --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Nov 2015 21:20:21 +0000

Hiya,

> in the first place, and that it will not be supported in the future.

I agree that that is clearly the opinion in the TLS WG today. I'm
less sure I agree that's correct - my fear is that it's being driven
maybe too much by browsers and the web, where the conclusion is
valid.

> itself with full knowledge of the risks and tradeoffs. 

FWIW, I don't agree with the above, I think it's generalising too
much from the browser use-case.

> This implies that

I agree with the above though, so we end up in the same place:-)

I think for DPRIVE it could perhaps be enough to say that any padding
ought only be done after compression, if compression is done at all.
And of course padding is only of use if the data is encrypted before
transmission.

Cheers,
S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2015 20:43:39 -0500

> maybe too much by browsers and the web, where the conclusion is

Well, certainly for a system-wide (or application-wide) arbitrary DNS
client it's the same risk.  We have no way of knowing how many avenues
there are for attackers to be able to make the user make certain DNS
requests to their preferred privacy-preserving resolver.

And since we expect (D)TLS channels to be kept open and reused, that
attacker-controlled data will be touching the same deflate dictionary
that the ostensibly private queries are using.  This is the same
scenario as CRIME and BREACH, no?

> much from the browser use-case.

The point here is that if you don't know how the application layer mixes
attacker-controlled data with data that needs to be confidential, TLS
can't possibly do compression safely.

So while i agree with you that there could be (non-browser) applications
that clearly never mix any attacker-controlled data with
sensitive/private data on the same TLS channel, the only way to know
whether you're in such a state is by reasoning about it *at the
application layer*, which is why that's where the decisions about
compression need to be made.

anyway, i'm glad we agree on the outcome :)

     --dkg

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 16 Nov 2015 21:46:17 -0500

> On Nov 16, 2015, at 11:32 AM, Shane Kerr <[email-masked]> wrote:
> 
> Olafur,
> 
> Olafur Gudmundsson <[email-masked] <mailto:[email-masked]>> wrote:
> 

MUST is fine, 

> approach than trying to figure out how to defeat the compression?

yes that is much better, 
> will be identical for the entire RRset.

I wish DNS software just stopped doing compression and we could rip out lots of ugly slow code :-) 

> suggestion to simply remind people to turn TLS compression off.

I agree lets just say TLS compression MUST be OFF 

Olafur

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 17 Nov 2015 11:05:26 -0800

On 16-Nov-2015 08:11 am, Bob Harold <[email-masked]> wrote: 
> 
> On Mon, Nov 16, 2015 at 10:31 AM, Watson Ladd <[email-masked] <mailto:[email-masked]>> wrote:
> On Mon, Nov 16, 2015 at 10:28 AM, Olafur Gudmundsson <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Shane Kerr wrote:
> >>> Andreas Gustafsson <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>
> The reason they wanted 0-padding, and to be verified by the receiver is to prevent that data from being used as a hidden communication channel by viruses.  Changing that to random, or not checked, is therefore a problem.  But then it is compressible, which is a different issue.  I don't see an easy solution.

There are a myriad of other, existing hidden communication channels, including 0x20 encoding, DGA, etc.  I agree padding is another vector, but padding is only between the two DPRIVE entities, and is terminated there (unlike DGA which always hits the authoritative server).  Padding is a steganographic channel and only useful when communicating directly with the peer that understands the meaning of the padding, in which case non-DNS packets could be sent to that peer, anyway.

-d

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Nov 2015 21:38:58 +0000

On 17/11/15 01:43, Daniel Kahn Gillmor wrote:
> client it's the same risk.

Similar but not quite the same. Cookies are the main likely target
of CRIME but a DPRIVE equivalent can only target the (non-inserted)
QNAME (or is there more?), which hasn't quite got the same kind of
sensitivity.

>  We have no way of knowing how many avenues

Sure. I would guess the introduction of DPRIVE will change the
attack surface and new attacks will be discovered. (Timing may
well prove a fertile ground I would guess.)

> scenario as CRIME and BREACH, no?

Depends. It is unclear to me why padding doesn't help here,
if applied after compression. (Mind you, at that point I don't
know why one is bothering with compressing;-)

> can't possibly do compression safely.

But what is the application layer for a system wide stub resolver?
Your argument would also imply DNS/DPRIVE can't do compression either.

> compression need to be made.

We don't agree about that. I don't think I've seen a convincing
argument that's the *only* way to know. (E.g. always emitting
fixed size packets in a single write and sending some cover
traffic now and then when there's any compression in play would
also seem to help, no?) But that's off topic for this list I
guess, and may get too complicated before it'd get useful
enough.

> anyway, i'm glad we agree on the outcome :)

Yep - isn't the entire discussion of compression for DNS
pretty moot anyway? It's not clear to me what compressible
plaintext there is where compression would be a real benefit.

Cheers,
S.

---

From: Alex Mayrhofer <[email-masked]>
Date: Wed, 18 Nov 2015 11:30:53 +1300

Hello,

Jumping into this thread late, sorry. Anyways, my proposal:

- I think we should stick with requiring 0x00 padding (I am avoiding the term 'payload' here for a reason). This would prevent the abuse as a covert channel, is easily understood and implementable, and should not have any significant performance impact during creation of a message. 

- In the sense of "be conservative what you send, be liberal what to accept" I'm fine to change to text to require (recommend?) a Responder to ignore the contents. Which means that a malformed padding will never (rarely?) trigger an error response. However, my feeling is that we should still allow a "strict Responder" to indicate an error. That boils down to text like "a Responder MUST/SHOULD (?) ignore the contents of Padding" - I'd go for SHOULD,  and subsequently keep the definition to use FORMERR if a strict Responder wishes to indicate an error

- Further, I understand that TLS level compression is discouraged for DNS anyways ( I'm not an expert in this field, but that's what I understood what dkg said in our initial hallway discussion in Praha), so I'd stick with 0x00. If we find out this is really a problem,  we can always define a padding with more sophisticated contents which Updates or Obsoletes this document. Requiring that a Responder ignores the contents would create forward compatibility on the Responder end.

I'm more than happy to propose text if th WG agrees with the above summary :-)

Alex
(from mobile, sorry for brevity and typos)

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 18 Nov 2015 01:53:31 -0500

Alex

Why don't you propose some text, as we have a bandwidth delay product 
with you.

thanks
tim

On 11/17/15 5:30 PM, Alex Mayrhofer wrote:
> - I think we should stick with requiring 0x00 padding (I am avoiding the
> term 'payload' here for a reason). This would prevent the abuse as a
> covert channel, is easily understood and implementable, and should not
> have any significant performance impact during creation of a message.
>
> - In the sense of "be conservative what you send, be liberal what to
> accept" I'm fine to change to text to require (recommend?) a Responder
> to ignore the contents. Which means that a malformed padding will never
> (rarely?) trigger an error response. However, my feeling is that we
> should still allow a "strict Responder" to indicate an error. That boils
> down to text like "a Responder MUST/SHOULD (?) ignore the contents of
> Padding" - I'd go for SHOULD,  and subsequently keep the definition to
> use FORMERR if a strict Responder wishes to indicate an error
>
> - Further, I understand that TLS level compression is discouraged for
> DNS anyways ( I'm not an expert in this field, but that's what I
> understood what dkg said in our initial hallway discussion in Praha), so
> I'd stick with 0x00. If we find out this is really a problem,  we can
> always define a padding with more sophisticated contents which Updates
> or Obsoletes this document. Requiring that a Responder ignores the
> contents would create forward compatibility on the Responder end.
>
>  > On Mon 2015-11-16 16:20:21 -0500 <tel:21 -0500>, Stephen Farrell wrote:

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 18 Nov 2015 01:55:13 -0500

Hi

The Call for Adoption ended and we have strong consensus to adopt the 
document.

The document is also very close to WGLC, once the padding discussion has 
been sussed out.

Thank you all for your comments and reviews.

tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Nov 2015 21:45:51 +0100

On Wed, Nov 18, 2015 at 11:30:53AM +1300,
 Alex Mayrhofer <[email-masked]> wrote 
 a message of 207 lines which said:

> - I think we should stick with requiring 0x00 padding (I am avoiding
> the term 'payload' here for a reason). This would prevent the abuse
> as a covert channel,

-1 for me. I agree with Mark Andrews that "preventing the use as a
covert channel" is a non-goal (you cannot prevent two willing entities
to set up anything as a covert channel).

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 18 Nov 2015 17:11:00 -0500

> to set up anything as a covert channel).

I agree that we can't prevent them, and that it probably doesn't make
sense to allow recipients of non-zero padding to reject the packets.

Consider that a recipient that is not padding-aware will not reject the
packets; having a padding-aware recipient reject them seems like an
extra interop failure.  And as Alex said earlier:

>> If we find out this is really a problem, we can always define a
>> padding with more sophisticated contents which Updates or Obsoletes
>> this document. Requiring that a Responder ignores the contents would
>> create forward compatibility on the Responder end.

So i think that we should still say that a packet sender MUST pad with
all-zeros for this draft, even though a recipient MUST NOT reject a
query or response just because it a non-zero octet in its padding.

In addition to compatibility with future versions, we don't want to
encourage another heartbleed where uninitialized memory goes out on the
wire.  And we don't want to encourage people to leak big chunks of their
raw CSPRNG output to their correspondent.

       --dkg

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Nov 2015 22:44:45 -0500 (EST)

> raw CSPRNG output to their correspondent.

+1

Paul

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Nov 2015 12:07:42 +0200

> to set up anything as a covert channel).

<no hats>
I agree with Stephane here.

If someone wants to use this as a convert channel between e.g: stub
and recursive, they would need some manner to get information into the
padding section when sending, and then extract it on the other end.
This means that they have control of these endpoints, and so do
basically whatever they want. They can hide stuff in the QNAME, they
can stuff it anywhere else in the DNS packet, or they could just use
some other protocol that looks nothing like DNS. This all gets wrapped
in TLS, and so middleboxes / anything other then the sender and
receiver cannot check to see if the padding is being used as a convert
channel, if the stuff looks anything like DNS at all.
Much of this seems like: Don't test for an error condition you don't
know how to handle.

So, I really don't think that the receiver should check this field (a
well behaved receiver will ignore this field, a malicious one isn't
gong to care what we put in an RFC).

I also think (but am not sure) that the sender should pad with random
stuff[0] to prevent issues with "accidental" compression. Yes, we can
say that compression MUST be disabled, but will all implementations
follow this? The way many people write software is "look for something
kind of similar on stackexchange and fiddle with it till it compiles".
None of the easy examples I could find mention compression - e.g:
http://stackoverflow.com/questions/5009271/any-good-examples-on-programming-using-libssl,
https://wiki.openssl.org/index.php/Libcrypto_API, etc.

I suspect I'm in the rough on this.

W
[0]: Massive handwave here.

</no hats>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Alex Mayrhofer <[email-masked]>
Date: Thu, 19 Nov 2015 23:09:50 +1300

Hello,

I agree with stephane that we can't prevent covert channels. I will do a revised draft with what I think is the rough concensus of the WG regarding non-zero padding over the next few days.

Alex

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Nov 2015 13:34:15 -0500

> I suspect I'm in the rough on this.

TLS stacks should be moving to having compression disabled by default --
on both server and client sides.

Packing the padding "random stuff" is likely to be interpreted as "fill
the space with output from your CSPRNG" which itself could cause
problems if your CSPRNG is flawed (e.g. the flawed dual_ec_drbg is more
vulnerable the more of its contiguous output is known).

And this still won't address any additional traffic leakage that could
happen as a result of compression still being enabled (e.g. CRIME-style
attacks where attackers get you to make queries that change the deflate
dictionary).

padding with randomness also fails at the "compatibility with some
potential future padding semantics" goal mentioned above.

          --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Nov 2015 19:16:14 +0000

> potential future padding semantics" goal mentioned above.

In the choice between zero and random padding I'm almost entirely
in the "meh, just pick one and move on" camp, but if forced to
would side with putting in random crap and not zeros. I do think
requiring checking of zeros on the receiver would be wrong.

S.

---

From: "Visweswaran, Gowri" <[email-masked]>
Date: Fri, 20 Nov 2015 16:59:47 +0000

The below issue should apply to DTLS as well as TLS, i.e.,  we should that
compression MUST be disabled for both DTLS and TLS implementations. 
Does it make sense to add a section about this in the DNS over DTLS draft?

Also, the wording in https://tools.ietf.org/html/rfc7525#section-3.3  (pasted below) be changed from SHOULD to MUST and re-worded:

3.3.  Compression

   In order to help prevent compression-related attacks (summarized in
   Section 2.6 of [RFC7457]), implementations and deployments SHOULD
   disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless
   the application protocol in question has been shown not to be open to
   such attacks.

Gowri

-----Original Message-----
From: dns-privacy [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, November 19, 2015 2:16 PM
To: Daniel Kahn Gillmor; Warren Kumari; Stephane Bortzmeyer
Cc: Shane Kerr; Andreas Gustafsson; [email-masked]; Alex Mayrhofer
Subject: Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

On 19/11/15 18:34, Daniel Kahn Gillmor wrote:
>> follow this? The way many people write software is "look for 
>> something kind of similar on stackexchange and fiddle with it till it compiles".
> TLS stacks should be moving to having compression disabled by default 
> -- on both server and client sides.
> 
> Packing the padding "random stuff" is likely to be interpreted as 
> "fill the space with output from your CSPRNG" which itself could cause 
> problems if your CSPRNG is flawed (e.g. the flawed dual_ec_drbg is 
> more vulnerable the more of its contiguous output is known).
> 
> happen as a result of compression still being enabled (e.g. 
> CRIME-style attacks where attackers get you to make queries that 
> change the deflate dictionary).
> 

In the choice between zero and random padding I'm almost entirely in the "meh, just pick one and move on" camp, but if forced to would side with putting in random crap and not zeros. I do think requiring checking of zeros on the receiver would be wrong.

S.

---

From: "Mankin, Allison" <[email-masked]>
Date: Fri, 20 Nov 2015 17:17:21 +0000

This seems like content for the unified TLS/DTLS profiles draft that Sara, Tiru and DKG are now working on.

Sent from my iPhone

> On Nov 20, 2015, at 12:00, Visweswaran, Gowri <[email-masked]> wrote:
> 
> The below issue should apply to DTLS as well as TLS, i.e.,  we should that> compression MUST be disabled for both DTLS and TLS implementations. 
> Does it make sense to add a section about this in the DNS over DTLS draft?> 
>>> I also think (but am not sure) that the sender should pad with random >>> stuff[0] to prevent issues with "accidental" compression. Yes, we can >>> say that compression MUST be disabled, but will all implementations 
>> "fill the space with output from your CSPRNG" which itself could cause >> problems if your CSPRNG is flawed (e.g. the flawed dual_ec_drbg is 
>> And this still won't address any additional traffic leakage that could >> happen as a result of compression still being enabled (e.g.

---

From: "Visweswaran, Gowri" <[email-masked]>
Date: Fri, 20 Nov 2015 18:48:00 +0000

Re Stephen's comment: In the choice between zero and random padding I'm almost entirely in the "meh, just pick one and move on" camp, but if forced to would side with putting in random crap and not zeros. I do think requiring checking of zeros on the receiver would be wrong.

Rather than picking either zero or random, should we allow support for both alternatives?

Gowri

-----Original Message-----
From: dns-privacy [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, November 19, 2015 2:16 PM
To: Daniel Kahn Gillmor; Warren Kumari; Stephane Bortzmeyer
Cc: Shane Kerr; Andreas Gustafsson; [email-masked]; Alex Mayrhofer
Subject: Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?)

S.

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 20 Nov 2015 12:16:19 -1000

On Friday, November 20, 2015 8:48 AM, Visweswaran, Gowri wrote:
>
> Re Stephen's comment: In the choice between zero and random padding I'm
> almost entirely in the "meh, just pick one and move on" camp, but if
forced to
> would side with putting in random crap and not zeros. I do think requiring
> checking of zeros on the receiver would be wrong.
> 
> Rather than picking either zero or random, should we allow support for
both
> alternatives?

Yes.

I agree with Stephane's and Warren's analyses that trying to prevent covert
channels is futile. Let's keep it simple. I am also reluctant to mandate
randomness because this can be a very deep rabbit hole, and is not needed if
the local TLS stack does not do compression.

What about SHOULD send zeroes, MAY send random, MUST NOT look at the
received padding?

-- Christian Huitema

---

From: Alex Mayrhofer <[email-masked]>
Date: Sat, 21 Nov 2015 11:44:09 +1300

As dkg already said, I'm slightly worried that when we say "send random", lazy implementors might simply malloc() the space and send whatever was at that memory position before...

Alex

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 20 Nov 2015 21:29:54 -1000

On Friday, November 20, 2015 12:44 PM, Alex Mayrhofer wrote:
>
> As dkg already said, I'm slightly worried that when we say "send 
> random", lazy implementors might simply malloc() the space and 
> send whatever was at that memory position before...

Yes, this is the "rabbit hole" that I was alluding to. The moment we say "fill it with random values," we can expect an interesting discussion about what that means. Cue your favorite Dilbert or XKCD cartoon.

So maybe we need to be a bit more specific than "MAY send random." 

Something like:

Padding SHOULD be set to zeroes when sending. Application developers who are concerned about misguided lower layer compression MAY instead fill the padding with the output of a cryptographic random number generator. Recipient MUST ignore the received padding.

I understand your concern with lazy developers. But then, if they are really lazy, they will just call memzero and meet the requirement. Knowing that other developers may legitimately send something else than zero will also give teeth to the "must ignore" requirement.
 
-- Christian Huitema

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 23 Nov 2015 12:36:23 +0000

> On 20 Nov 2015, at 17:17, Mankin, Allison <[email-masked]> wrote:
> 

Yes - this recommendation is already in our preliminary document.

Sara.