Looking forward to discussions on the draft in a few weeks. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917
A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A On 3/11/15, 5:55 AM, "Warren Kumari" <[email protected]> wrote: >On Wed, Mar 11, 2015 at 3:31 AM, W.C.A. Wijngaards <[email protected]> >wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Zhiwei Yan, >> >> On 03/11/2015 04:24 AM, Zhiwei Yan wrote: >>> Hi, All, I have a simple idea to support the encryption of the >>> signalings between stub and recursive resolvers under UDP. My >>> solution is based on asymmetric encryption scheme and the main >>> points are as following: >> >> https://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-03 >> >> This draft follows the points you list. Perhaps, it is one way to >> fulfil the details in what you describe? >> >> It was first submitted to perpass, but then moved to the DNSOP WG, and >> now, a bit later, it can be considered by the DPRIVE working group. > >And a reminder to all to please read this draft -- many folk already >have (during the perpass / pre-IETF times) but it will be discussed at >the meeting in Dallas, so re-reading it have the info fresh would be >good. > >W > >> >> Best regards, >> Wouter >> >> >>> o Firstly, the stub resolver and recursive resolver should >>> generate an asymmetric key pair respectively and we denote then as >>> KEY-S and KEY-R. For the KEY-S, the private key is denoted as >>> KEY-S-pub and the public key is denoted as KEY-S-pri. Similarly, >>> for the KEY-R, the private key is denoted as KEY-R-pub and the >>> public key is denoted as KEY-R-pri. o In order to publish the >>> public key of recursive resolver, KEY- R-pub can be included in an >>> option of DHCP message or in the RR of DNS following DANE >>> protocols. Anyway, the stub resolver should learn the KEY-R-pub >>> during its bootstrap phase and update it securely and easily. o >>> When the stub resolver sends DNS request message to the recursive >>> resolver, the KEY-S-pub should be contained in this message. >>> Besides, the DNS request message is encrypted by the KEY-R-pub. o >>> After receiving the DNS request message, the recursive resolver >>> decrypts the message with KEY-R-pri. Then the recursive resolver >>> records the information in the DNS request message, including the >>> KEY-S-pub. o When the recursive resolver replies to the stub >>> resolver, it encrypts the DNS response message with KEY-S-pub. >>> >>> Because the DNS request message sent from stub resolver to >>> recursive resolver is encrypted by the public key of the recursive >>> resolver, only the corresponding recursive resolve can decrypt that >>> DNS request message. In opposite, because the DNS response message >>> sent from recursive resolver to stub resolver is encrypted by the >>> public key of the stub resolver, only the corresponding stub >>> resolver can decrypt that DNS response message. In this way, the >>> privacy of the exchanged messages between stub and recursive >>> resolvers can be guaranteed. >>> >>> I just want to get some comments from you. If you think this >>> solution makes sense, the draft will be published after the IETF >>> meeting. BR, Zhiwei Yan >>> >>> >>> 2015-03-11 >>> >>> >>> >>> _______________________________________________ dns-privacy mailing >>> list [email protected] >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iQIcBAEBAgAGBQJU/+81AAoJEJ9vHC1+BF+NUfkQAK+l5gu3bvbFDz5UYTvs2ZAn >> UNsM3WbJocFLBQVqS/Ky/dMX15RxnR1fBn9AwCKn6095hgU8OXjsiwUFx4+J48uI >> 0Oy4OjfgrDchPYh8XnqFUVYmeVFzBwmsqRZnmwxRWoMZGzk4iBARlBBCF9VVW/Kl >> qYREdv4J0GJSMJSQQjZ728+EIsyJqhUr0yNZQ3XaokM9hGNUpy6/IvfzSosmoEeT >> im01bB5Oa4eO3cM+oTu9btzEJueePA8CrBtF98U18IBp0EhhF9lJP7xF/psrsiYx >> p9oip9Y30BDDsYbjacNDdp9c35JRAemLLfQJa2MxW/O7cBiRZsOL3yTZUZ9590xz >> uNh8/B2JCl6hs54hd7cpkuPMPrMhBc39t79n3dwdfgQph0w2M3VmlL/0DIxMeOBv >> ixnVVfIejh/1trUo0q4mb84L2Gq92GFxQ8gwQTgiveEM6Eff6APEoTP6FZ3w9mE5 >> UFehPq5EwUjSz9pKWVNQrdojaXNP+CTs5HKYXVKkdh6xah0+J0iP80gp0JBiGM7Y >> 34E0PhXxCm8LdglCbp/v6IDOCTT+O9wGeZ/P21HtFJAv8CW/NWbTRr7trL7N4rYU >> F8tU5Yjaw8SFgug575yqXfv9vacTMCZVKK1S0IfdIvCn+UQl34F5rqDLaE5uStN+ >> kwdVXLAxnduq8h5EZ8i7 >> =5/cq >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy > > > >-- >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 >[email protected] >https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
