Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
Bob https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/ is a working URL thanks for pointing that out tim On 10/22/15 6:59 PM, Bob Harold wrote: On Thu, Oct 22, 2015 at 5:23 AM, Warren Kumari> wrote: Dear DPRIVE WG, The authors of draft-ietf-dprive-dns-over-tls-01 have indicated that they believe that the document is ready, and have asked for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls-01/ Please review this draft to see if you think it is ready for publication and send comments to the DPRIVE list, clearly stating your view. We have chosen to run this WGLC during the IETF meeting, and have it end after the meeting. This will allow us use meeting time to discuss contentious WGLC issues (if any). This will be a 3 week WGLC, and ends Thu 12-Nov-2015. To satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): Are you personally aware of any IPR that applies to draft-ietf-dprive-dns-over-tls-01? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as DPRIVE WG co-chair) The URL is not working for me, and I cannot find a working URL. Is it just me? -- Bob Harold ___ 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
> On Oct 22, 2015, at 6:59 PM, Bob Haroldwrote: > > 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] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
On Thu, Oct 22, 2015 at 2:05 PM, Wessels, Duanewrote: > > > 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/ > > Thanks Tim and Duane, looks good to me. -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review
This is an interesting idea, a few comments: 1. In section 2 it sounds as though you are suggesting that the new RR containing the encryption key needs to be published in the parent zone. Why not publish this as a RR at the apex of the zone with whose name servers you want to encrypt? The advantage to putting encryption keys in the zone rather than the parent is that you create less work for registrars who already seem to really struggle with providing a way to publish DS/DNSKEY records. 2. The fallback to reverse DNS takes an optimistic view of reverse DNS. Most hosting providers will not grant permission to customers to publish in the reverse DNS for net blocks that they manage. 3. I like the idea of leaving the DNS packets mostly in tact - I think this is more likely to survive transit through middle boxes that might want to do some simple packet inspection to see whether the DNS is being used for something other than DNS. This is in fact the same idea that Wouter Wijngaards and I proposed in the confidential DNS draft. 4. Section 3.1.1 specifies an applicable NS name. It is not clear to me why I would want this field. Wouldn't it be more consistent with the current mode of operation of the DNS to determine this using the DNS hierarchy? A zone operator would publish an NSK at the owner name for the NS to which it applies. 5. I would recommend choosing a different name for the new RR as Name Server Key could create confusion to folks learning about the various key records in the DNS. What about something like NSENCK - Name Server Encryption Key? 6. Failure modes could use some attention. It would be useful to distinguish cases where a decrypt fails due to a wrong key versus a format error, unsupported encryption scheme , etc. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 10/19/15, 3:58 PM, "Witold Kręcicki"wrote: >Hi all, > >I've just posted an updated version of Stateless DNS Encryption draft, >it still has holes and unaswered questions but it's now almost >implementable. > >I'd really appreciate if the group could read and comment on it. > >Witold Kręcicki > > >A new version of I-D, draft-krecicki-dprive-dnsenc-01.txt >has been successfully submitted by Witold Krecicki and posted to the >IETF repository. > >Name: draft-krecicki-dprive-dnsenc >Revision: 01 >Title: Stateless DNS Encryption >Document date: 2015-10-19 >Group: Individual Submission >Pages: 15 >URL: >https://www.ietf.org/internet-drafts/draft-krecicki-dprive-dnsenc-01.txt >Status: >https://datatracker.ietf.org/doc/draft-krecicki-dprive-dnsenc/ >Htmlized: >https://tools.ietf.org/html/draft-krecicki-dprive-dnsenc-01 >Diff: >https://www.ietf.org/rfcdiff?url2=draft-krecicki-dprive-dnsenc-01 > >Abstract: > The DNS is the last common Internet protocol that has no encryption > scheme and therefore provides no privacy to the users. This document > proposes an extensible mechanism providing encryption of DNS queries > and responses with method for secure retrieval and verification of > validity of encryption keys. It is independent of the underlying > transport protocol. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > >___ >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] draft-krecicki-dprive-dnsenc-01 - call for review
On 10/22/15, 9:15 AM, "Witold Kręcicki"wrote: >W dniu 22.10.2015 o 15:04, Wiley, Glen pisze: >> On 10/22/15, 8:18 AM, "Witold Kręcicki" wrote: >> >> >>> W dniu 22.10.2015 o 13:44, Wiley, Glen pisze: This is an interesting idea, a few comments: 1. In section 2 it sounds as though you are suggesting that the new RR containing the encryption key needs to be published in the parent zone. Why not publish this as a RR at the apex of the zone with whose name servers you want to encrypt? The advantage to putting encryption keys in the zone rather than the parent is that you create less work for registrars who already seem to really struggle with providing a way to publish DS/DNSKEY records. >>> Because that would require an unencrypted query to the zone NS to get >>> the zone key - and that would be a huge leak of information (as an >>> attacker would know that a victim is looking for something in >>> wikileaks.org, probably www.wikileaks.org). I know that putting the >>>keys >>> at the delegation point is going to be much harder to implement in real >>> world but as an alternative is compromising privacy - it's the only >>> proper way. >> >> This is a great opportunity to not let the best become the enemy of >>better. >> The parent could be a preferred location rather than the only location. >That is an option, but I'm afraid that if this becomes an option then no >operator will allow putting NSK at delegation point... It is often the case that when a technology attempts to impose the best option rather than provide a bridge or progressive path to adoption that it may simply not be adopted. I would like to see your idea refined and tuned up so that it can move forward and I think it would be a shame to create this obstacle to adoption. > >> Passive monitoring would see a query go to the NS IP of the zone in >> question >> anyway so you don't really loose much privacy by publishing the key at >>the >> NS owner label. You are still able to encrypt queries that include a >> delegation. >In most cases NSes are shared (I always wanted to use wikileaks.org, but >it's a bad example here ;) ) so information that a specific IP is >queried is only revealing that a victim might be querying one of the >domains that are hosted on a specific NS (and attacker usually doesn't >have the full list). > > >Witold Krecicki ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review
W dniu 22.10.2015 o 13:44, Wiley, Glen pisze: > This is an interesting idea, a few comments: > > 1. In section 2 it sounds as though you are suggesting that the new RR > containing the encryption key needs to be published in the parent zone. > Why not publish this as a RR at the apex of the zone with whose name > servers you want to encrypt? The advantage to putting encryption keys in > the zone rather than the parent is that you create less work for > registrars who already seem to really struggle with providing a way to > publish DS/DNSKEY records. Because that would require an unencrypted query to the zone NS to get the zone key - and that would be a huge leak of information (as an attacker would know that a victim is looking for something in wikileaks.org, probably www.wikileaks.org). I know that putting the keys at the delegation point is going to be much harder to implement in real world but as an alternative is compromising privacy - it's the only proper way. > 2. The fallback to reverse DNS takes an optimistic view of reverse DNS. > Most hosting providers will not grant permission to customers to publish > in the reverse DNS for net blocks that they manage. This approach is mostly for recursive servers - and those as mostly managed by owners of the net block. An alternative for recursive servers is a hardcoded key in eg. /etc/resolv.conf. The question if this should be a fallback for auth servers is open for discussion, I've already heard voices that it's not a good idea and I'm not insisting on it. > 4. Section 3.1.1 specifies an applicable NS name. It is not clear to me > why I would want this field. Wouldn't it be more consistent with the > current mode of operation of the DNS to determine this using the DNS > hierarchy? A zone operator would publish an NSK at the owner name for the > NS to which it applies. My goal was to allow two different keysets for a domain in case its nameservers are operated by different entities, so that domain owner doesn't have to share his keys with SNS (and so that a SNS can use small amount of keys, and not different key for every domain it hosts), eg: example.com IN NS ns1.provider1.com example.com IN NS ns2.provider1.com example.com IN NS ns.provider2.com example.com IN NSK ... *.provider1.com ... example.com IN NSK ... *.provider2.com ... > 5. I would recommend choosing a different name for the new RR as Name > Server Key could create confusion to folks learning about the various key > records in the DNS. What about something like NSENCK - Name Server > Encryption Key? I'm open to propositions, I had an opinion that DNSENC is to similiar to DNSSEC so I've changed the name to DNSCRYPT just to get a message that it is already commonly used so I'm back to DNSENC. > 6. Failure modes could use some attention. It would be useful to > distinguish cases where a decrypt fails due to a wrong key versus a format > error, unsupported encryption scheme , etc. Agree, that's an early version of draft and I was focused mostly on describing the general idea, not getting into details. Witold Kręcicki ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review
On 10/22/15, 8:18 AM, "Witold Kręcicki"wrote: >W dniu 22.10.2015 o 13:44, Wiley, Glen pisze: >> This is an interesting idea, a few comments: >> >> 1. In section 2 it sounds as though you are suggesting that the new RR >> containing the encryption key needs to be published in the parent zone. >> Why not publish this as a RR at the apex of the zone with whose name >> servers you want to encrypt? The advantage to putting encryption keys >>in >> the zone rather than the parent is that you create less work for >> registrars who already seem to really struggle with providing a way to >> publish DS/DNSKEY records. >Because that would require an unencrypted query to the zone NS to get >the zone key - and that would be a huge leak of information (as an >attacker would know that a victim is looking for something in >wikileaks.org, probably www.wikileaks.org). I know that putting the keys >at the delegation point is going to be much harder to implement in real >world but as an alternative is compromising privacy - it's the only >proper way. This is a great opportunity to not let the best become the enemy of better. The parent could be a preferred location rather than the only location. Passive monitoring would see a query go to the NS IP of the zone in question anyway so you don't really loose much privacy by publishing the key at the NS owner label. You are still able to encrypt queries that include a delegation. I disagree that it would offer a "huge" leak of information, in fact I would argue that you really don't disclose anything that would not already be disclosed since you have to talk to the NS IP. > >> 2. The fallback to reverse DNS takes an optimistic view of reverse DNS. >> Most hosting providers will not grant permission to customers to publish >> in the reverse DNS for net blocks that they manage. >This approach is mostly for recursive servers - and those as mostly >managed by owners of the net block. An alternative for recursive servers >is a hardcoded key in eg. /etc/resolv.conf. >The question if this should be a fallback for auth servers is open for >discussion, I've already heard voices that it's not a good idea and I'm >not insisting on it. > >> 4. Section 3.1.1 specifies an applicable NS name. It is not clear to me >> why I would want this field. Wouldn't it be more consistent with the >> current mode of operation of the DNS to determine this using the DNS >> hierarchy? A zone operator would publish an NSK at the owner name for >>the >> NS to which it applies. >My goal was to allow two different keysets for a domain in case its >nameservers are operated by different entities, so that domain owner >doesn't have to share his keys with SNS (and so that a SNS can use small >amount of keys, and not different key for every domain it hosts), eg: > >example.com IN NS ns1.provider1.com >example.com IN NS ns2.provider1.com >example.com IN NS ns.provider2.com >example.com IN NSK ... *.provider1.com ... >example.com IN NSK ... *.provider2.com ... > > >> 5. I would recommend choosing a different name for the new RR as Name >> Server Key could create confusion to folks learning about the various >>key >> records in the DNS. What about something like NSENCK - Name Server >> Encryption Key? >I'm open to propositions, I had an opinion that DNSENC is to similiar to >DNSSEC so I've changed the name to DNSCRYPT just to get a message that >it is already commonly used so I'm back to DNSENC. > >> 6. Failure modes could use some attention. It would be useful to >> distinguish cases where a decrypt fails due to a wrong key versus a >>format >> error, unsupported encryption scheme , etc. >Agree, that's an early version of draft and I was focused mostly on >describing the general idea, not getting into details. > > >Witold Kręcicki ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-krecicki-dprive-dnsenc-01 - call for review
W dniu 22.10.2015 o 15:04, Wiley, Glen pisze: > On 10/22/15, 8:18 AM, "Witold Kręcicki"wrote: > > >> W dniu 22.10.2015 o 13:44, Wiley, Glen pisze: >>> This is an interesting idea, a few comments: >>> >>> 1. In section 2 it sounds as though you are suggesting that the new RR >>> containing the encryption key needs to be published in the parent zone. >>> Why not publish this as a RR at the apex of the zone with whose name >>> servers you want to encrypt? The advantage to putting encryption keys >>> in >>> the zone rather than the parent is that you create less work for >>> registrars who already seem to really struggle with providing a way to >>> publish DS/DNSKEY records. >> Because that would require an unencrypted query to the zone NS to get >> the zone key - and that would be a huge leak of information (as an >> attacker would know that a victim is looking for something in >> wikileaks.org, probably www.wikileaks.org). I know that putting the keys >> at the delegation point is going to be much harder to implement in real >> world but as an alternative is compromising privacy - it's the only >> proper way. > > This is a great opportunity to not let the best become the enemy of better. > The parent could be a preferred location rather than the only location. That is an option, but I'm afraid that if this becomes an option then no operator will allow putting NSK at delegation point... > Passive monitoring would see a query go to the NS IP of the zone in > question > anyway so you don't really loose much privacy by publishing the key at the > NS owner label. You are still able to encrypt queries that include a > delegation. In most cases NSes are shared (I always wanted to use wikileaks.org, but it's a bad example here ;) ) so information that a specific IP is queried is only revealing that a victim might be querying one of the domains that are hosted on a specific NS (and attacker usually doesn't have the full list). Witold Krecicki ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] New agenda posted...
Hi all, I've just posted an updated agenda for the Yokohama meeting. Included below for convenience. WG: DNS PRIVate Exchange (dprive) Meeting:IETF 94, Yokohama Location: Pacifico Yokohama Date: 2 Nov 2015 Time: 17:10-19:10 Chairs: Warren Kumari Tim Wicinski Administrivia - Agenda Bashing, Blue Sheets, etc. Warren / Tim 10 minutes DNS over DTLS draft-ietf-dprive-dnsodtls-02 Reddy 20 min DNS over TLS draft-ietf-dprive-dns-over-tls-01 Allison 30 min Stateless DNS Encryption draft-krecicki-dnsenc-00 Ray Bellis / Mukund Sivaraman 15 min The Eval Document [ TBD ] 10 min The way forward… Warren / Tim 15 minutes Performance art / interpretive dance. 5 minutes -- 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 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy