Subject: [dns-privacy] Moving things along...

From: Warren Kumari <[email-masked]>
Date: Wed, 18 Feb 2015 14:48:25 -0500

Dear DPRIVE,

Apologies for the lack of momentum - your chairs had gotten
sidetracked by holidays, lots of travel, day-jobs, etc and have not
been giving the WG the time it deserves.

Getting things moving again, we need to decide on a way forward.

We now have 2 primary document sets under consideration:
A: Phillip Hallam-Baker's set:
DNS Privacy and Censorship: Use Cases and Requirements -
http://tools.ietf.org/html/draft-hallambaker-dnse-02
Service Connection Service (SXS) -
http://tools.ietf.org/html/draft-hallambaker-wsconnect-08
Private-DNS - http://tools.ietf.org/html/draft-hallambaker-privatedns-01

B:  The combined USC/Information Sciences, Verisign, VPN Consortium doc
TLS for DNS: Initiation and Performance Considerations -
draft-hzhwm-dprive-start-tls-for-dns

We have 3 possible options here:
1: Adopt Phillip's set
2: Adopt the hzhwm-dprive-start-tls-for-dns doc
3: Adopt both, with the understanding that one will fall by the wayside.

I''d appreciate it if the WG can read both sets of documents, and
start deciding which option best meets the WG's goals.

We expect to get the Aziz / Allison Mankin evaluation document next
week, which will contain ways of describing the privacy goal and
helping evaluate how well it is attained; but we can, and should, read
the document sets before that.

W

-- 
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: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Feb 2015 20:56:55 +0100

On Wed, Feb 18, 2015 at 02:48:25PM -0500,
 Warren Kumari <[email-masked]> wrote 

> We now have 2 primary document sets under consideration:

What is your assessment of draft-hoffman-dprive-dns-tls-* and
draft-wijngaards-dnsop-confidentialdns?

Lacking a common set of criteria to choose among the proposals, I can
say that, by my book, they should be considered, too.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 18 Feb 2015 21:26:50 +0100

Does it mean that you want to only go with solution to change DNS protocol?
You don't want to put any other solution in agenda which doesn't change much
the DNS protocol  such as cga-tsige. The might be more examples.

Best,
Hosnieh

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> Warren Kumari
> Sent: Wednesday, February 18, 2015 8:48 PM
> To: [email-masked]
> Subject: [dns-privacy] Moving things along...
> 
> Dear DPRIVE,
> 
> Apologies for the lack of momentum - your chairs had gotten sidetracked by
> holidays, lots of travel, day-jobs, etc and have not been giving the WG
the time
> it deserves.
draft-hzhwm-dprive-
> start-tls-for-dns
> I''d appreciate it if the WG can read both sets of documents, and start
> deciding which option best meets the WG's goals.
> 
> We expect to get the Aziz / Allison Mankin evaluation document next week,
> which will contain ways of describing the privacy goal and helping
evaluate
> how well it is attained; but we can, and should, read the document sets
before
> that.
> 
> W
> 
> 
> --
> I don't think the execution is relevant when it was obviously a bad idea
in the
> first place.
regret at
> having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Warren Kumari <[email-masked]>
Date: Wed, 18 Feb 2015 16:50:49 -0500

On Wednesday, February 18, 2015, Stephane Bortzmeyer <[email-masked]>
wrote:

>  Warren Kumari <[email-masked] <javascript:;>> wrote

 Sorry, I should have been more clear - draft-hoffman-dprive-dns-tls-* has
been combined with the Verisign document.

On the draft-wijngaards-dnsop-confidentialdns front, we hadn't really
discussed it much / Wouter hasn't asked for it to be adopted, but you are
right - it had completely slipped my mind. (Writing on a phone, will look
more when I get home, and also check if they want to persue it. )

W

-- 
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: Paul Hoffman <[email-masked]>
Date: Wed, 18 Feb 2015 14:44:35 -0800

On Feb 18, 2015, at 11:56 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> What is your assessment of draft-hoffman-dprive-dns-tls-*

Ah, sorry, I should have said so in public. I'm dropping the draft-hoffman-* ideas because one (new port) is now part of hzhwm-dprive-start-tls-for-dns. If others really think that the ALPN or HTTP-wrapping are a good idea, I'm happy to have them move those forwards, but personally, I think both are less likely to succeed than hzhwm-dprive-start-tls-for-dns.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 18 Feb 2015 17:45:16 -0500

> the DNS protocol  such as cga-tsige. The might be more examples.

The CGA-TSIG document itself seems to have been shopped around a large
amount, starting in 2012 -- I see it being pushed in IntArea, SAAG,
DANE, DNSOP, DNSEXT and DPRIVE.

It has been discussed in DPRIVE, but I did not get the sense that the
WG had interest in pursuing it. There were some questions / confusion
about what exactly it provides / how it works.
You did request agenda time in Dallas - we only requested a 90 minute
slot, and so can only give you 10 minutes to present and answer
questions - if the WG shows support after that we can discuss adopting
this as well....

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Feb 2015 19:23:59 -0500

> the DNS protocol  such as cga-tsige. The might be more examples.

I am not proposing to change the DNS protocol. What I am proposing is to
change the DNS protocol Session layer while keeping the DNS protocol the
same. The VeriSign proposal is essentially the same.

I know people don't like thinking of things in terms of the ISO stack model
(because that particular model is rubbish). But thinking of the problem in
terms of a stack is still really useful.

A DNS client cannot have an encrypted conversation with a DNS server unless
both the client and serve understand the encryption protocol and know the
key. So there is going to have to be a code change at both sides. The
question is what that change should look like.

Despite the name 'TLS', TLS actually works above the TCP layer so it isn't
transport. It is something in between. The Internet does not follow the ISO
stack model but it does have layers between ISO layers 4 and 7.

What changes at each layer is not just the data format, the identifiers
change as well. An Application connects to the Internet through a DNS name.
The connection to the transport layer is an IP address and port number.

Here is the problem: DNS is not just an information service built on top of
the Internet stack, it is an information service that is being used in
layers 5 and 6. It is certainly being used to map DNS host names to IP
addresses and I would like to see it being used to map DNS Service (SRV)
names to host names.

So the design of any revised DNS client-resolver protocol has to dance
round the bootstrap problem.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 19 Feb 2015 09:15:37 +0100

On Wed, Feb 18, 2015 at 04:50:49PM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 78 lines which said:

> Sorry, I should have been more clear -
> draft-hoffman-dprive-dns-tls-* has been combined with the Verisign
> document.

No, _I_m sorry, I didn't read draft-hzhwm-dprive-start-tls-for-dns-01
yet. Doing it now.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 19 Feb 2015 10:24:00 +0100

Hi Warren,

> questions - if the WG shows support after that we can discuss adopting

I am going to do another revision before cut off date. Please allocate 
this 10 mins to this draft (hopefully this is enough). I will use this 
time only to cover questions rather than explaining the detail idea.

Thank you,
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 19 Feb 2015 10:56:36 +0100

On , Phillip Hallam-Baker wrote:
> I am not proposing to change the DNS protocol. What I am proposing is
> to change the DNS protocol Session layer while keeping the DNS
> protocol the same. The VeriSign proposal is essentially the same.
> 
> I know people don't like thinking of things in terms of the ISO stack
> model (because that particular model is rubbish). But thinking of the
> problem in terms of a stack is still really useful.
> 
> A DNS client cannot have an encrypted conversation with a DNS server
> unless both the client and serve understand the encryption protocol
> and know the key. So there is going to have to be a code change at
> both sides. The question is what that change should look like.
> 
> Despite the name 'TLS', TLS actually works above the TCP layer so it
> isn't transport. It is something in between. The Internet does not
> follow the ISO stack model but it does have layers between ISO layers
> 4 and 7.
> 
> What changes at each layer is not just the data format, the
> identifiers change as well. An Application connects to the Internet
> through a DNS name. The connection to the transport layer is an IP
> address and port number.
> 

Hi Phillip,

Thanks for the explanation. I haven't reviewed the recent version of 
your draft and perhaps I have a wrong impression about this draft. I 
think I will receive the answer to some questions about "how does DNS 
server and client starts negotiating the security parameters such as 
key, algorithm, etc. at the beginning of establishing this secure 
channel so called TLS? Does all DNS server needs to have a CA so that 
the client doesn't need any pre-config? or DANE? " later after deep 
review.

> Here is the problem: DNS is not just an information service built on
> top of the Internet stack, it is an information service that is being
> used in layers 5 and 6. It is certainly being used to map DNS host
> names to IP addresses and I would like to see it being used to map DNS
> Service (SRV) names to host names.
> 

I hope in  operational side, it is also easy. If one needs almost no 
changes on clients and servers and only the implementation and 
installation of such protocol, solve all the problem, then it is the 
ideal solution but if one needs to think about middle boxes and changes 
the configuration of them (one by one) to provide such service, then it 
is likely to be not easy.

Thanks,
Best,
Hosnieh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 22 Feb 2015 13:52:46 +0100

On Wed, Feb 18, 2015 at 05:45:16PM -0500,
 Warren Kumari <[email-masked]> wrote 

> about what exactly it provides / how it works.

A good summary. I've read these CGA-TSIG documents and I still do not
understand the problem it solves, and how. A big explanation effort,
starting from a problem statement, seems necessary.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 22 Feb 2015 14:04:27 +0100

> 
> On Wed, Feb 18, 2015 at 05:45:16PM -0500,  Warren Kumari
> <[email-masked]> wrote  a message of 101 lines which said:
> 
starting
> from a problem statement, seems necessary.

Secure authentication + data encryption 

Your suggestion to improve summary is welcomed as I am working on revision.

Best,
Hosnieh

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Feb 2015 19:21:11 +0000

> Your suggestion to improve summary is welcomed as I am working on revision.

Hang on - didn't we set up a mailing list [1] for exactly that
purpose? I.e. to investigate and explain Hosnieh's proposal.
AIUI that wasn't fruitful and the list was closed.

I hope the dprive chairs will not allow repetition of all of that
discussion here. That's nothing against Hosnieh or her proposal,
but we should not divert this wg with such repetition.

S.

[1] https://www.ietf.org/mail-archive/web/secauth/current/maillist.html

---

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Feb 2015 14:53:24 -0500

> AIUI that wasn't fruitful and the list was closed.

Ah! Yes, I kinda, vaguely remember this -- I followed this list for a
very short while, but quickly decided I didn't have time (or
interest).
It is useful to know that the consensus (after ~250 emails, so it was
well discussed) was not to pursue this or form a WG. I've just
cherry-picked a few emails from the list, and agree with the
consensus.

> but we should not divert this wg with such repetition.

Agree. Apologies to Hosnieh, but due to the tight agenda time and the
fact that CGA-TSIG has already been discussed (in multiple venues), we
will not be able to provide you with discussion time.
W

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 22 Feb 2015 21:19:11 +0100

> >> > A good summary. I've read these CGA-TSIG documents and I still do
> >> > not understand the problem it solves, and how. A big explanation
> >> > effort,
> > starting
> Hang on - didn't we set up a mailing list [1] for exactly that purpose? I.e. to
> investigate and explain Hosnieh's proposal.
> I hope the dprive chairs will not allow repetition of all of that discussion here.
> That's nothing against Hosnieh or her proposal, but we should not divert this
> wg with such repetition.

Hello? did you read the message at all or Do you have allergy with my name!! Don't be defensive I am not armed!  :-)

JFYI : CGA-tSIG is whole about DNS and nothing to do with secauth... secauth and now SDNauth [1] [2] is about SDN authentication and authorization especially the authorization of two controllers. This is nothing to do with DNS and DNS privacy. 

About closing an active group, other people have already also discussed in IETF discussion list and also secauth group. So I don't see a good reason to bring that discussion here to another group.

[1] http://mail.rozanak.com/pipermail/sdnauth/
[2] https://mail.rozanak.com/mailman/listinfo/sdnauth

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 22 Feb 2015 21:22:51 +0100

Warren,

Secauth is different than CGA-TSIGe. CGA-TSIGe is about secure
authentication for DNS (not for everything) and encrypting the whole DNS
message with almost no clear change on DNS protocol. 

So this is also can be an option and solution space for Dprive. 

I don't know what Stephen is saying. But secauth is clearly different or was
different than CGA-TSIG/e.

Thanks again for keeping it in agenda as I have prepared for it.

Best,
Hosnieh

> Ah! Yes, I kinda, vaguely remember this -- I followed this list for a very
short
> while, but quickly decided I didn't have time (or interest).
> It is useful to know that the consensus (after ~250 emails, so it was well
> discussed) was not to pursue this or form a WG. I've just cherry-picked a
few
> emails from the list, and agree with the consensus.
> 
> >
> > discussion here. That's nothing against Hosnieh or her proposal, but
> > we should not divert this wg with such repetition.
> 
> Agree. Apologies to Hosnieh, but due to the tight agenda time and the fact
> that CGA-TSIG has already been discussed (in multiple venues), we will not
be
> able to provide you with discussion time.
> W
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 22 Feb 2015 21:31:11 +0100

On Sun, Feb 22, 2015 at 09:22:51PM +0100,
 Hosnieh Rafiee <[email-masked]> wrote 
 a message of 49 lines which said:

> with almost no clear change on DNS protocol. 

Stop playing with words: if it requires a change in both client and
server, it *is* a change in the protocol (even if the DNS part is
unmodified, which is, for instance, the case with
DNS-over-TLS-on-new-port). If it can be deployed unilaterally by one
party, it is not a change in the protocol.

I don't see how encryption of DNS traffic could be done without a
change in the protocol.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 22 Feb 2015 22:42:37 +0100

> Stop playing with words: if it requires a change in both client and
server, it
> *is* a change in the protocol (even if the DNS part is unmodified, which
is, for
> instance, the case with DNS-over-TLS-on-new-port). If it can be deployed
> unilaterally by one party, it is not a change in the protocol.

Maybe there is misunderstanding of the definition of changes. Perhaps we
need to come up with the unique the meaning of changes: I use the following
definition. You might want to modify it.
There are 3 different changes:
- Big changes : completely new protocol than DNS --- I guess no of the
current solution proposals were in this area... or if it is  I cannot recall
it.

- medium changes: It uses the current DNS protocol but the implementation of
that requires configuration changes on middle boxes as well as installation
of the protocol on clients and server. It might be something like SSH that
is the combination of different protocol that make one protocol but it has
its own assigned port. If there is no unique assigned port then the problem
might be the performance as the DNS server doesn't know which message on TLS
port  belongs to it and which one is for other purposes.  You might say
otherwise, but I would classify DNS over TLS in this category. 

- small changes:  only the installation of that protocol (option) is enough.
It uses the current DNS protocol. 
This is where I categorize CGA-TSIGe.

> I don't see how encryption of DNS traffic could be done without a change
in
> the protocol.

I would be happy to explain to you in more detail. Of course I cannot cover
all 50 pages of the draft here but try to make it short and only explain the
main functions.

--------------1-How a client receive the DNS information---------

Client receives the DNS information from an option in DHCP server or in an
option of router advertisement in a secure way. 

Untrusted network:
If the DHCP server is not trusted or DNS resolver is not trusted, then
either the client can refer to the already trusted resolver list (I presumed
that the implementation need to keep a short list of home resolvers or
trusted resolvers). How to automatically fill this list might have different
solution and not so easy. How a client understands whether this is trusted
or not, one way can be based on receiving an invalid DNS IP address (in
local range). 
If the user is professional, then the protocol should allow a user to
manually set this value. Since the this protocol can securely authenticate
the set value, it doesn't allow MITM. (please refer to draft for further
information)

------------------2-How a client tells the DNS server that it uses
cga-tsige----------

This has two options. Either using current available messages for key
exchange without defining new messages.
Or using the current DNS empty message only with having TSIG as an
additional part and set the algorithm type to CGA-TSIGe. 

CGA-TSIGe is added in "Other DATA" of TSIG. (please refer to draft for more
info)

-------------3- Why DNS server exchange its keys with client and sign
it----------------

1- the client verifies the DNS server (authenticate) as it already received
DNS server information in a secure way (like IP and hash of the key). 
2- the client use this public key to encrypt only a random number (called
shared secret or session key). Then the client can use this shared secret to
encrypt the whole DNS message.

-----------4- If the whole DNS message is encrypted, how the DNS server
knows how to decrypt this----------

The DNS message is encapsulated to a new DNS message. After the DNS message
is encypted using that shared secret, the client then add a new header to
this DNS message and this encrypted message will be the body section of this
new DNS message (please refer to the draft
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11#section-4.2.2.1.
1 specially step 4. for more information). In other word, CGA-TSIGe actually
uses  the whole encrypted section as one single question
+-----+------+--------+
   |Type |Length|Reserved|
   |1byte|1 byte| 1 byte |
   +---------------------+
   |        Header       |
   |       12 bytes      |
   +---------------------+
   |  Encrypted sections |
   |   variable length   |
   +---------------------+
   |   Additional Data   |
   |   variable length   |
   +---------------------+
   Figure 9 Encrypted DNS Query message

Figure 9 of draft shows this encapsulation. 

When the DNS server receive such message, based on the header it can find
additional section and when the algorithm type is CGA-TSIGe, then it first
decrypt the secret key by its own private key (which is in the additional
section) and then decrypt the whole message using the shared secret and a
symmetric  algorithm. All necessary information about symmetric algorithm
can be found in additional section. 

This is the whole process. The main difference of this approach and DNS over
TLS is how key exchange occurs and how they process the encryption. The
similarity is that both need to use public key cryptography for session key
encryption and shared key and a symmetric algorithms for better performance.

The other difference might be the verification of DNS server.

If there are other questions, I'll be happy to answer and cover them.

Best,
Hosnieh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 Feb 2015 19:53:05 -0500

Responding to Hosnieh:

We have to avoid loaded terms like minimal changes. What is a minimal
change is a very subjective question.

We have middlebox issues. Since a middlebox can't do anything useful to an
encrypted message and because my objective is to bypass government
censorship schemes, my approach is to bypass the middleboxen wherever
possible. So I see no value in port 53 whether UDP or TCP.

Changing the port number isn't really a major change in the protocol in my
view.

Sure we could tunnel e-DNS over DNS. In fact I started off doing that three
years ago. I even wrote code for that. But why bother when there are plenty
of uncluttered UDP ports?

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 23 Feb 2015 07:04:22 +0100

From: dns-privacy [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker

We have to avoid loaded terms like minimal changes. What is a minimal change is a very subjective question.

We have middlebox issues. Since a middlebox can't do anything useful to an encrypted message and because my objective is to bypass government censorship schemes, my approach is to bypass the middleboxen wherever possible. So I see no value in port 53 whether UDP or TCP.

Changing the port number isn't really a major change in the protocol in my view.

Sure we could tunnel e-DNS over DNS. In fact I started off doing that three years ago. I even wrote code for that. But why bother when there are plenty of uncluttered UDP ports?

--------------------------------
[Hosnieh] Don't make mistake... first of all the discussion is not about whether this or that proposal is good or bad. The discussion is about having EQUAL chance for all proposals to present themselves while this haven't happened at least for CGA-TSIGe and everytime dropped from agenda.

[Hosnieh] The similarity of all proposals IMO are as follows:
1- the purpose of all proposals are to avoid government censorship. 
2- encrypting the DNS messages

The differences of these proposals are:
1- How to do the encryption of DNS message

Now let's back to any proposals with the need of using other ports than DNS. To be realistic, at the moment in all middle boxes like a firewall , port 53  have been defined for DNS and open for that purpose. In most large enterprises there are restricted policies and mostly the keep close all unnecessary ports. In none of my message I said it is not possible to re-configure all of these devices, but would say it is not easy not only technically but also non-technically. I am not talking about a small network with perhaps one firewall or a router, but large corporates. I know that many big enterprises have a lot of bureaucracy to change any single things in their network. furthermore, this Is too much administrative works. 

I hope it is clear.
Best,
Hosnieh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Feb 2015 09:20:38 -0500

On Mon, Feb 23, 2015 at 1:04 AM, Hosnieh Rafiee <[email-masked]> wrote:

> Phillip Hallam-Baker
> Sure we could tunnel e-DNS over DNS. In fact I started off doing that
> three years ago. I even wrote code for that. But why bother when there are
> plenty of uncluttered UDP ports?
>
> [Hosnieh] Don't make mistake... first of all the discussion is not about
> whether this or that proposal is good or bad. The discussion is about
> having EQUAL chance for all proposals to present themselves while this
> haven't happened at least for CGA-TSIGe and everytime dropped from agenda.
>
> Now let's back to any proposals with the need of using other ports than
> DNS. To be realistic, at the moment in all middle boxes like a firewall ,
> port 53  have been defined for DNS and open for that purpose. In most large
> enterprises there are restricted policies and mostly the keep close all
> unnecessary ports. In none of my message I said it is not possible to
> re-configure all of these devices, but would say it is not easy not only
> technically but also non-technically. I am not talking about a small
> network with perhaps one firewall or a router, but large corporates. I know
> that many big enterprises have a lot of bureaucracy to change any single
> things in their network. furthermore, this Is too much administrative works.
>

I don't think we should have any concern for providing a bypass for the
enterprise case. If General Motors wants to control their network, that is
their business. They have a right to decide what devices connect to their
network and every bit of software in the stack.

The reason for providing a plan-b transport is that many ISPs are playing
idiot games with DNS that we do need a work-around on. Residential
broadband typically has UDP open so as to support world of warcraft etc.

We should not worry too much about the possibility of providing a
standardized firewall bypass mechanism. There are plenty of non standard
ones and it is not our job to fix holes in other people's sieves.

But that does not mean that we should design the protocol to bust
enterprise network firewalls either.

Busting the DNS middleboxen provided by ISPs to residential users is a very
different matter. They are selling Internet connectivity and their customer
has a right to get what they paid for, not a walled garden controlled by
the ISP. But in practice it isn't the walled gardens that are the problem
so much as clueless gateways that the ISPs often don't even know are doing
DNS interception.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Feb 2015 19:11:42 -0500

> Sure we could tunnel e-DNS over DNS. In fact I started off doing that three years ago. I even wrote code for that. But why bother when there are plenty of uncluttered UDP ports?

<chair hat on>
I'm sorry, but no. The discussion is not about "having EQUAL chance
for all proposals to present themselves" - we only give agenda time to
proposal that:
A: are within our charter and
B: that the WG appears to want to work on / discuss.

I do not see a reasonable indication that the WG wants to work on this.
However, in order to avoid any personal bias (I have previously
expressed some views on CGA-TSIG, which *is* related), I'm going to
poll the WG.

---------
Dear DPRIVE participants,

Are you interested on working on CGA-TSIGe and would you like to
devote some (10 minutes) of the meeting time in Dallas to a
presentation / discussion on CGA-TSIGe?

Warren

---------
</chair hat>

---

From: Neil Cook <[email-masked]>
Date: Thu, 26 Feb 2015 11:35:03 +0000

> On 23 Feb 2015, at 14:20, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Busting the DNS middleboxen provided by ISPs to residential users is a very different matter. They are selling Internet connectivity and their customer has a right to get what they paid for, not a walled garden controlled by the ISP. But in practice it isn't the walled gardens that are the problem so much as clueless gateways that the ISPs often don't even know are doing DNS interception.
> 

Whilst I don’t deny that ISPs are using middelboxes for things like advertising etc, it should also be pointed out that many ISPs are concerned about security, and may be using middleboxes to protect users from things like hijacking, detecting C&C in the DNS stream, detecting lookups to known phishing/malware sites etc. 

Assuming what users want or saying that they aren’t getting what they paid for is quite dangerous IMO. For example, many users sign up to third-party DNS services like OpenDNS, because they effectively *are* are a walled garden, or they may choose an ISP because it filters adult sites using DNS (such as happens here in the UK).

Neil

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Feb 2015 08:57:19 -0500

On Thu, Feb 26, 2015 at 6:35 AM, Neil Cook <[email-masked]> wrote:

I think we are actually in violent agreement here.

> > Busting the DNS middleboxen provided by ISPs to residential users is a
> very different matter. They are selling Internet connectivity and their
> customer has a right to get what they paid for, not a walled garden
> controlled by the ISP. But in practice it isn't the walled gardens that are
> the problem so much as clueless gateways that the ISPs often don't even
> know are doing DNS interception.
> >
>
>
> Whilst I don’t deny that ISPs are using middelboxes for things like
> advertising etc, it should also be pointed out that many ISPs are concerned
> about security, and may be using middleboxes to protect users from things
> like hijacking, detecting C&C in the DNS stream, detecting lookups to known
> phishing/malware sites etc.
>

Comodo provides that type of service. As I said, the fact that a crook has
bought a DNS domain name does not mean I have to allow my computers to
connect to it. A lot of folk who can't understand why DNSSEC take up at the
client has been limited need to understand such things.

The question is who chooses the filtering service. I do not have much of a
choice in ISPs. I do not want either to be able to filter my content
without being accountable for their actions to me.

Assuming what users want or saying that they aren’t getting what they paid
> for is quite dangerous IMO. For example, many users sign up to third-party
> DNS services like OpenDNS, because they effectively *are* are a walled
> garden, or they may choose an ISP because it filters adult sites using DNS
> (such as happens here in the UK).

We should certainly provide a mechanism that allows consumers to opt back
in to such services or to obtain them from a different provider OF THEIR
CHOICE.

Opting out from David Cameron's smut filter is another objective here. Back
when we were at Oxford together, David's idea of a good time was to go out
and smash up a restaurant. I don't think he is the sort of person I want to
decide that I have to have censorship because the Daily hate wrote a couple
of their scare stories.

---

From: Neil Cook <[email-masked]>
Date: Thu, 26 Feb 2015 14:07:13 +0000

> On 26 Feb 2015, at 13:57, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> On Thu, Feb 26, 2015 at 6:35 AM, Neil Cook <[email-masked] <mailto:[email-masked]>> wrote:
> 

Yep, nothing I said is against DPRIV, just wanted to make sure these use case were handled.

> 
> > On 23 Feb 2015, at 14:20, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
> >
> Comodo provides that type of service. As I said, the fact that a crook has bought a DNS domain name does not mean I have to allow my computers to connect to it. A lot of folk who can't understand why DNSSEC take up at the client has been limited need to understand such things.
> 
> The question is who chooses the filtering service. I do not have much of a choice in ISPs. I do not want either to be able to filter my content without being accountable for their actions to me.

Indeed - if you *choose* to use a third-party DNS service, you should be able to do so securely, privately, and without restriction.

> We should certainly provide a mechanism that allows consumers to opt back in to such services or to obtain them from a different provider OF THEIR CHOICE.
> 
Right.

> Opting out from David Cameron's smut filter is another objective here. Back when we were at Oxford together, David's idea of a good time was to go out and smash up a restaurant. I don't think he is the sort of person I want to decide that I have to have censorship because the Daily hate wrote a couple of their scare stories.
> 

I’d rather not bring politics into the debate :) Opting out of the smut filter is actually straightforward today, because most ISPs don’t prevent you from using third-party DNS, but they might in future, because the DNS protocol can be transparently intercepted and interfered with/redirected. DPRIV should ensure that isn’t possible. It *should* also prevent bad guys from doing the same by hijacking your CPE or something like DNSChanger.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Feb 2015 09:45:46 -0800

> presentation / discussion on CGA-TSIGe?

No.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Feb 2015 16:42:49 +0100

On Wed, Feb 25, 2015 at 07:11:42PM -0500,
 Warren Kumari <[email-masked]> wrote 

> presentation / discussion on CGA-TSIGe?

I'm not. Currently, it's really too confused for me, and backed by
dubious claims.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 27 Feb 2015 15:44:39 +0000

> I'm not. Currently, it's really too confused for me, and backed by

Is it the same as new version? my explanation wasn't clear? What did you find confusing?

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 Feb 2015 10:45:38 -0800

At Fri, 27 Feb 2015 16:42:49 +0100,

> I'm not. Currently, it's really too confused for me, and backed by

Same here, at least that was the case for me for a couple of initial
revisions, and I almost gave up trying to understand it since then.
So, to be honest, I've not read the very latest version, and I can't
deny the possibility that it now happens to be super clear and might
even look the best fit for dprive, but as someone with a quite limited
amount of available time for IETF related stuff I'd rather focus on
the materials currently on the wg table.  I know I sound unfair, but
that's the sad reality for me.

--
JINMEI, Tatuya

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 27 Feb 2015 20:40:46 +0100

> Same here, at least that was the case for me for a couple of initial
revisions,
> and I almost gave up trying to understand it since then.
> So, to be honest, I've not read the very latest version, and I can't deny
the
> possibility that it now happens to be super clear and might even look the
best
> fit for dprive, but as someone with a quite limited amount of available
time for
> IETF related stuff I'd rather focus on the materials currently on the wg
table.  I
> know I sound unfair, but that's the sad reality for me.
> 

I would not comment on beings fair or unfair. But what I convey from your
message is like this that because something was wrong with x proposal
sometime ago,  I would generalize it and say it will never get better and
would not like to give her/him any other chance because it is worthless.  I
even do not say what part of the proposal is wrong  so that the person put
more efforts to improve that.

The clear case is that, the most current proposals are about TLS + DNS.
Everyone knows how TLS works (public key cryptography + a symmetric
algorithms). This is the same as CGA-TSIGe. But the only difference is that
the data in TLS is sent after the session initiation. But for CGA-TSIGe,
there is similar the way IPsec does but only with this difference that IPsec
(tunnel mode) encapsulate the whole packet but CGA-TSIGe, only encapsulate
the whole DNS message. In other word, the encapsulation is after TCP header.

 I agree that the first versions might be confusing. If I can recall, you
have reviewed only version 7 and no other revisions made after that. During
this time there were some other reviewers who commented and sent me their
review offlist mostly only to help to improve it.  I don't think reviewing
the introduction and overview takes more than a few minutes even for people
who don't have much time. 

Thanks,
Best,
Hosnieh

------------

2.  Introduction 

   DNS messages might contain important data which might allow an 
   attacker to analyse the behavior of users in a network or pursue 
   further attacks. The data that might be confidential and need 
   protection. There are recently a lot of concerns about DNS privacy 
   and hiding the data exchanges between stub resolvers' and DNS server 
   from prying eyes (either in active or passive attacks). 

   This document introduces a possible solution to DNS privacy by 
   protecting a user against privacy related attacks explained in 
   [dns-privacy]. It does this by providing a node with a mechanism to 
   securely verify the DNS resolver (to avoid spoofed DNS messages) and 
   encrypt the whole DNS message. It uses the current available Resource 
   Records (RRs) to carry any parameters requires for this process. 
   After encryption process, this encrypted message is encapsulated in a 
   new DNS message and the required parameters are added in the 
   additional section of this new DNS message for decryption process in 
   the receiver node. 

   To address DNS data protection where it is needed (Data 
   confidentiality), considering different factors ? automation 
   (minimizing human interaction); secure authentication; performance; 
   encryption, and to secure the last miles of Internet where DNSSEC 
   cannot easily handle this protection (especially authentication 
   during DDNS and authentication of DNS resolvers), this document 

Rafiee, et al.      Expires August 27, 2015                     [Page 4]

INTERNET DRAFT             New algorithms in TSIG      February 27, 2015

   proposes two algorithms -- one is for secure authentication that is 
   called CGA-TSIG and one for both secure authentication and DNS data 
   encryption (DNS privacy) that is called CGA-TSIGe. CGA-TSIGe is a 
   mechanism to address DNS privacy issues. In DNS privacy, this 
   document uses both asymmetric and symmetric cryptography. Asymmetric 
   cryptography is used for encrypting the 16 byte secret key. This 
   secret key then can be used as a key for the symmetric encryption 
   algorithm in order to encrypt the whole DNS message. This process 
   will increase the DNS performance by avoiding the encryption of a 
   large DNS message using a public key cryptography. These algorithms 
   support both IPv4 and IPv6 enabled network and considered as new 
   algorithms in the TSIG Resource Record (RR). 

2.1.  Overview of CGA-TSIG/e Mechanisms 

   - Purpose 

   1-secure authentication, 2-provide data confidentiality and 
   3-minimize human interaction required to accomplish a shared secret 
   or key exchange. If only number 1 and 2 is the purpose, then the 
   algorithm is called CGA-TSIG. When 1,2, and 3 all together is the 
   purpose, then the algorithm is called CGA-TSIGe 

   It uses the same port as DNS protocol, therefore, there is no need to 
   change any middle boxes to adapt them to this proposal. The 
   installation of this mechanism on client and server is enough. Since 
   this protocol is added to "Other Data" section of TSIG RR, when a DNS 
   client or server does not support CGA-TSIG, it easily ignores 
   CGA-TSIG option without returning any error and returns back to 
   compatibility mode, i.e., using DNS server without encryption. 

   - How client and server receives the IP address/hash of public key of 
   DNS server? 

   There are two possibilities: 1- From a DNS option in router 
   advertisement message [RFC6106] 2- From a DHCP/v6 server protected 
   via SAVI approaches [savi-dhcp] or any monitoring node 

   - What if the network is not trusted (e.g. untrusted DHCP server, 
   untrusted router, untrusted DNS server) 

   This is only applicable for resolver scenario. User can easily 
   introduce the IP address of trusted resolver (or select home resolver 
   from the list of trusted resolvers in its computer). For automation 
   purpose, the implementation SHOULD provide a possibility to store a 
   short list of trusted resolvers so that the client can pick one of 
   them. 

Rafiee, et al.      Expires August 27, 2015                     [Page 5]

INTERNET DRAFT             New algorithms in TSIG      February 27, 2015

   - How CGA-TSIG/e Prevents Spoofing and authenticate DNS servers or 
   clients (depends on scenario) 

   In the IPv6 scenario, the algorithms use Cryptographically Generated 
   Addresses (CGA) [RFC3972] or Secure Simple Addressing Scheme for IPv6 
   Autoconfiguration (SSAS) [4, 5]. Both CGA and SSAS provide the nodes 
   with the necessary proof of IP address ownership by providing a 
   cryptographic binding between a host's public key and its IP address 
   without the need for the introduction of infrastructure. In other 
   word, by receiving any message from a DNS resolver, client can verify 
   its signature and since the key is bound to the IP address, the 
   client can make sure that the value is from the same resolver as it 
   already received the IP address from DHCP server or an option in 
   router advertisement message. 

   In IPv4 scenarios, the algorithms use the hash of public key as an 
   authentication approach. For example, in resolver scenario, the 
   client receives the DNS resolver?s hash of (IPv4 + public key) from a 
   DHCPv4 server that is protected by SAVI approaches or other 
   monitoring approaches. When the client receives the key from DNS 
   server it calculates the hash of (IPv4 + public key) and compare this 
   value with what it received from DHCP server. If it matches, then the 
   client can trust any value received from the DNS server. 

   - How Client and server do key exchange 

   Client sends an empty message and adding TSIG in additional part and 
   set the algorithm to CGA-TSIGe. This message then can be sent to DNS 
   server. DNS server then knows it should submit its key to client, 
   sign it with its own private key. 

   - In CGA-TSIGe, if the whole message is encrypted, How the DNS server 
   knows how to decrypt the message 

   After a client receives the public key of DNS server in a secure 
   manner (as explained in prior paragraphs), it generates a random 
   number and call this number a secret key (it is similar to session 
   key in TLS or SSL). It, then, encrypts the whole DNS message and 
   encapsulate it in a new DNS message (that is adding new header and 
   additional section). In additional section of this new DNS message, 
   it includes CGA-TSIGe and all its required parameters. In other word, 
   the whole encrypted messages is like a query section in new DNS 
   message. Then the secret key is encrypted using the public key of DNS 
   server and this message is submitted to the DNS server. 

   When the DNS server receives this message, if the additional section 
   includes CGA-TSIGe, then it first decrypts the secret key using 

Rafiee, et al.      Expires August 27, 2015                     [Page 6]

INTERNET DRAFT             New algorithms in TSIG      February 27, 2015

   public key cryptography and then decrypts the whole DNS message using 
   this secret key and a symmetric algorithm such as AES.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Feb 2015 11:58:09 -0800

On Feb 27, 2015, at 11:40 AM, Hosnieh Rafiee <[email-masked]> wrote:
> I agree that the first versions might be confusing.

I have looked at the current draft and it is still just as confusing to me. I do not feel that it is a good use of our time to cycle on this draft just to get it to be understandable to typical readers. I'm happy to read the Introduction section of further revisions and, if one eventually is clear, to comment then.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Feb 2015 16:38:56 -0500

On Fri, Feb 27, 2015 at 2:58 PM, Paul Hoffman <[email-masked]> wrote:

> I have looked at the current draft and it is still just as confusing to
> me. I do not feel that it is a good use of our time to cycle on this draft
> just to get it to be understandable to typical readers. I'm happy to read
> the Introduction section of further revisions and, if one eventually is
> clear, to comment then.
>
> --Paul Hoffman

I agree. I don't see that this is helping us understand the problem or the
solution options.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 27 Feb 2015 17:17:46 -0500

On Thu 2015-02-26 08:57:19 -0500, Phillip Hallam-Baker wrote:
> Comodo provides that type of service.

Is this a reference to PrivDog?  With all respect to Phillip, i hope the
recent vulnerabilities announced in some versions of PrivDog will make
users think twice about subscribing to service:

https://blog.hboeck.de/archives/865-Software-Privdog-worse-than-Superfish.html

Adopting a "security services provider" like this invariably means
opening yourself to whatever vulnerabilities lurk in that provider's
technological (and organizational, and legal) stack.

There is room for such a service in the world, but we need to find ways
to hold services like that to a *much* higher standard if we hope to
rely on them safely.

A confidential resolving DNS cache sounds much easier and safer to use
by comparison, and DNSSEC could *still* be verified on the client side
(with some kind of extension to indicate that a domain is blacklisted)
to avoid exposure to the kind of untrustworthy behavior we saw in
PrivDog.

        --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Feb 2015 12:50:28 -0500

> users think twice about subscribing to service:

That isn't actually ours. And one of the problems with AV software is that
it tends to share a lot of coding practices with the malware it is intended
to suppress.

We distributed a different version that passed our QA before the bug was
inserted. Perhaps Clayton Christiansen's proposal to separate out
disruptive technologies from the core company is not the best advice in a
security product context.

All security problems are easy if you only look at one problem. Lets stop
Saddam from getting nukes... yep did that... but it wasn't the only
security issue that should have been a concern now was it?

> technological (and organizational, and legal) stack.

Which is why I distinguish between rewriting TLSA records and rewriting
A/AAAA records. Very different trust concerns.

If we do the usual route of deciding how we think things should work and
supporting only those then people will come along and bust holes in our
system. And like the trust root stores that will allow roots to be added
but provide no way to limit their scope, the holes will be big and ugly
ones.

There is a justification for an enterprise root, but why not limit the
roots by default to just the enterprise domain?

Why does it take our techies half an hour to find out what roots have been
installed and what the consequences are?

> to hold services like that to a *much* higher standard if we hope to

That is an accountability model and it is a necessary component. But we
should also make as much use as possible from access control and least
privilege as well.