Subject: [dns-privacy] Privacy for engineers

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Oct 2014 08:46:13 +0100

Good reading about the "blind spots" of engineers about privacy:

http://lockstep.com.au/blog/2014/08/28/engineers-and-privacy

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 27 Oct 2014 08:03:48 +0000

Hi,
I guess you have heard about CGA-TSIG. What do you think about the approach explained there?

<http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11 >

This can be one of optional approaches for privacy. This approach has almost zero changes on DNS protocol. Only needs registration with IANA. 

In introduction section you can read the motivation behind this document.

What do you think?

Best,
Hosnieh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Oct 2014 09:23:09 +0100

On Mon, Oct 27, 2014 at 08:03:48AM +0000,
 Hosnieh Rafiee <[email-masked]> wrote 
 a message of 19 lines which said:

> I guess you have heard about CGA-TSIG.

Please do not steal threads: start a new thread (otherwise, your
message will be filed under the thread I started, for some users).

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 27 Oct 2014 09:55:08 +0000

Hi Stephane,

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:[email-masked]]
> Sent: Monday, October 27, 2014 9:23 AM
> To: Hosnieh Rafiee
> Cc: [email-masked]
> Subject: Re: [dns-privacy] What about CGA-TSIG as a solution for DNS
> privacy?
> 
> On Mon, Oct 27, 2014 at 08:03:48AM +0000,  Hosnieh Rafiee
> <[email-masked]> wrote  a message of 19 lines which said:
> 

I started a new thread with new topic without replying to your message or having the same subject as yours. This is the problem of IETF mailinglist that categorized my message automatically under your thread here
http://www.ietf.org/mail-archive/web/dns-privacy/current/threads.html

so, it is better that you blame mailman programmers not me!

Best,
Hosnieh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Oct 2014 10:59:45 +0100

On Mon, Oct 27, 2014 at 09:55:08AM +0000,
 Hosnieh Rafiee <[email-masked]> wrote 
 a message of 28 lines which said:

> This is the problem of IETF mailinglist that categorized my message
> automatically under your thread here

I strongly doubt it, since *your* message included:

References: <[email-masked]>
In-Reply-To: <[email-masked]>

> so, it is better that you blame mailman programmers not me!

Nobody else had the problem so I think we can safely assume Mailman is
correct.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 27 Oct 2014 10:12:39 +0000

> On Mon, Oct 27, 2014 at 09:55:08AM +0000,  Hosnieh Rafiee
> <[email-masked]> wrote  a message of 28 lines which said:
> 

No not always. I saw a lot of such misleading information by mailman before in other groups as well. 

It appears that mailman uses a fuzzy approach and if the subject line has any similar words to the subject line of the previous thread, it categorized it under the same thread. 

As I said I have started a completely new message. So the header of my message was quite new and not carry any information for the old thread.

For instance this one is another example of such problem. Y
[dns-privacy] Authenticating the resolver, Paul Hoffman
Re: [dns-privacy] Authenticating the resolver, Wes Hardaker
Re: [dns-privacy] Authenticating the resolver, Paul Hoffman

You can also search other groups and will see many similar cases. If this is an important problem, it is better to address fundamentally in mailman and not blaming someone who either not a programmer of a mailman or even not replied or commented the same thread.

Therefore, I do not see any reason for further discussion.

Hosnieh

---

From: Bob Harold <[email-masked]>
Date: Mon, 27 Oct 2014 09:12:49 -0400

Good reading, but I cannot agree with "the definition of PII is clear cut".
  Rather "*any* information pertaining to an identifiable individual" is
extremely vague.  And when they want us to try to 'secure' information that
is already 'public', we have to scratch our heads and wonder.
But at least he admits that there are tradeoffs.  The law (or a typical
organization's policy) does not seem to understand that.

Disclaimer: definitely not speaking for my employer.

-- 
Bob Harold

On Mon, Oct 27, 2014 at 3:46 AM, Stephane Bortzmeyer <[email-masked]>
wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Oct 2014 07:20:55 -0700

> I guess you have heard about CGA-TSIG. What do you think about the approach explained there?

Is still has many confusing dependencies that make it hard to understand, and it vastly oversells the IPv4 capabilities.

> What do you think?

It is a distraction for this WG and should not be considered.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Mon, 27 Oct 2014 10:36:00 -0400

> It is a distraction for this WG and should not be considered.

+1

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: Hosnieh Rafiee <[email-masked]>
Date: Mon, 27 Oct 2014 14:36:40 +0000

Hi Paul,
> Is still has many confusing dependencies that make it hard to
> understand, and it vastly oversells the IPv4 capabilities.

Would you please clarify the problem. I would welcome any comments to improve it and open for any comments. Of course, I need to know the exact problem that I can address it clearly. Which part of the draft is not readable? Which section needs improvements which  is not easily understandable? 

One of the problem that I tried to address in this version is to improve readability. Joel helped me to make it readable. But if we missed anything, I need its exact section that is not well-written so that I can address it.

About IP based, DNS and all other services are working on IP addresses and as far as I know they are also not behind any NAT or middle box devices that makes it impossible to verify them IP based. 
Resolvers also are verified at the moment on clients based on their source IP address. Now, simply the idea behind cga-tsig is just the resolver sign their messages and by verifying this signature, the bindings help to provide to authenticate this message. Then the client can use this public key of the resolver to encrypt a random value (used as a session key) and then encrypt the whole message using this random value and AES algorithm. 

> It is a distraction for this WG and should not be considered.

There might be several solution in this regard. This draft is also simply a solution to DNS privacy (providing both authentication and required encryption easily). 

So why do you think it is distraction for the WG that addresses privacy?

Thanks,
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 27 Oct 2014 14:42:19 +0000

> > It is a distraction for this WG and should not be considered.

It would be good to know the reason before just simply say I agree or disagree does not help to understand the reason. Does this group address privacy? If so why a solution to a privacy is not acceptable for this group? 

Does the group decided on the solution space yet and do not want to go through encryption? 

Thanks,
Best,
Hosnieh

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Oct 2014 07:45:52 -0700

> So why do you think it is distraction for the WG that addresses privacy?

I said I thought it was a distraction; discussing it further would be more of a distraction.

--Paul Hoffman

---

From: Don Blumenthal <[email-masked]>
Date: Mon, 27 Oct 2014 14:51:48 +0000

Thanks, Stephane. 

The article is excellent in discussing the intersection of privacy issues and ICT. However, "[o]nline and in privacy law alike, things are very crisp." Maybe they are in Australia. However,  one of the big challenges in the privacy space is that definitions of PI, PII, and similar acronymed (word?) concepts vary widely and may not be spelled at all in some jurisdictions.

I find it curious that Mr. Wilson makes such a categorical statement in this article while linking to another post where he discusses definitional uncertainties. http://lockstep.com.au/blog/2013/09/27/pii-or-not-pii. It was worthwhile following his links to get a full picture.

Don

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 27 Oct 2014 14:51:30 +0000

> I said I thought it was a distraction; discussing it further would be

Unfortunately, I haven't received any answer to the question that "why it is distraction?". I only received ambiguous answer to the question.

I do not think WG decided on any solution space , if the scope is not to have any encryption, then I agree with you. But I couldn't see anything on charter about this. 

Best,
Hosnieh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Oct 2014 11:10:04 -0400

> I said I thought it was a distraction; discussing it further would be more

Which is not a polite or acceptable fashion to deal with a proposal.

Like many people I have been looking at applying TSIG more generally for
many years. I think the approach is architecturally sound from a security
point of view but it isn't a complete solution and when you start to extend
it to meet the use cases here it soon becomes apparent that reuse is
hurting more than helping.

TSIG is only authentication so you have to add encryption. And the original
TSIG assumed keys would be passed out of band so it needs a key exchange.

So lets divide the protocol into two parts, a key exchange that establishes
a shared secret and some form of packaging that applies encryption and
integrity operations to the DNS messages.

The second part is straightforward. People can agree or disagree as to
whether my attempts to optimize the transport for DNS deliver worthwhile
benefits, we can argue over the specific encoding (I picked the TLS
schema). But what is clear is that it should be very simple to describe and
implement or its being done wrong.

The key exchange is the place where the design choices come in. And here we
have two approaches:

1) Reuse something already existing (CGA-TSIG, DTLS).
2) Write something new designing it so that it could be reused elsewhere.

I believe the second course is the best approach in this case. I am not
re-inventing the TLS crypto but I am presenting it as a JSON web service in
a way that allows for reuse.

CGA does not meet the use case requirements I see for the Enterprise where
it has to be really easy to bind a device to a DNS service. For embedded
devices it has to be 'scan a bar code' level of simplicity.

And I know that we are not talking about those use cases now. And I don't
really want to have to talk about those cases now either. Instead I want to
have a mechanism that can be implemented very simply to meet most of the
use cases and can be extended later as needed.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 27 Oct 2014 15:29:34 +0000

Hi Phillip,

Thanks for your message. I tagged my message with my name since I converted it to text.

TSIG is only authentication so you have to add encryption. And the original TSIG assumed keys would be passed out of band so it needs a key exchange.

[Hosnieh] Yes that is true. It is only authentication. However, CGA-TSIG only used TSIG as a carrier protocol because some people told me that in this case I would need minimum changes to the protocol and like other algorithms, I can only register a new algorithm with IANA for TSIG. Therefore it can be also a separate RDATA however, to avoid compatibility I just did not think about that.

So lets divide the protocol into two parts, a key exchange that establishes a shared secret and some form of packaging that applies encryption and integrity operations to the DNS messages.

[Hosnieh] True. 

The second part is straightforward. People can agree or disagree as to whether my attempts to optimize the transport for DNS deliver worthwhile benefits, we can argue over the specific encoding (I picked the TLS schema). But what is clear is that it should be very simple to describe and implement or its being done wrong.

[Hosnieh] but for TLS you probably need to have CA or preconfigured your nodes with the list of trusted anchor. This is why I thought this binding would help to minimal configuration.

The key exchange is the place where the design choices come in. And here we have two approaches:

I believe the second course is the best approach in this case. I am not re-inventing the TLS crypto but I am presenting it as a JSON web service in a way that allows for reuse.

CGA does not meet the use case requirements I see for the Enterprise where it has to be really easy to bind a device to a DNS service. For embedded devices it has to be 'scan a bar code' level of simplicity. 

[Hosnieh] It is possible that use simply a hash of (IP + key), like the networks that doesn't support CGA or SSAS or like IPv4 scenario in CGA-TSIG. Sorry that CGA-tSIG name is a bit misleading and the first interpretation of this draft is the use of CGA. However, CGA is only one of possible mechanism introduced in the draft. 

And I know that we are not talking about those use cases now. And I don't really want to have to talk about those cases now either. Instead I want to have a mechanism that can be implemented very simply to meet most of the use cases and can be extended later as needed.

[Hosnieh] Do you have any suggestion for a simple implementations such as some required factors for implementations? I don't know how much this group would like to think about operational cases. 

Thanks,
Best,
Hosnieh

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 27 Oct 2014 23:30:27 -0700

CGA-TSIG is a possible solution to the "secure-provisioning" problem. The IPv6 CGA address contains a hash of a public key used to secure the service. If the address is provisioned in a secure manner, then the client can authenticate the resolver, by verifying that the resolver's certificate matches the hash in the IPv6 address. I am not sure that this is the best solution, but it is certainly more secure than pointing the resolver to "8.8.8.8" and later observing that this is in fact rerouted to the Turkish police.

This kind of provisioning is a tradeoff. The main advantage is to not create a new provisioning channel. No need to be bothered with entering a certificate, entering the address suffices. But of course the flip side is that it only works if we update the DNS client and the resolver. If we do change the client and resolver, a number of alternatives can be used, such as:

* Use the same trick as CGA but encode the hash of the certificate as a name part, e.g. "AF4563ED0B561.example.com". This is probably easier to use than CGA, because names are less restricted than addresses. 
* Use Secure DNS, or DANE, to verify the resolver certificate.

Both of these approaches have the same property of reusing an existing provisioning channel. The DANE approach is probably easier to manage, because both the "hash in the address" and "hash in the name" approaches have a hard time dealing with certificate renewal.

But, yes, solving the "secure provisioning" issue would be nice.

-- Christian Huitema

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 28 Oct 2014 10:07:18 +0000

Hi Christian,

Thanks for sharing your opinion about current approaches and also CGA-TSIG.

> If we do change the client and resolver, a number of alternatives can
> be used, such as:
> 
> * Use the same trick as CGA but encode the hash of the certificate as a
> name part, e.g. "AF4563ED0B561.example.com". This is probably easier to
> use than CGA, because names are less restricted than addresses.

True, This is to some extend prevents exposing information and I think this is how NSEC3 works. 
But do you think it is applicable for resolver scenario. I think in this case we have two scenarios

1- client sends a plain text to resolver, resolver can respond to client with hashing the whole query. IN other words the whole www.example.com can be hashed and resolver can respond to the client by sending abcabcabcabc.
In this case, if people here are worry about plain text, then the plain text is already exposed in client's request.

2- client cannot hash all its query. This is because the resolver does not know then what is the content of its query so that it can ask the right authoritative server. Therefore only the first scenario can happen that it still might expose information.

> Both of these approaches have the same property of reusing an existing
> provisioning channel. The DANE approach is probably easier to manage,
> because both the "hash in the address" and "hash in the name"
> approaches have a hard time dealing with certificate renewal.

DANE might be ideal for some scenarios but I think for this scenario where we are talking about last miles of the internet (end users), the pre-configuration of clients with trusted anchor/s for certain domain might not allow unknown nodes to use this service or administrative overheads. Because a node might also move from one network to another.  This is why I thought CGA-TSIG can be helpful in such scenarios. I again do not claim that it is the best approach but I think it reduces many required configuration.
About generating new keys (dealing with certificate renewal), I also thought about an approach and how client or server can inform the other communicating party about the new keys. because in my proposal I tried to considered all possible situation such as dynamic environment where nodes need to change their IP address or their keys. However, I guess for DNS server, changing keys might be a rare case. In other word, what I understands from DANE, clients needs to be configured with the list of trusted anchors for certain domains. While CGA-TSIG need only the IP address of resolver or maximum the hash of public key and IP address (for IPv4).  
This IP address can be received either from Secure RA or from protected DHCP server or even set manually.

Thanks,
Best,
Hosnieh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Oct 2014 09:13:57 -0400

On Tue, Oct 28, 2014 at 2:30 AM, Christian Huitema <[email-masked]>
wrote:

> CGA-TSIG is a possible solution to the "secure-provisioning" problem. The
> IPv6 CGA address contains a hash of a public key used to secure the
> service. If the address is provisioned in a secure manner, then the client
> can authenticate the resolver, by verifying that the resolver's certificate
> matches the hash in the IPv6 address. I am not sure that this is the best
> solution, but it is certainly more secure than pointing the resolver to
> "8.8.8.8" and later observing that this is in fact rerouted to the Turkish
> police.
>
> This kind of provisioning is a tradeoff. The main advantage is to not
> create a new provisioning channel. No need to be bothered with entering a
> certificate, entering the address suffices. But of course the flip side is
> that it only works if we update the DNS client and the resolver. If we do
> change the client and resolver, a number of alternatives can be used, such
> as:
>
> name part, e.g. "AF4563ED0B561.example.com". This is probably easier

It is also potentially more general. I wrote on this in a paper for the IAB
workshop:

http://tools.ietf.org/html/draft-hallambaker-presentation-00

Let us imagine that you are issued a new Surface 10 by Microsoft (lets face
it, all version numbers are now 10). It is a corporate machine so the root
of trust for the machine must be a Microsoft key.

So in the back room somewhere, someone has taken out the Microsoft root of
roots and signed 'stuff' that interests Microsoft, like the ICANN DNS root
and the CA roots installed in the browser. What you would want is to have
that as the ultimate root of trust for everything connected to that device.

So representing this as a DNS label we might get something like the
following:

example.com.xx--49AAC1-1D7B6-F6446-702E5-4A1607-3716

Here I have taken the x?-- prefix convention and allocated a new prefix to
represent a hash. These are in hex but Base32 encoding is obviously a
little better. These are what I call strong DNS names.

Note that we only need a 128 bit hash for this particular application
because the birthday attack does not apply.

It is a very clean and a very general means of encoding root anchors and
ensuring that there is close control on the trust.

So lets imagine that in .NET there is a stream class 'NetworkStream' with
the following constructors:

NetworkStream (string Domain, string Service) // SRV service discovery
NetworkStream (string Domain, int Port) // Well known port discovery

If we give these constructors a strong name, we can in principle use it to
construct a secure channel to the selected endpoint that does not depend on
any additional root of trust.

One consequence of this approach is that it potentially makes network
administration a lot simpler because all that you need is a domain name.

Now before everyone starts breaking out the champagne because us CAs 'go
away'. This is only true if you never need to go outside your own domain
and never need to establish yourself as trustworthy externally.

What it does mean though is that example.com could set up an internal Web
service client that is guaranteed to only accept certs that were issued by
the example.com CA directly or by a CA that example.com had cross
certified. This would seem to be an excellent security approach for a
nuclear power station.