Subject: Re: [dns-privacy] Considering IPsec

From: Daniel Migault <[email-masked]>
Date: Mon, 13 Apr 2015 19:20:36 -0400

Hi Paul,

Thanks for the response. I am just initiating a new tread to avoid mixing
conversations.

On Mon, Apr 13, 2015 at 5:44 PM, Paul Wouters <[email-masked]> wrote:

> On Mon, 13 Apr 2015, Daniel Migault wrote:
>
>  Just for information, what are the technical reasons IPsec has not been
>> considered at all for providing DNS privacy.
>>
>
> People can already use an IPsec VPN and a remote DNS server without
> anything new from IETF?
>

I do not see what prevents securing communications to IP_DNS or FQDN_DNS
with IPsec, either using transport or tunnel mode.

>
> I think additionally, IPsec has a higher barrier to entrance because it
> needs more priviledges to build a system host tunnel as compared to an
> application encryption tunnel like (D)TLS.

This is partly true, especially if you use UDP encapsulation. If you do not
use UDP encapsulation, cannot it be possible to build your packet over a
raw socket. -- but that is right it may be still a bit more difficult.  If
you use the IPsec kernel implementation, then the only disadvantage I would
see is a lake of interactions between the application and the SPD for
alternatively a secured and non-secured DNS.

> Also, IPsec does not yet
> allow the client to remain anonymous - although we're almost done that
> part with draft-ietf-ipsecme-authnull. And you _can_ already use that
> if you support IKE authnull to 193.110.157.123  (although it does not
> yet support one-sided auth where the IKE client verifies the IKE server)
>
> In addition there is also BTNS. RFC5386

> Having an IPsec protected DNS connection is a very good and solid
> solution. But an individual application cannot decide to use such
> encrypted DNS. Using an application based (D)TLS would allow an
> application to make encrypted DNS possible without requiring the system
> core OS to have some support for that.
>
> I see that as the "higher barrier to entrance" you mentioned earlier.

>  The use of IPsec could re-use existing extensions like NAT traversal,
>> compatibility with UDP/TCP, resilience to change of IP
>> addresses... and this without creating new extensions.
>>
>
> But you get those as well using (D)TLS ?
>

Yes of course, but the point is that you need both TLS and DTLS for the
TCP/UDP compatibility.

> Paul

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Apr 2015 19:34:32 -0400 (EDT)

On Mon, 13 Apr 2015, Daniel Migault wrote:

>             Just for information, what are the technical reasons IPsec has not been considered at all for providing DNS
>             privacy.
>
> I do not see what prevents securing communications to IP_DNS or FQDN_DNS with IPsec, either using transport or tunnel mode.

Encrypting is not the problem, authenticating is.

> This is partly true, especially if you use UDP encapsulation. If you do not use UDP encapsulation, cannot it be possible to build your
> packet over a raw socket. -- but that is right it may be still a bit more difficult.  If you use the IPsec kernel implementation, then
> the only disadvantage I would see is a lake of interactions between the application and the SPD for alternatively a secured and
> non-secured DNS.

Yes, people are already unhappy with applications needing dnssec
processing libraries for true validation into the application. Adding an
IPsec stack would be far worse. Also, you would not be able to run IKE
on the regular IKE port, so this quickly becomes far more complicated
than TLS. (and far more complicated than a preconfigured IPsec VPN to 8.8.8.

> In addition there is also BTNS. RFC5386

But BTNS requires kernel changes, and I am not aware of any kernel
implementation of BTNS.

>             The use of IPsec could re-use existing extensions like NAT traversal, compatibility with UDP/TCP, resilience to
>             change of IP
> Yes of course, but the point is that you need both TLS and DTLS for the TCP/UDP compatibility.

I would hope that recursors implementing dprive, would also have long
lived TCP connections, so that we wouldn't need UDP.

Paul

---

From: "Zhiwei Yan" <[email-masked]>
Date: Tue, 14 Apr 2015 09:03:06 +0800

Hi, all,
Then why not consider the DHCP?
DHCP can support client authentication and can be used to configure the RS key on the authenticated client.
Do you think this will help?
Zhiwei Yan

2015-04-14 

Zhiwei Yan 

发件人： Daniel Migault 
发送时间： 2015-04-14  07:20:47 
收件人： Paul Wouters 
抄送： dns-privacy; Daniel Kahn Gillmor; Stephen Farrell 
主题： Re: [dns-privacy] Considering IPsec 
 
Hi Paul, 

Thanks for the response. I am just initiating a new tread to avoid mixing conversations.

Just for information, what are the technical reasons IPsec has not been considered at all for providing DNS privacy.

I think additionally, IPsec has a higher barrier to entrance because it
needs more priviledges to build a system host tunnel as compared to an
application encryption tunnel like (D)TLS. 
This is partly true, especially if you use UDP encapsulation. If you do not use UDP encapsulation, cannot it be possible to build your packet over a raw socket. -- but that is right it may be still a bit more difficult.  If you use the IPsec kernel implementation, then the only disadvantage I would see is a lake of interactions between the application and the SPD for alternatively a secured and non-secured DNS.

Also, IPsec does not yet

The use of IPsec could re-use existing extensions like NAT traversal, compatibility with UDP/TCP, resilience to change of IP
addresses... and this without creating new extensions.

Paul

-- 

Daniel Migault

Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Apr 2015 23:04:10 -0400 (EDT)

> Do you think this will help?

How do you know the DHCP server is not a rogue attacker?
How does the system determine encrypting to the DHCP/DNS server is
guaranteed to not be eavesdropped on?

It depends on if I trust that network (eg my home) or not (eg starbucks)

Paul

---

From: "Zhiwei Yan" <[email-masked]>
Date: Tue, 14 Apr 2015 12:02:24 +0800

RFC 3118 provides a scheme for this issue:
http://www.rfc-base.org/txt/rfc-3118.txt 

2015-04-14 

Zhiwei Yan 

发件人： Paul Wouters 
发送时间： 2015-04-14  11:04:58 
收件人： Zhiwei Yan 
抄送： dns-privacy 
主题： Re: [dns-privacy] Considering DHCP 
 
How do you know the DHCP server is not a rogue attacker?
How does the system determine encrypting to the DHCP/DNS server is
guaranteed to not be eavesdropped on?
It depends on if I trust that network (eg my home) or not (eg starbucks)
Paul
_______________________________________________
dns-privacy mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Melinda Shore <[email-masked]>
Date: Mon, 13 Apr 2015 20:24:56 -0800

> http://www.rfc-base.org/txt/rfc-3118.txt

Authentication addresses the "who are you" question (sort
of) but not the "Can I trust you?" one.  If you're sitting
in an airport terminal and someone offers you an IP address,
even if you know for certain that they're "ohare-free-wifi",
you still don't know whether "ohare-free-wifi" is friend
or foe.

Melinda

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 14 Apr 2015 00:36:23 -0400

[ rearranging for chronological sanity ]

On Tue 2015-04-14 00:02:24 -0400, Zhiwei Yan wrote:
> [ Paul Wouters wrote: ]

Haven't we just pushed the problem off a level then?

It seems you've replaced the problem "how do i choose a trust anchor for
my DNS server" with "how do i choose a trust anchor for my DHCP server"?

And the trust anchor framework described in 3118 is pretty weak compared
to the trust anchor frameworks we have available in TLS (problematic
though some of them may be):

 Key Utilization:
 https://tools.ietf.org/html/rfc3118#section-5.4

 Key Management:
 https://tools.ietf.org/html/rfc3118#page-16

In those scenarios where a trust relationship already exists between a
DHCP client and a DHCP server, sure, we should figure out a way to
distribute DNS resolver trust information as well, once we know what
that looks like (e.g. a DHCP extension containing a SHA256-sum of the
DNS server's subjectPublicKeyInfo would be plausible).  But again, that
seems like a nice thing to have *after* we've sorted out what the DNS
trust anchor looks like in the manually-configured case.

 --dkg

---

From: Linhui Sun <[email-masked]>
Date: Tue, 14 Apr 2015 17:46:12 +0800

HI, Daniel

I think there is no difference when we considering which to do first. If 
the
DHCP could offer a better way, that would be fine. However, there are 
several
problems in the authentication mechanism defined in RFC3118, thus the dhc 
WG
developed another mechanism called secure DHCP ( 
http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/
[http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/] & 
http://datatracker.ietf.org/doc/draft-jiang-dhc-sedhcpv4/
[http://datatracker.ietf.org/doc/draft-jiang-dhc-sedhcpv4/] ) to enhance 
the RFC3118.

I think the key point is whther we could trust a DHCP server just as 
Melinda
mentioned. I'm not sure whether the secure DHCP could solve the "trust" 
problem,
I just provided it here for reference only. If possible, an extension to 
DHCP
may be a good way. Comments are welcome.

Best Regards,
Linhui

2015-04-14 12:36 GMT+08:00 Daniel Kahn Gillmor < [email-masked] 
[[email-masked]] > :
[ rearranging for chronological sanity ]

On Tue 2015-04-14 00:02:24 -0400, Zhiwei Yan wrote:
 >>> DHCP can support client authentication and can be used to configure 
the RS
key on the authenticated client.
 > http://www.rfc-base.org/txt/rfc-3118.txt
[http://www.rfc-base.org/txt/rfc-3118.txt]

Key Utilization:
https://tools.ietf.org/html/rfc3118#section-5.4
[https://tools.ietf.org/html/rfc3118#section-5.4]

Key Management:
https://tools.ietf.org/html/rfc3118#page-16
[https://tools.ietf.org/html/rfc3118#page-16]

--dkg

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

---

From: Zhiwei Yan <[email-masked]>
Date: Tue, 14 Apr 2015 18:54:44 +0800

+1

Best Regards,
Zhiwei Yan

> 在 2015年4月14日，下午5:46，Linhui Sun <[email-masked]> 写道：
> 
> HI, Daniel
> 
> I think there is no difference when we considering which to do first. If the DHCP could offer a better way, that would be fine. However, there are several problems  in the authentication mechanism defined in RFC3118, thus the dhc WG developed another mechanism called secure DHCP (http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ & http://datatracker.ietf.org/doc/draft-jiang-dhc-sedhcpv4/) to enhance the RFC3118.
> 
> I think the key point is whther we could trust a DHCP server just as Melinda mentioned. I'm not sure whether the secure DHCP could solve the "trust" problem, I just provided it here for reference only. If possible, an extension to DHCP may be a good way. Comments are welcome.
> 
> Best Regards,
> Linhui
> 
> 2015-04-14 12:36 GMT+08:00 Daniel Kahn Gillmor <[email-masked]>:

---

From: Zhiwei Yan <[email-masked]>
Date: Tue, 14 Apr 2015 18:57:52 +0800

We should solve two problems:
1) trust problem
2) encryption problem
No matter whether we adopt DHCP, it's better to solve them separately. I mean that it's OK if two solutions are used for these two problems.

Best Regards,
Zhiwei Yan

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Apr 2015 10:33:37 -0400

DNS is an application that runs on a single port between two hosts. In that environment, TLS is always a much more appropriate protection mechanism than IPsec for the numerous reasons PaulW gave.

We don't need to document this decision any more than we need to document every application's choice to use TLS.

--Paul Hoffman

---

From: manning <[email-masked]>
Date: Tue, 14 Apr 2015 10:18:50 -0700

Or…   include the first sentence (with a slight editorial change) in the document.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Apr 2015 13:34:54 -0400

> We don't need to document this decision any more than we need to document every application's choice to use TLS.

DNS is not an application protocol. It is a mapping protocol serving
the presentation and session layers.

That said, all the reasons I am not keen on using TLS apply to IPSEC
which has a vast amount of mechanism for exchanging keys that doesn't
really meet the needs of DNS confidentiality. The only bit that is
useful is the packet format which is a few hours work.