Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

[Wessels, Duane]

> On Mar 12, 2023, at 8:43 AM, Brian Haberman  wrote:
> 
> All,
> This starts a 2-week WGLC for draft-ietf-dprive-unilateral-probing-05. 
> This call is to determine if the document is sufficiently complete to 
> facilitate implementations and interoperability testing. Once that 
> determination is made, the chairs will park this document in the datatracker 
> with a state of "Waiting for Implementation" and we will await for the 
> requested implementations and interoperability reports.
> 
> The chairs will note that the document is currently marked as Proposed 
> Standard and that there has been a suggestion to move it to Experimental. If 
> you have an opinion on the status at this time, please include it in your 
> feedback to the WG mailing list. We will revisit the status of the document 
> before it gets advanced to our AD.
> 
> This WGLC will end at midnight UTC on March 26, 2023.
> 
> Regards,
> Brian & Tim
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 


My primary concern with this draft is that, as written, it could
be interpreted as a requirement for DNS providers that operate
under contracts that use language such as "shall comply with relevant
existing RFCs".  I'm not sure that was the authors' intention.
For example, section 3 says:

   An authoritative server implementing the protocol described in this
   document MUST implement at least one of DoT or DoQ on port 853.

I can think of a couple ways this guidance could be improved:

1. The document could be split into two separate documents for clients
   and servers, and the server document could be given Experimental status.

2. Clarify that this protocol is optional for servers to deploy.  For example:

   The protocol described in this document is OPTIONAL for authoritative
   servers.  An authoritative server choosing to implement the
   protocol described in this document MUST implement at least one
   of DoT or DoQ on port 853.

Also as a point of semantics, when this document uses "implement"
I think maybe it really means "deploy"?  I've always thought that
implementation is what developers do and deployment is what operators
do.  That is the approach taken with RFCs 7766 (DNS Transport over
TCP - Implementation Requirements) and 9210 (DNS Transport over TCP
- Operational Requirements).

DW

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt]

[Wessels, Duane]

Hi Peter,

While I remain neutral as to whether or not ds-dot-signal-and-pin is a good 
idea overall, you can count me as one that thinks flags=257 is a bad idea.  I 
don't think anything in 403[345] say that flags can be interpreted differently 
depending on the algorithm or on the value of the Zone Signing column.  

The document uses the phrase "DNSKEY algorithm" very often but I think you 
really mean DNS Security Algorithm (or just algorithm).  For example, 

   more than one DS record with DNSKEY algorithm TBD

is better as just

   more than one DS record with algorithm TBD

DW



> On Jul 13, 2020, at 10:16 AM, Peter van Dijk  
> wrote:
> 
> Hello,
> 
> please find below revision -01 of our proposal for enabling DoT from
> resolver to authoritative.
> 
> New in this revision:
> 
> * a lot of clarifying text without changing the underlying protocol
> 
> * the DNSKEY flags field is now specified to be 257 instead of 0. We
> know that this goes against the explicit wishes of some of those who
> commented on -00, but we argue in the document that because our algo
> TBD will have 'Zone Signing=N' in the IANA DNSKEY algo registry, the
> flags do not mean 'ZONE' and 'SEP'. The value 257, meanwhile, is
> believed to go down with registries much easier.
> 
> * we added a 'Design considerations' section that explains how this
> protocol came to be, and why we did not go the TLSA route. You can
> click through to it directly via 
> https://secure-web.cisco.com/1547Nd7TUhQCx--6BXQ2V7Fe6OsN72FFOIoB6X79e4tCF2s3ZpnvtGzBeZ35b3VZublqmT2QWLNxBE-H4UuDLJnh3itcQpBUb6pvqqG91nLQIfZ6JfJk-0nXyuSFLvD9anUSvqQjNwa7usrKjP9E-9zoOj8_4YAfpeb5yetnz5zz6RafsBHm8OG4n_AdFMl89cKxMT7P4a9IwkKlAutHh5GjZM1CDogcPKO6FLJ6QgiE6IYhafhiHX3qtYL2Z_veABcJwEj5EI9_m4VdsUVb3gfMkZPh0RCerOSzBeJ00Eqk/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin-01%23section-9
> 
> Furthermore, we have tried to do a review of this protocol against the
> requirements of the DPRIVE phase 2 document.  You can find this review
> (which might be updated outside of revisions of this draft or the phase
> 2 draft) via 
> https://secure-web.cisco.com/1A25tPS76irHgdA_csUZGhdQB7R1rIbrOg1TW6d07W694zX71PQw1tAqCq4W-Yy-5i2h9ujLnVA3gCvVmF1AQkb04kNBNapCJrd3AIAma9QbnSKK_h65nrwXbi62Ylrxwjlpuook_wYJpyVmdsE3gvLF0fupzhFzjV6ufEXcxtz5FLv5H7STGDYGhD6pmlkXs4s4Ne03z_NV7Y5lT1r-RooYejeWscUws5c7DkEBTF3L_pTOYu_NRH1SA1SAGABwE_uaOR1fq1Gj1BIsI4yBwQw/https%3A%2F%2Fgithub.com%2FPowerDNS%2Fparent-signals-dot%2Ftree%2Fmaster%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin%2Fyardsticks
> 
> We'll be presenting the draft at the IETF108 dprive session.
> 
> Kind regards,
> Manu, Robin & Peter
> 
>  Forwarded Message 
> From: internet-dra...@ietf.org
> To: Robin Geuze , Peter van Dijk <
> peter.van.d...@powerdns.com>, Emmanuel Bretelle 
> Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds-
> dot-signal-and-pin-01.txt
> Date: Mon, 13 Jul 2020 01:47:10 -0700
> 
> A new version of I-D, draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt
> has been successfully submitted by Peter van Dijk and posted to the
> IETF repository.
> 
> Name: draft-vandijk-dprive-ds-dot-signal-and-pin
> Revision: 01
> Title:Signalling Authoritative DoT support in DS records, 
> with key pinning
> Document date:2020-07-13
> Group:Individual Submission
> Pages:14
> URL:
> https://secure-web.cisco.com/1DsK2MVevadXT3GdniFfbtgOI396AfHCVKwwaV2-vAgI7z9Dd0q8NsHHtR5-Yvr8yKxH_PsQUrwCjagVNwgqtbfFNBSLwggZdZvleOtsjhVoeUmEteo8hKdrw77dn5UNKta2PuxqVGaZXwtZvs-4DQaP4xGc7jPUy3_Rl9Vtv_nHj5nYYy0pJo9XXQX5rtZ6xX1eZb29S5H51GbUukAdUD8vkiLEdfM49HeyTI1UBukpyYtaF3GsqY0KDHV7wEEhE_7DCsOfkqajfAZNXedeMR1XYjo04sw1CHYXBLmmkRBg/https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin-01.txt
> Status: 
> https://secure-web.cisco.com/1lJ9HOKB3lcr0FYkKcTfMImWTawCKcgf31T_3MoPvTc9gMCdIA_ajbmqsJ4rIMbt424s-ph7cAAqmJvl7MVr3ebT547Uz7sP9gA7HUHq-Jx2RjBRUFvf_sL64ZKYdT15vGJxq7MpweDRIPtOdTKsKNv-7NgTI_zAHJaHlrnwE3rB6ex-YZqGLp-UKZEns5N_nBOxy5aA_nGhijjVJn4ekYBrw2ZJ2AYXki5uFYvUSkauqxifxZ84Bd__Ltjygp285gciA0joIcrkb8IFNsx7kzw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin%2F
> Htmlized:   
> https://secure-web.cisco.com/1cFirxV4x2U2WbrlVzODCuwJ9pifdlZzpYB3Xq4t0hBEgNekIlAEC-Qthjgvz5EUvGHxGpLRuuJ0NL0AmSAMwJnYwkyUtIROhvZOTM45Ze3dx738rFrs2e_k-8D7glvhyQAD7w2Mjr1A3F3l2fjbaOmBsljJ1LJytf57_udaJAPOpJmsI6Ip1FR1kSyJo4jGWKohWGdfySdd04FQyHE_RzAkfHiIej1GUpf0sGSG1N6W1AGS0JqaP3n_z9B-8bpjygQQkaOVIplt3dkiTwRMmifie6zY8oHApoQ6Zt6MnNUs/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-vandijk-dprive-ds-dot-signal-and-pin-01
> Htmlized:   
> 

Re: [dns-privacy] I-D Action: draft-ietf-dprive-phase2-requirements-01.txt

[Wessels, Duane]

Hi Benno, Alex, and Jason.  I have a few comments and questions about this 
version.  Hopefully these are helpful.

DW



> 5.  Requirements
> 
>   The requirements of different interested stakeholders are outlined
>   below.
> 

Perhaps this is obvious others, but I would like to see a better explanation of 
exactly what kind of requirements these are meant to be.  Are they 
implementation or protocol requirements (versus operational requirements)? Or 
requirements of some other type?

Also, I'm struggling a little bit with "interested stakeholders" above.  I 
don't think these are requirements *on* stakeholders.  Maybe it would be better 
to say something like "[protocol] requirements of different elements are 
outlined below."?


> 5.1.  Mandatory Requirements
> 
>   1.   Each implementing party should be able to independently take
>incremental steps to meet requirements without the need for
>close coordination (e.g. loosely coupled)

If that is a requirement then MUST/must instead of "should"?


>   2.   Use a secure transport protocol between a recursive resolver and
>authoritative servers
> 
>   3.   Use a secure transport protocol between a recursive resolver and
>TLD servers
> 
>   4.   Use a secure transport protocol between a recursive resolver and
>the root servers
 
These were worded a differently in an earlier version.  The following text is 
from draft-lmo-dprive-phase2-requirements-01:


>   2.  Implement DoT between a recursive resolver and single level domain
>   authoritative servers (high risk, high priority)
> 
>   3.  Implement DNS privacy protections between a recursive resolver and
>   TLD servers (low risk, low priority)
> 
>   4.  Implement DNS privacy protections between a recursive resolver and
>   the root servers (low risk, low priority)


I get why DoT was changed in #2, but why was "DNS privacy protections" changed 
to "a secure transport protocol"?  Why were the risk and priority 
classifications removed?

Also, I'm not sure how these are requirements as written (e.g., they lack RFC 
2119 key words).  And, on whom or what are these requirements placed upon?


>   5.   The secure transport MUST only be established when referential
>integrity can be verified, MUST NOT have circular dependencies,
>and MUST be easily analyzed for diagnostic purposes.
> 
 

I think the "MUST NOT have circular dependencies" requirement should be further 
explored (i.e., more text). Since item 9 below says that specification of 
preferences must occur using DNS only, is that itself a circular dependency?

Also, could more be said about the "easily analyzed" part?  "easily" might be 
subjective, unless there is to be some way to quantify this requirement?


>   6.   Use a secure transport protocol or other DNS privacy protections
>in a manner that enables operators to perform appropriate
>performance and security monitoring, conduct relevant research,
>etc.

Again, not sure how this is a requirement or for whom it is a requirement. Does 
it mean something like "use of secure transport protocols MUST NOT prevent 
operators [of xxx] from performing appropriate performance and security 
monitoring, conducting research, etc."? 
 

>   7.   The authoritative domain owner or their administrator MUST have
>the option to specify their secure transport preferences (e.g.
>what specific protocols are supported).  This SHALL include a
>method to publish a list of secure transport protocols (e.g.
>DoH, DoT and other future protocols not yet developed).  In
>addition this SHALL include whether a secure transport protocol
>MUST always be used (non-downgradable) or whether a secure
>transport protocol MAY be used on an opportunistic (not strict)
>basis.
> 
>   8.   The authoritative domain owner or their administrator MUST have
>the option to vary their preferences on an authoritative
>nameserver to nameserver basis, due to the fact that
>administration of a particular DNS zone may be delegated to
>multiple parties (such as several CDNs), each of which may have
>different technical capabilities.

Including that some servers for a domain may use secure transport and others 
may not?

It is common for a given name server to be authoritative for multiple zones. 
Should this document state that a name server can provide secure transport for 
one zone but not another?

 

>   9.   The specification of secure transport preferences MUST be
>performed using the DNS and MUST NOT depend on non-DNS
>protocols.
> 
>   10.  For the secure transport, TLS 1.3 (or later versions) MUST be
>supported and downgrades from TLS 1.3 to prior versions MUST not
>occur.
> 

It seems like #10 should be qualified with something like "For TLS-based 
transports..." since there might be some future secure transport that 

Re: [dns-privacy] Fwd: New Version Notification for draft-hzpa-dprive-xfr-over-tls-01.txt

[Wessels, Duane]

> On Mar 11, 2019, at 7:07 PM, Sara Dickinson  wrote:
> 
> A new draft has been submitted outlining using DNS-over-TLS for zone 
> transfers.
> 

Hi Sara,

I wonder if you would be willing to include a reference to the ZONEMD work
in this draft.  Just as RFC 7858 says that TLS and DNSSEC are independent
and solve different problems, I think it would be good to point out here
that xfr-over-tls is not a substitution for being able to verify the
integrity of zone data as published.

DW



smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Brian Haberman's Yes on draft-ietf-dprive-dns-over-tls-07: (with COMMENT)

[Wessels, Duane]

> On Mar 9, 2016, at 9:19 AM, John Heidemann  wrote:
> 
>>> 
>>> Wrt this comment, I would suggest:
>>> 
>>> Use of port 53 for DNS-over-TLS is prohibited to avoid
>>> complication in selecting use or non-use of TLS,
>>> and to reduce risk of downgrade attacks.
>> 
>>   I missed this follow-up prior to responding to Duane...
>> 
>>   My suggestion is replacing "prohibited" with "not recommended".
>> 
>> No hats here, but I like that.
> 
> I checked in with this text:
> 
>  This recommendation against use of port 53 for DNS-over-TLS
> is to avoid
>  complication in selecting use or non-use of TLS,
>  and to reduce risk of downgrade attacks.
> 
> 
> to avoid the "...not recommended to avoid..." double negative.


Thanks John.  If everyone is okay with that, then I believe we have addressed
all of Brian's comments?

DW


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dns-over-tls-07: (with DISCUSS and COMMENT)

[Wessels, Duane]

> On Mar 9, 2016, at 1:17 PM, Stephen Farrell  wrote:
> 
> 
>> 
>>> 
>>> - 3.2: "make use of trusted a SPKI Fingerprint pinset" needs to be
>>> rephrased.
>> 
>> Do you say that because SPKI is not spelled out at this point, or
>> something else?  We've since expanded SPKI here.
> 
> No "trusted a SPKI" seems like Yoda-speak is all:-)

Okay, wow... I must've read that at least five times today and not noticed.


> 
>> 
>>> 
>>> - 3.4, 2nd last para: this recommends using tickets (RFC5077), which
>>> is fine. RFC7525 (section 3.4) suggests changing tickets at least
>>> weekly. Is that suggestion also good here or would it be better to
>>> recommend (or suggest) some other ticket lifetime? I'd guess 
>>> it's fine but maybe you know better?
>> 
>> Ticket lifetime hasn't come up before, so I would assume the RFC7525
>> recommendation is fine.
>> 
>> 
>>> 
>>> - 4.1, RFC 7435 is about "opportunistic security" and not about
>>> "opportunistic encryption." That followed a long terminology debate,
>>> so you might want to s/encryption/security/ there. (But I don't care
>>> personally:-)
>> 
>> I've changed it to opportunistic encryption.
> 
> It was that before, though. Maybe you did s/encryption/security/
> which'd be fine.

Yes, sorry!

   
 
   For opportunistic privacy, analogous to SMTP opportunistic
-  encryption  one does not require privacy,
+  security , one does not require privacy,
  but one desires privacy when
   possible.
 



>> 
>> How does this look to you?
>> 
>>   Since
>>   padding of DNS messages is new, implementations might need to
>>   support multiple types of padding or other mitigation techniques
>>   in response to traffic analysis threats.
> 
> I'd suggest instead:
> 
> "Since traffic analysis can be based on many kinds of pattern
> and many kinds of classifier, simple padding schemes may not
> by themselves be sufficient to mitigate the attack. Padding
> will however form a part of more complex mitigations for the
> traffic analysis attack that are likely to be developed over
> time. Implementers who can offer flexibility in terms of how
> padding can be used may be in a better position to enable such
> mitigations to be deployed in future."


Excellent, thank you.

DW


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Brian Haberman's Yes on draft-ietf-dprive-dns-over-tls-07: (with COMMENT)

[Wessels, Duane]

Hi Brian,


> On Mar 8, 2016, at 7:38 AM, Brian Haberman  wrote:
> 
> 
> I am a definite Yes on this work, but just have a couple of comments...
> 
> * Section 3.1 says "By mutual agreement with its server, the client MAY,
> instead, use a port other than port 853 for DNS-over-TLS.  Such an other
> port MUST NOT be port 53..." It would be useful to *briefly* explain the
> MUST NOT. If it is by mutual agreement, what's the harm?

This text was recently added during a review of 5966bis (DNS-over-TCP)
where there was a concern that neither that nor this document said anything
about not mixing cleartext and ciphertext.

I suppose another reason is that middleware boxes might want to "inspect"
port 53 and TLS over port 53 will fail.

Would you be okay with adding this sentence or similar?  

   Use of port 53 for DNS-over-TLS is prohibited
   because mixing cleartext and ciphertext can result in false privacy.



> 
> * Section 3.2 uses the SPKI acronym before it is expanded in section
> 4.2.

Fixed.


> 
> * I do not understand the last sentence of section 3.2, especially the
> "SHOULD".


You are referring to this sentence:

 At this point, normal DNS queries SHOULD take place.

I believe it is sort of an artifact from the time when the draft included
a "STARTTLS for DNS" option whereby an unencrypted TCP connection could
be upgraded.  Dropping the sentence is fine with me.  

DW
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Fwd: [DNSOP] Confusing title of draft-ietf-dprive-dns-over-tls

[Wessels, Duane]

The message below was sent to dnsop rather than dprive.  Myself and coauthor 
Paul Hoffman agree that the
proposed title "Specification for DNS over TLS" better matches the current 
document.  

With the permission of the chairs and the working group I will update the 
document title.

DW

> Begin forwarded message:
> 
> From: Paul Wouters 
> Subject: [DNSOP] Confusing title of draft-ietf-dprive-dns-over-tls
> Date: February 17, 2016 at 3:10:37 PM PST
> To: dnsop 
> 
> 
> While looking up a reference for the "DNS over TLS" document, I stumbled
> upon draft-ietf-dprive-dns-over-tls which is titled:
> 
> "DNS over TLS: Initiation and Performance Considerations"
> 
> Since I was not looking for initiation or performance details, I kept
> lookig for the DNS over TLS draft. After some failing, I realised that
> this rather confusingly titled doument is the one I am looking for.
> 
> Please retitle this doument :)
> 
> Perhaps "Specification for DNS over TLS" or something ?
> 
> Paul
> 
> ___
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-05.txt

[Wessels, Duane]

Hello All,

This update to draft-ietf-dprive-dns-over-tls adds an informative
reference to DNSCrypt as suggested by Stephane Bortzmeyer.  My apologies
for missing it earlier Stephane!

DW


> On Jan 22, 2016, at 1:35 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the DNS PRIVate Exchange Working Group of the 
> IETF.
> 
>Title   : DNS over TLS: Initiation and Performance 
> Considerations
>Authors : Zi Hu
>  Liang Zhu
>  John Heidemann
>  Allison Mankin
>  Duane Wessels
>  Paul Hoffman
>   Filename: draft-ietf-dprive-dns-over-tls-05.txt
>   Pages   : 19
>   Date: 2016-01-22
> 
> Abstract:
>   This document describes the use of TLS to provide privacy for DNS.
>   Encryption provided by TLS eliminates opportunities for eavesdropping
>   and on-path tampering with DNS queries in the network, such as
>   discussed in RFC 7258.  In addition, this document specifies two
>   usage profiles for DNS-over-TLS and provides advice on performance
>   considerations to minimize overhead from using TCP and TLS with DNS.
> 
>   Note: this document was formerly named
>   draft-ietf-dprive-start-tls-for-dns.  Its name has been changed to
>   better describe the mechanism now used.  Please refer to working
>   group archives under the former name for history and previous
>   discussion.  [RFC Editor: please remove this paragraph prior to
>   publication]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dns-over-tls-05
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

[Wessels, Duane]

> On Oct 22, 2015, at 6:59 PM, Bob Harold  wrote:
> 
> The URL is not working for me, and I cannot find a working URL.  Is it just 
> me?


Try this:

https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-01.txt

[Wessels, Duane]

I'd like to thank everyone who provided reviews and input to the DNS-over-TLS 
document.
The -01 revision has been uploaded with the following changes since -00:

- Request for early port allocation was granted.  The document now refers to 
port 853.

- Clarified that TLS also help with on-path tampering.

- Clarified language about writing two-octet length field (matching 
draft-5966bis)

- Removed "port number" in description of matching queries to responses.

- Mention getaddrinfo() in addition to gethostbyname().

- Removed reference to RFC3118 under advice that it is not used and may be 
deprecated.

- Removed questionable use of the term "pinning".

- Clarified that unencrypted queries and responses might happen over port 53 
prior to
  TLS.

DW


> On Oct 11, 2015, at 9:21 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the DNS PRIVate Exchange Working Group of the 
> IETF.
> 
>Title   : DNS over TLS: Initiation and Performance 
> Considerations
>Authors : Zi Hu
>  Liang Zhu
>  John Heidemann
>  Allison Mankin
>  Duane Wessels
>  Paul Hoffman
>   Filename: draft-ietf-dprive-dns-over-tls-01.txt
>   Pages   : 17
>   Date: 2015-10-11
> 
> Abstract:
>   This document describes the use of TLS to provide privacy for DNS.
>   Encryption provided by TLS eliminates opportunities for eavesdropping
>   and on-path tampering with DNS queries in the network, such as
>   discussed in RFC 7258.  In addition, this document specifies two
>   usage profiles for DNS-over-TLS and provides advice on performance
>   considerations to minimize overhead from using TCP and TLS with DNS.
> 
>   Note: this document was formerly named
>   draft-ietf-dprive-start-tls-for-dns.  Its name has been changed to
>   better describe the mechanism now used.  Please refer to working
>   group archives under the former name for history and previous
>   discussion.  [RFC Editor: please remove this paragraph prior to
>   publication]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dns-over-tls-01
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] review of draft-ietf-dprive-dns-over-tls

[Wessels, Duane]

John,

> On Oct 1, 2015, at 9:21 PM, John Levine  wrote:
> 
> I think it's in pretty good shape but of course I have a few questions.
> 
> In 3.3, it says to match queries and responses "using the ID field and
> port number".  I get the ID field, but the port number?  In a TCP
> session?  This language appears to be copied from 5966bis, where it
> seems to have been copied by mistake from something that was talking
> about UDP.  It's not in RFC 5966.

Already fixed, as you already know...


> 
> In the opportunistic privacy profiles in 4.1, why wouldn't you want to
> use opportunistic TLS when talking to an authoritative server the same
> as you would talking to a cache?  The example suggests it only applies
> to caches.

Because the working group is focused on stub-to-recursive that is what
the document authors focused on as well.  

> 
> In the security considerations, item 3 appears to be left over from
> the STARTTLS version.  If the handshake happens at the beginning, how
> could there be protocol interactions prior to the handshake?

Here's the text:

3.  Any protocol interactions prior to the TLS handshake are
   performed in the clear and can be modified by a person-in-the-
   middle attacker.  For this reason, clients MAY discard cached
   information about server capabilities advertised prior to the
   start of the TLS handshake.

The authors debated about leaving this in or taking it out.

The argument for leaving it is that a client might not use TLS
immediately, for whatever reason.  If it performs normal queries
before using TLS then the client might want to discard anything it
learned about servers.  That might include RTT estimates, EDNS support, etc.

If there is consensus that its better to remove that paragraph, we would
be happy to do so.

DW


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Please review documents...

[Wessels, Duane]

> On Oct 2, 2015, at 11:23 AM, 神明達哉  wrote:
> 
> At Wed, 23 Sep 2015 10:32:05 -0400,
> Warren Kumari  wrote:
> 
>> Please review our documents:
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
> 
> I've reviewed the 00 version of draft-ietf-dprive-dns-over-tls.  I
> didn't see any substantial issues, so it seems to me almost ready to
> ship.  (But I don't think I can claim to be a TCP or TLS or security
> expert, so my review is more or less superficial anyway).
> 
> For the record I agreed with what Stephane Bortzmeyer complained about
> in his review.
> 
> I have a couple of more minor comments and one editorial nit:
> 
> - Section 3.3
> 
>   For reasons of efficiency, DNS clients and servers SHOULD
>   transmit the two-octet length field, and the message described by
>   that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis],
>   Section 8).
> 
>  I pointed out that 'in a single TCP segment' is not realistic for my
>  review on 5966bis, and in my understanding this sentence has been
>  revised.  This draft will also have to make corresponding updates.

Thanks, this has been updated:

@@ -380,7 +380,10 @@
   .
   For reasons of efficiency, DNS clients and servers SHOULD
   transmit the two-octet length field, and the message
-  described by that length field, in a single TCP segment
+  described by that length field, to the TCP layer at the
+  same time (e.g., in a single "write" system call) to make
+  it more likely that all the data will be transmitted in
+  a single TCP segment
   (, Section 8).

> 


> - Section 4.2
> 
>   Methods for pre-deployment of the designated DNS provider are outside
>   the scope of this document.  In corporate settings, such information
>   may be provided at system installation, for instance within the
>   authenticated DHCP exchange [RFC3118].
> 
>  In my understanding no one ever seriously used RFC3118 (or
>  RFC3315)-style DHCP authentication.  In fact, the dhc wg is now even
>  going to deprecate the original RFC3315-based authentication in a
>  bis document.  So, even with 'for instance', referring to this
>  particular authentication mechanism seems to be too unrealistic.  If
>  there's a better and more practical example (which I don't know), I
>  suggest replacing the example with that one; otherwise, I'd rather
>  suggest removing the "for instance...[RFC3118]'.

Fine with me and not hearing any other comments, I've removed it as you
suggested:

@@ -543,8 +545,7 @@
 
   Methods for pre-deployment of the designated DNS provider are
   outside the scope of this document.  In corporate settings,
-  such information may be provided at system installation, for 
instance within
-  the authenticated DHCP exchange . 
+  such information may be provided at system installation.

> 


> - Section 9: a minor nit: s/be//?
> 
>   2.  Middleboxes [RFC3234] are be present in some networks and have

Thanks!

DW


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] review of draft-ietf-dprive-dns-over-tls

[Wessels, Duane]

> On Oct 9, 2015, at 3:44 PM, John R Levine  wrote:
> 
>> Here's the text:
>> 
>> 3.  Any protocol interactions prior to the TLS handshake are
>>  performed in the clear and can be modified by a person-in-the-
>>  middle attacker.  For this reason, clients MAY discard cached
>>  information about server capabilities advertised prior to the
>>  start of the TLS handshake.
>> 
>> The authors debated about leaving this in or taking it out.
>> 
>> The argument for leaving it is that a client might not use TLS
>> immediately, for whatever reason.  If it performs normal queries
>> before using TLS then the client might want to discard anything it
>> learned about servers.  That might include RTT estimates, EDNS support, etc.
> 
> If the TLS stuff is on a separate port that only does TLS, what could 
> possibly happen before the TLS handshake?


I'm suggesting that a query/response on port 53 might happen prior to TLS.

DW


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-00.txt

[Wessels, Duane]

> On Oct 2, 2015, at 1:09 AM, Simon Josefsson  wrote:
> 
>>> I believe the abstract or introduction section should mention that
>>> TLS gives you data integrity services, which protects against
>>> on-path tampering.  Right now the document talks about encryption
>>> to protect against eavesdropping.  However, the RFC 7258 pervasive
>>> monitoring attack includes active attacks and thus I believe
>>> talking about integrity is useful to set the context right.
>> 
>> I've added a short sentence to the abstract:
>> 
>> @@ -169,7 +169,9 @@
>> This document describes the use of TLS to provide privacy
>> for DNS.  Encryption provided by TLS eliminates opportunities
>> for eavesdropping on DNS queries in the network, such as
>> -discussed in RFC 7258.  In addition, this document specifies
>> +discussed in RFC 7258.
>> +TLS also protects against on-path tampering.
>> +In addition, this document specifies
>> two usage profiles for DNS-over-TLS and provides advice on
>> performance considerations to minimize overhead from using
>> TCP and TLS with DNS.
> 
> Hi Duane.  Thank you.  7258 also talks about active attacks.  So
> maybe it reads better to say:
> 
>  Encryption provided by TLS eliminates opportunities for eavesdropping
>  and on-path tampering with DNS queries in the network, such as
>  discussed in RFC 7258.


Thanks, this change has been made.

DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Please review documents...

[Wessels, Duane]

> On Sep 30, 2015, at 5:05 PM, Watson Ladd  wrote:
> 
> On Wed, Sep 23, 2015 at 10:32 AM, Warren Kumari  wrote:
>> Hi all,
>> 
>> Please review our documents:
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/
>> 
>> We would like to see a significant amount of review and discussion before
>> our meeting in Yokohama - if not it is hard to justify the meeting time.
>> 
>> I put in the request for early port allocation few days back...
> 
> Is "pining" really the right term for recording which resolvers
> support DNS? When I've seen pinning used it has been in the context of
> certificates, with pining involving remembering which certificate was
> used.

Watson,

I think that is a fair point and I've made the following change:

@@ -787,8 +787,8 @@
 Clients and
 servers MUST adhere to the TLS implementation recommendations
 and security considerations of .
-DNS clients keeping track of servers known to support TLS (i.e.,
-"pinning") enables clients to detect downgrade attacks.
+DNS clients keeping track of servers known to support TLS
+enables clients to detect downgrade attacks.
 For servers with no connection history and no apparent
 support for TLS, clients depending on their Privacy
 Profile and privacy requirements may choose to (a) try another 
server when



> We don't seem to have a good deal to say about authenticating DNS resolvers.

Yes, and we are acknowledging such as out of scope for this document.


DW


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] review of draft-ietf-dprive-dns-over-tls

[Wessels, Duane]

> On Oct 9, 2015, at 4:33 PM, John R Levine  wrote:
> 
>>> If the TLS stuff is on a separate port that only does TLS, what could 
>>> possibly happen before the TLS handshake?
>> 
>> I'm suggesting that a query/response on port 53 might happen prior to TLS.
> 
> Oh, OK.  It'd help if the text mentioned that.
> 

John, how does this look to you?

-Any protocol interactions prior to the TLS handshake are
-performed in the clear and can be modified by a 
person-in-the-middle
-attacker.  For this reason, clients MAY discard cached
+Any DNS protocol interactions prior to the TLS handshake that are
+performed in the clear can be modified by a person-in-the-middle
+attacker.  For example, unencrypted queries and responses
+might take place over port 53 between a client and server
+prior to TLS.  For this reason, clients MAY discard cached
 information about server capabilities advertised prior to
 the start of the TLS handshake.


DW
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-00.txt

[Wessels, Duane]

Simon,


> On Sep 21, 2015, at 2:58 AM, Simon Josefsson <si...@josefsson.org> wrote:
> 
> "Wessels, Duane" <dwess...@verisign.com> writes:
> 
>> The former draft described two approaches to establishing a
>> DNS-over-TLS session: upgrade-based (aka STARTTLS for DNS) and
>> port-based.  In this new version we have removed the upgrade-based
>> approach and describe only the use of a well-known port.
> 
> Yay, thank you!
> 
> I believe the abstract or introduction section should mention that TLS
> gives you data integrity services, which protects against on-path
> tampering.  Right now the document talks about encryption to protect
> against eavesdropping.  However, the RFC 7258 pervasive monitoring
> attack includes active attacks and thus I believe talking about
> integrity is useful to set the context right.

I've added a short sentence to the abstract:

@@ -169,7 +169,9 @@
 This document describes the use of TLS to provide privacy
 for DNS.  Encryption provided by TLS eliminates opportunities
 for eavesdropping on DNS queries in the network, such as
-discussed in RFC 7258.  In addition, this document specifies
+discussed in RFC 7258.
+TLS also protects against on-path tampering.
+In addition, this document specifies
 two usage profiles for DNS-over-TLS and provides advice on
 performance considerations to minimize overhead from using
 TCP and TLS with DNS.


> One comment/thought around the /etc/service name 'domain-s'.  I find it
> undescriptive and difficult to type.  How about 'dnsovertls' or
> something more descriptive?

This has already been discussed and the IANA Ports Review team has provided
guidance that the -s suffix is preferred:

https://mailarchive.ietf.org/arch/msg/dns-privacy/dO99_jjoBUrHS2hCNDKTNRlBLFo

DW

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Please review documents...

[Wessels, Duane]

Hello Ilari,


> On Sep 30, 2015, at 12:23 PM, Ilari Liusvaara  
> wrote:
> 
> 
> DNS-over-TLS (-00):
> 
> 1) Section 3.2:
> 
> Is the section about authentication just examples or is it missing
> stuff like pinning RPK of the server?

I don't feel that section 3.2 is missing anything.  Pinning is mentioned
later in the Security Considerations section.

> 
> Also, DNS servers are usually designated by IP, but certificates
> work by domain name...

The subject of a certificate can be a domain name or an IP address, and there
are other ways of establishing trust of a server certificate.

> 
> 2) Section 3.3:
> 
> I presume each request or reply SHOULD also be inside just one
> TLS record (but multiple queries/responses can be combined into
> a single one)?

I think you're saying that a DNS message shouldn't be split between
multiple TLS records.   Is that because of performance or security reasons?
And do applications generally have that level of control over TLS?

DW

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-00.txt

[Wessels, Duane]

Hi Stephane,

Does this change address your concerns?

diff --git a/draft-ietf-dprive-dns-over-tls.xml 
b/draft-ietf-dprive-dns-over-tls.xml
index a0ae144..a40cec8 100644
--- a/draft-ietf-dprive-dns-over-tls.xml
+++ b/draft-ietf-dprive-dns-over-tls.xml
@@ -394,7 +394,7 @@
  
  Since pipelined responses can arrive out-of-order, clients
  MUST match responses to outstanding queries using the ID
- field and port number.  Failure by clients to properly
+ field, query name, type, and class.  Failure by clients to properly
  match responses to outstanding queries can have serious
  consequences for interoperability (, Section 7).
@@ -403,7 +403,7 @@
 
   
 
-  For DNS clients that use library functions such as "gethostbyname()",
+  For DNS clients that use library functions such as "getaddrinfo()" 
and "gethostbyname()",
   current implementations are known to open and close TCP connections 
each DNS
   call.  To avoid excess TCP connections, each with a single query,
   clients SHOULD reuse a single TCP connection to the



> On Sep 21, 2015, at 7:48 AM, Stephane Bortzmeyer  wrote:
> 
> On Fri, Sep 18, 2015 at 05:03:58PM -0400,
> Warren Kumari  wrote 
> a message of 97 lines which said:
> 
>> We would appreciate it if the WG could do a careful review of this
>> document and point out the issues, inconsistencies, errors and
>> omissions.
> 
> I did not find a serious problem. I have one question and one
> criticism.
> 
>> Since pipelined responses can arrive out-of-order, clients MUST
>> match responses to outstanding queries using the ID field and port
>> number.
> 
> I do not understand how this works. All replies on a given TCP
> connection will have the same source port (the new well-known port)
> and the same destination port (the one used to open the TCP
> connection). So, how do you use the port number for demultiplexing?
> Why not using the QNAME instead? (The query ID may be unsufficient if
> there are a lot of outstanding queries + the birthday paradox.)
> 
>> For DNS clients that use library functions such as
>> "gethostbyname()",
> 
> This was replaced by a better function in RFC 2133, in 1997...
> 



smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dns-over-tls-00.txt

[Wessels, Duane]

This is an update to the draft formerly named 
draft-ietf-dprive-start-tls-for-dns-01.  If searching mail archives for 
previous discussion of this draft you may need to use the former name.

The former draft described two approaches to establishing a DNS-over-TLS 
session: upgrade-based (aka STARTTLS for DNS) and port-based.  In this new 
version we have removed the upgrade-based approach and describe only the use of 
a well-known port.

The URL below will show the differences between this and the previous document.

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dprive-start-tls-for-dns-01.txt=https://tools.ietf.org/id/draft-ietf-dprive-dns-over-tls-00.txt

DW




> On Sep 18, 2015, at 1:21 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the DNS PRIVate Exchange Working Group of the 
> IETF.
> 
>Title   : DNS over TLS: Initiation and Performance 
> Considerations
>Authors : Zi Hu
>  Liang Zhu
>  John Heidemann
>  Allison Mankin
>  Duane Wessels
>  Paul Hoffman
>   Filename: draft-ietf-dprive-dns-over-tls-00.txt
>   Pages   : 17
>   Date: 2015-09-18
> 
> Abstract:
>   This document describes the use of TLS to provide privacy for DNS.
>   Encryption provided by TLS eliminates opportunities for eavesdropping
>   on DNS queries in the network, such as discussed in RFC 7258.  In
>   addition, this document specifies two usage profiles for DNS-over-TLS
>   and provides advice on performance considerations to minimize
>   overhead from using TCP and TLS with DNS.
> 
>   Note: this document was formerly named
>   draft-ietf-dprive-start-tls-for-dns.  Its name has been changed to
>   better describe the mechanism now used.  Please refer to working
>   group archives under the former name for history and previous
>   discussion.  [RFC Editor: please remove this paragraph prior to
>   publication]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-00
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy



smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Early port allocation request for dns-over-TLS

[Wessels, Duane]

 On Aug 17, 2015, at 6:42 AM, Warren Kumari war...@kumari.net wrote:
 
 On Tue, Aug 11, 2015 at 2:00 PM, Joe Touch to...@isi.edu wrote:
 
 Hi, Warren,
 
 It might be useful to summarize on this list the rationale for this
 allocation and the plan for its use.
 
 In particular:
 
- why port 53 is not sufficient using STARTTLS
 
 
 - The WG decided that using a new port instead of a STARTTLS or
 octet-matching would better suite our operational goals.
 We had significant discussions on this, and we have concerns about
 things like middle boxes reacting to non-DNS on 53.

Additionally:

- A separate port avoids the 1xRTT incurred by STARTTLS negotiation.

- DNS-over-DTLS can't use STARTTLS (at least not as currently described), 
although
it does claim that it can run on port 53.  That relies on an unaware server
mis-interpreting a DTLS ClientHello message as a DNS message with Opcode=15.  
That,
in turn, takes Opcode 15 off the table for future allocation, etc.


DW

smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Anycast and TCP-based DPRIVE queries

[Wessels, Duane]

 On Apr 22, 2015, at 10:15 AM, Dan Wing dw...@cisco.com wrote:
 
 One issue brought up by Phillip Hallam-Baker during the Dallas meeting was 
 anycast.  With any approach encrypting the query, the server needs the 
 cryptographic context to decrypt the query.  Transferring that cryptographic 
 context from the other anycasted server is difficult at scale, so instead the 
 client needs to establish cryptographic context with the new (current) 
 anycast server.  (With DNS over TLS over TCP, the TCP state would need to be 
 transferred, too.)   When a DNS over TLS over TCP query is sent to a new 
 (anycasted) server, that TCP packet will often -- but not always -- elicit a 
 TCP RST from the server and that TCP RST would cause the DPRIVE client to 
 initiate a new handshake.  However, if the TCP already has synchronized state 
 with that same TCP port and same source IP address, and receives a bogus TCP 
 packet, it will send an empty acknowledgement, 
 https://tools.ietf.org/html/rfc793#page-37,
 
  3.  If the connection is in a synchronized state (ESTABLISHED,
   FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
   any unacceptable segment (out of window sequence number or
   unacceptible acknowledgment number) must elicit only an empty
   acknowledgment segment containing the current send-sequence number
   and an acknowledgment indicating the next sequence number expected
   to be received, and the connection remains in the same state.
 
 That empty acknowledgement is received by the DPRIVE client but not reported 
 to the application, so the DPRIVE client would have to time out the query.  I 
 don't know how often we might encounter the synchronized state problem -- its 
 frequency occurrence depends on things like:
 * how often anycast causes a new DNS server to be selected for a particular 
 DPRIVE client
 * how long the TCP connection is kept around on anycasted DNS servers,
 * how frequently an IP address is re-assigned (irrespective of NAT or NAPT)
 * TCP port re-use because of address sharing (such as A+P [RFC6346]) and 
 because of NAPT, especially bulk-port allocation popular on CGNs.
 
 Perhaps this is infrequent enough that the typical ~3 second timeout will be 
 good enough to catch it.

Hello Dan,

Anyone deploying TCP anycast service should certainly be aware of these state 
issues, so its good to raise them.

However, in my opinion this perfect storm of conditions you describe 
(established connection, routing change, same IP, same port) will be so 
uncommon that it will be lost in the noise of all the other things that can 
lead to clients retrying their queries.  By other things, I'm thinking of 
packet loss, funky middleboxes, implementation bugs, crashes, bitflips, and so 
on.

DW

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy