Subject: [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-02.txt

From: Daniel Migault <[email-masked]>
Date: Mon, 21 Oct 2013 09:19:11 +0200

Hi,

Please find a draft that defines DHCP options to provision DNSSEC
validators so DNSSEC validation can always be performed.

Feel free to make any comments. I would be happy to have f2f discussion
during IETF88 to solve this issue with a more complete document.

Best Regards,
Daniel

URL:
http://www.ietf.org/internet-drafts/draft-mglt-homenet-dnssec-validator-dhc-options-02.txt

Abstract:
   DNSSEC provides data integrity and authentication for DNSSEC
   validators.  However, without valid trust anchor(s) and an acceptable
   value for the current time, DNSSEC validation cannot be performed.
   As a result, there are multiple cases where DNSSEC validation MUST
   NOT be performed.  In addition, this list of exceptions is expected
   to become larger over time.

   Considering an increasing number of cases where DNSSEC is disabled
   adds complexity to the DNSSEC validator implementations and increases
   the vectors that disable security.

   This document assumes that DNSSEC adoption by end devices requires
   that end devices MUST be able to support a DNSSEC validation always
   set.  This MUST be valid today as well as in the future.

   This document describes DHCP Options to provision the DHCP Client
   with valid trust anchors and time so DNSSEC validation can be
   performed.

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.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Oct 21, 2013 at 9:12 AM
Subject: New Version Notification for
draft-mglt-homenet-dnssec-validator-dhc-options-02.txt
To: Daniel Migault <[email-masked]>

A new version of I-D, draft-mglt-homenet-dnssec-validator-dhc-options-02.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename:        draft-mglt-homenet-dnssec-validator-dhc-options
Revision:        02
Title:           DNSSEC Validators DHCP Options
Creation date:   2013-10-21
Group:           Individual Submission
Number of pages: 12
URL:
http://www.ietf.org/internet-drafts/draft-mglt-homenet-dnssec-validator-dhc-options-02.txt
Status:
http://datatracker.ietf.org/doc/draft-mglt-homenet-dnssec-validator-dhc-options
Htmlized:
http://tools.ietf.org/html/draft-mglt-homenet-dnssec-validator-dhc-options-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-dnssec-validator-dhc-options-02

Abstract:
   DNSSEC provides data integrity and authentication for DNSSEC
   validators.  However, without valid trust anchor(s) and an acceptable
   value for the current time, DNSSEC validation cannot be performed.
   As a result, there are multiple cases where DNSSEC validation MUST
   NOT be performed.  In addition, this list of exceptions is expected
   to become larger over time.

   Considering an increasing number of cases where DNSSEC is disabled
   adds complexity to the DNSSEC validator implementations and increases
   the vectors that disable security.

   This document assumes that DNSSEC adoption by end devices requires
   that end devices MUST be able to support a DNSSEC validation always
   set.  This MUST be valid today as well as in the future.

   This document describes DHCP Options to provision the DHCP Client
   with valid trust anchors and time so DNSSEC validation can be
   performed.

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

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Oct 2013 14:16:07 -0400 (EDT)

On Mon, 21 Oct 2013, Daniel Migault wrote:

> Please find a draft that defines DHCP options to provision DNSSEC validators so DNSSEC
> validation can always be performed.
> 
> Feel free to make any comments. I would be happy to have f2f discussion during IETF88 to solve
> this issue with a more complete document.

I am a little worried to bring this into the DHCP layer. While the
document makes statements about only accepting trust anchors when
the DHCP server is "trusted", when thinking about CPE equipment, old
handhelds, etc, there is no such trust relationship. (I'm also not very
familiar with what a "trust relationship" is between a DHCP server and
client?)

I'm also a little nervous about using certificates to kickstart dnssec and
time, especially because it just moves the problem to certificate validity
times. When not under attack, it's much simpler to insecurely query for
the root key and use that key for an initial time setting as well.

For CPE devices, I think querying for the root key without dnssec to
use as time and possible TA is something it could possibly prompt the
user for. It would work without DHCP and not require new DHCP options.
CPE devices could also insecurely query for the proper ICANN website and
grab the trust anchor bundle (i.e. what unbound-anchor does) and use the
certificate of ICANN.

For enterprise devices, I would assume that an unfiltered internet
connection is not available (firewalled, etc) so it might need something
else. However, there is likely good reason to have trust in the LAN,
and a time estimate could be obtained from the NTP server through DHCP
(option 42 could provide an IP address for one entry, therefor removing
the need for DNS to obtain NTP)

I do see a need to transfer DNSSEC TA's once we see split-view DNS where
at the very least the public view is signed and there is a "lie" for an
internal only zone that needs to be believed. I am not sure how those
should get authenticated though. I wouldn't want my device to accept a
rogue trust anchor and a DNS forwarder to use and take over all my DNS.

So I do think we need OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. I'm less sure
about OPTION_DNSSEC_CERT_TRUST_ANCHOR.

OPTION_TIME seems like a good addition but I'm also afraid of this being
used in combination with a (fixed) registrar/registry compromise to
replay old DNSSEC signed records. It should only be honoured by devices
that are known to be in a timless tate (eg if its 1970).

A discussion would be very helpful to talk about the various security
implications, and to ensure that we can keep the differences between
DHCP and IKEv2 options for VPN as small as possible.

Paul

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Oct 2013 14:27:20 -0400

> grab the trust anchor bundle (i.e. what unbound-anchor does) and use the

See also draft-jabley-dnsop-validator-bootstrap-00.

Joe

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Oct 2013 10:42:08 +0100

> familiar with what a "trust relationship" is between a DHCP server and

The draft talks vaguely about IPSEC, which immediately sets off my wishful
thinking alarm bells and reminds me of 1990s security considerations
sections. More specifically, how is the client supposed to set up a
security association with the DHCP server when it doesn't have an IP
address? This is supposed to help with bootstrapping, right? How can the
client bootstrap its trust in the DHCP server in a way that is less likely
to expire than the root trust anchor?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 22 Oct 2013 14:40:16 +0200

Hi Paul,

Thanks for your comments. I also share your opinions. I add my comment in
the body part.

On Mon, Oct 21, 2013 at 8:16 PM, Paul Wouters <[email-masked]> wrote:

>> during IETF88 to solve

By trusted relationship, I wanted to clarify that authenticating the DHCP
Server is not sufficient. The Client MUST trust the DHCP Server. More
specifically, when you are in a corporate network you assume you are in a
trusted network, so you trust information from your DHCP Server. On the
contrary, in a cyber café, even if you authenticate the DHCP Server as the
one of the cybercafé, you do not necessarily trust it to the point to
accept crucial information.

Practically, this means that these Options must be 1) considered cautiously
by the DHCP Client and 2) "only" when they are provided by trusted
networks, that is mostly the corporate network, or the DSL line at home.

One reason I posted the draft in the homenet WG instead of DNSOP is that
the DHCP Options may not apply to devices connected to different untrusted
networks. More specifically, a mobile WiFi device in your pocket that wakes
up every months/years may not use these options unless they are at home.

> Thanks, this point has not been addressed in the draft.

The reason to use certificate is that ISP will not deploy DNSSEC in DSL
boxes, if they have no way to push securely the valid KSKs.  I saw
certificate as one way to provide authenticated information, and this
information can be provided over untrusted/unsecured/unauthenticated
channels.
True that if the device is desynchronized, signature checks  cannot be
performed neither for DNSSEC nor for certificates. To use certificates the
device needs a valid CA and a proper time. If the device is desynchronize,
it should use the time value provided by the DHCP Time Option. This only
works if provided by a trusted DHCP Server. As a result, for a
desynchronized device it may not provide any advantages, and sending the
KSK insecurely is much simpler.

The question is then for desynchronized devices, does it worth protecting
the KSKs with certificate, if one parameter (the time) is not
authenticated.

> grab the trust anchor bundle (i.e. what unbound-anchor does) and use the
That is definitely one way to get the root key. What we propose by
providing the certificate with the KSK is very similar. The only difference
is that the CA may not be only the one the ICANN but can also be the one of
third parties like the ISP. In both cases, CA have to be provisioned in the
devices, and the device is expected to perform signature checks, so we have
the same issues as above.
The big issues I see are:
    1) It only applies to the Root Key. Which means the CPE cannot recover
for example from TLD that had an emergency roll over. In addition the Root
Key is probably the one that is mostly unlikely to have issues with
emergency roll over. Most of these issues are expected to happen with other
subzones.
    2) If does not provide the ISP to mitigate a key roll over issue
performed on the Internet. If a problem occurs, the end user will not call
ICANN.

> the need for DNS to obtain NTP)
Good point, providing IP addresses makes DHCP Time Option unnecessary.
Difference between ntp client vs DHCP Options is that using ntp client adds
round trip, and requires the ntp client to be installed. If that does not
cause any problems, then we should use option 42.

> So I do think we need OPTION_DNSSEC_KSK_RR_TRUST_**ANCHOR. I'm less sure
> about OPTION_DNSSEC_CERT_TRUST_**ANCHOR.
>
>
I see your point with split-views. I should add this to the draft. I agree
that CERT may not be very useful in LAN or trusted environment. On the
other hand it would really help that ISPs can provision the devices with
KSKs and authenticate them. In addition I would like also a standard way to
store KSK in certificate. The format adopted for the Root Zone seems very
specific to the root zone.

> I am not sure we should consider these devices, maybe sensors or IoT have
different ideas on supporting ntp client. I feel using NTP is much better.

> DHCP and IKEv2 options for VPN as small as possible.

Definitely. I have not mentioned VPN use cases, but we should consider this
case with more attention. Wen you say "as small as possible" do you mean
that we should also define new CP attributes? I am sure I must
misunderstood something, but I expect the VPN client to get the DHCP Server
address from the security gateway(INTERNAL_*_DHCP) and from that the client
sends the ORO to the DHCP Sever.

Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Daniel Migault <[email-masked]>
Date: Tue, 22 Oct 2013 14:49:31 +0200

Hi Joe,

Thank you for your comment. draft-jabley-dnsop-validator-
bootstrap-00 is mentioned in the draft. We would like to extend this to
other non root KSKs. Otherwise we do not see contradictions with what is
mentioned in draft-jabley-dnsop-validator-bootstrap-00.
As mentionned "[...] and believe the principle described in these documents
[ draft-jabley-dnsop-validator-bootstrap-00, and
I-D.jabley-dnssec-trust-anchor] SHOULD be applied by the validators".

Best Regards,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Daniel Migault <[email-masked]>
Date: Tue, 22 Oct 2013 15:36:33 +0200

Hi Tony,

Thank you for your comment.

Maybe I should clarify this: Authentication of DHCP messages between the
DHCP Client and the DHCP Server is accomplished through the use of the
Authentication option. IPsec can be used between DHCP Relays and DHCP
Servers. We also need to clarify how IPsec and DHCP interact in the case of
remote VPN clients.

You are right saying root KSK is probably better managed than any other
KSKs as well as other trusted communications. But 1) we are not only
concerned by the root KSK. The root KSK is crucial for DNSSEC, however, it
is not the only cause of failures. Other KSKs may also provide DNSSEC
validation failures. 2) we have no control on KSK operations.

As I mentioned earlier, in the case of the root zone end users whose DNSSEC
validation fails will not call IANA, but our hot lines.
The key difference between the DHCP bootstrap and DNSSEC boostrap is that
ISPs have no influence on DNSSEC key roll overs, whereas we manage DHCP
Server bootstrap.

Best Regards,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 09:51:15 -0400

On Oct 22, 2013, at 8:40 AM, Daniel Migault <[email-masked]> wrote:
> By trusted relationship, I wanted to clarify that authenticating the DHCP Server is not sufficient. The Client MUST trust the DHCP Server. More specifically, when you are in a corporate network you assume you are in a trusted network, so you trust information from your DHCP Server. On the contrary, in a cyber café, even if you authenticate the DHCP Server as the one of the cybercafé, you do not necessarily trust it to the point to accept crucial information. 

But this is absolutely crucial.   How do you know that you are on a trusted network?   The document doesn't say.   DHCP is supposed to be zero-touch.   If we have to set up a DHCP security association in order to be able to trust the DHCP server to tell us what the DNSSEC trust anchors are, why not skip that step and install the trust anchors?

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Oct 2013 11:57:34 -0400 (EDT)

On Tue, 22 Oct 2013, Daniel Migault wrote:

> By trusted relationship, I wanted to clarify that authenticating the DHCP Server is not sufficient. The Client
> MUST trust the DHCP Server. More specifically, when you are in a corporate network you assume you are in a
> trusted network, so you trust information from your DHCP Server. On the contrary, in a cyber café, even if you
> authenticate the DHCP Server as the one of the cybercafé, you do not necessarily trust it to the point to accept
> crucial information.

I'm not sure I agree. When I am in a corporate network, I don't want it
to give me trust anchors for nohats.ca regardless. It does not matter to
me whether it is a large enterprise or a starbucks wifi.

I think at most, it should be allowed to give me a trust anchor for the
domain option it gives me, meaning to re-arrange trust for the LAN I
just entered. Although that moves the security issue to when I should or
should not accept a domain option from DHCP. I still don't want
starbucks to give me a nohats.ca search domain and modify its trust
anchor.

> Practically, this means that these Options must be 1) considered cautiously by the DHCP Client and 2) "only" when
> they are provided by trusted networks, that is mostly the corporate network, or the DSL line at home. 

That would require marking networks as "trusted" in your network manager
program by the end user.

> The reason to use certificate is that ISP will not deploy DNSSEC in DSL boxes, if they have no way to push
> securely the valid KSKs. 

I _really_ don't want ISPs pushing trust anchors. Enterprise LAN setups,
home networks, sure. But not random hotspots or random ISPs. DNSSEC
deployment _protects_ me from bad ISPs (like Rogers Canada) who mangle
the DNS for me with "sitefinder" like ads. There have been ISPs with poisoned
caches or malicious employees trying to get adviews. ISPs can and should
provide a DNS caching resolver I can use, but they cannot be trusted to
set any DNSSEC trust anchor.

> I saw certificate as one way to provide authenticated information, and this information
> can be provided over untrusted/unsecured/unauthenticated channels.
> True that if the device is desynchronized, signature checks  cannot be performed neither for DNSSEC nor for
> certificates. To use certificates the device needs a valid CA and a proper time. If the device is desynchronize,
> it should use the time value provided by the DHCP Time Option. This only works if provided by a trusted DHCP
> Server. As a result, for a desynchronized device it may not provide any advantages, and sending the KSK
> insecurely is much simpler.

But if the client needs that much certificate processing capability, why
not just have the client do that straight against the ICANN pem bundle?
That works better too if the device changes hands (as old devices often
do)

The only reason I see here is to have corporate issued devices take on
the non-public corporate trust anchors. I don't think enterprise device
management needs an internet protocol. They should just grab the device
and bring it up to date with its OS/firmware before redeploying it on
their internal network. You shouldn't be deploying unpatched years-old
devices on a corporate lan anyway.

>     1) It only applies to the Root Key. Which means the CPE cannot recover for example from TLD that had an
> emergency roll over.

But the root key is special. for all other emergency rollovers, flush
your DNS cache and try again?

>     2) If does not provide the ISP to mitigate a key roll over issue performed on the Internet. If a problem
> occurs, the end user will not call ICANN.

They should call Microsoft, Apple, Google, or their Linux vendor
instead. Giving ISPs so much trust power to override an enduser's trust
anchors is just not safe.

> Difference between ntp client vs DHCP Options is that using ntp client adds round trip, and requires the ntp
> client to be installed. If that does not cause any problems, then we should use option 42.

Even most cheap $30 wifi/routers have ntp these days. the only category
that might not have it is the "internet of things" kind of devices. But
those would not use DNS(SEC) either I think.

> I see your point with split-views.

which I think is really the most important trust anchor hand-over to
deal with. And your draft might be used for that!

> I should add this to the draft. I agree that CERT may not be very useful in
> LAN or trusted environment. On the other hand it would really help that ISPs can provision the devices with KSKs
> and authenticate them.

I _really_ don't want ISPs changing trust anchors. We are moving DNSSEC
to the endnode because we cannot trust either the ISPs or the link
between the ISPs and us.

> In addition I would like also a standard way to store KSK in certificate.

While I'm really trying hard to keep DNS in DNS only :)

> Definitely. I have not mentioned VPN use cases, but we should consider this case with more attention. Wen you say
> "as small as possible" do you mean that we should also define new CP attributes? I am sure I must misunderstood
> something, but I expect the VPN client to get the DHCP Server address from the security gateway(INTERNAL_*_DHCP)
> and from that the client sends the ORO to the DHCP Sever.

Each option that we add to DHCP for DNS reconfiguration is an option we
would need to have an IPsec gateway relay via IKE as well to remote
clients so being remote or local ends up with the same DNS configuraion.
Of course, the advantage of IPsec is that it is all authenticated,
unlike DHCP.

Paul