Subject: [homenet] 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: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 08:29:55 -0700

> 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 associat…

Since this is homenet, oughtn't we be thinking in terms of getting 
configuration information
from things that we believe we ought to always trust, like, oh say, a 
server on our home network?
Regardless of our current attachment point(s)?

There's always been a friction between the discovery function of dhcp 
and the configuration
function. Today's roaming -- and the complete inability for us to know 
what we're attached to
at any given time -- brings that into stark relief.

Mike

---

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 12:01:27 -0400

On Oct 22, 2013, at 11:29 AM, Michael Thomas <[email-masked]> wrote:
> Since this is homenet, oughtn't we be thinking in terms of getting configuration information
> from things that we believe we ought to always trust, like, oh say, a server on our home network?

What would the security model be here?   How do we know to trust something on our home network? We pretty much blew this off when we did the architecture document—the general attitude seemed to be "security is hard, so let's do it later."   So while I might agree in the abstract that your proposal makes sense, we have no solution that actually _does_ this.  So mentioning it as an alternative isn't going to get us anywhere.   Of course, we _also_ don't have a security model for the scenario Daniel's draft talks about.   So I would say that both of these solutions are non-starters.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 22 Oct 2013 10:02:24 -0700

On Oct 22, 2013, at 9:01 AM, Ted Lemon <[email-masked]> wrote:

> What would the security model be here?   How do we know to trust something on our home network? We pretty much blew this off when we did the architecture document—the general attitude seemed to be "security is hard, so let's do it later."

I'm not so sure of that, I think there is a lack of broad-based consensus on what balance to attempt, which is not to say that it was blown off, it's not like there was an absence of debate.

>   So while I might agree in the abstract that your proposal makes sense, we have no solution that actually _does_ this.  So mentioning it as an alternative isn't going to get us anywhere.   Of course, we _also_ don't have a security model for the scenario Daniel's draft talks about.   So I would say that both of these solutions are non-starters.

If you come down on the side of relatively unrestrictive homenets one imagines hosts security models treating those as hostile environments.

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 10:06:39 -0700

> What would the security model be here?   How do we know to trust something on our home network? We pretty much blew this off when we did the architecture document—the general attitude seemed to be…

At least there is a security model on my home network, such as it is: wired needs physical
access, wireless needs a password. For roaming, wireless is a closer model. So at least we
have shared credentials.

That's why I keep saying that "Zeroconf" is an illusion. The only way you have wireless zeroconf
is to not have wireless authentication which is pretty boneheaded. Littleconf.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 13:19:44 -0400

> I'm not so sure of that, I think there is a lack of broad-based consensus on what balance to attempt, which is not to say that it was blown off, it's not like there was an absence of debate.

Absolutely.   There was tons of debate!   :)

> If you come down on the side of relatively unrestrictive homenets one imagines hosts security models treating those as hostile environments.

Yes.   Or if that's the kind of homenets that we wind up describing simply because we didn't address the security problem, which I think is the status quo.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 13:22:55 -0400

> access, wireless needs a password. For roaming, wireless is a closer model. So at least we

You have shared credentials with the wrong thing.   They don't serve to authenticate a DHCP packet you receive on the WiFi.   Furthermore, since they are shared, it makes no sense to use them to authenticate the server—everybody on the network by definition knows the password, so anybody can prove that they have it.   Passwords of this sort strictly function to prevent unauthorized access to the network—they can't be used for anything else.

I suppose we could mandate WPA2 enterprise on the homenet, but we still don't have a way to use that to secure the DHCP transaction.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 12:28:56 -0700

> I suppose we could mandate WPA2 enterprise on the homenet, but we still don't have a way to use that to secure the DHCP transaction.
I didn't say anything about DHCP; I was purposefully vague about what a configuration/whatever
protocol ought to be.  I was only pointing out that there already exists a shared credential between
my phone, say, and my home router, say. And you could use the initial contact with the holder of
a shared secret (eg router) to bootstrap a 1:1 key (diffie helman is probably our friend). So you have
an initial leap of faith, but beyond that you're enrolled. No AAA required.

Mike

---

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

On Oct 22, 2013, at 3:28 PM, Michael Thomas <[email-masked]> wrote:
> protocol ought to be.  I was only pointing out that there already exists a shared credential between my phone, say, and my home router, say. And you could use the initial contact with the holder of a shared secret (eg router) to bootstrap a 1:1 key (diffie helman is probably our friend). So you have an initial leap of faith, but beyond that you're enrolled. No AAA required.

The DHCP issue is a red herring.   You don't have a shared secret.   You have a well-known token.  You can't use that to make a leap of faith.

I'm not saying this problem can't be solved, but it won't be solved this way, and it must be solved before we can trust the configuration information we get on the local wire.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 13:01:37 -0700

> I'm not saying this problem can't be solved, but it won't be solved this way, and it must be solved before we can trust the configuration information we get on the local wire.
It's isn't "well known", it's just a group secret. And you certainly could use it to make
a leap of faith: ssh does it without a group secret at all, so it's actually somewhat better:
I at least know that the thing that I'm doing the leap of faith with has knowledge of the
group secret.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 16:08:37 -0400

> I at least know that the thing that I'm doing the leap of faith with has knowledge of the

It's not a secret if it is shared by more than two hosts.   It is a well known token, which is not widely known.   Any device connected to the network can pretend to be the server if you allow that token to be used to authenticate the server.

Ssh has a public/private key pair on the server.   The leap of faith there is based on that key pair, not on a "group secret."

This problem can be solved, but I am strongly opposed to handwaving.   If you want to assert that we can have a secure system, even based on a leap of faith, I do not disagree with that, but you need to tell me what the system _is_.   Otherwise the discussion is completely hypothetical, and we can't draw any real conclusions at all.

So before the working group has any conversations about technologies that depend on a security solution that doesn't yet exist, I would like us to have a security solution upon which to base those technologies.   Until we do, proposals like this one just sound like security snake oil, and we shouldn't be entertaining them.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 13:22:03 -0700

> It's not a secret if it is shared by more than two hosts.   It is a well known token, which is not widely known.   Any device connected to the network can pretend to be the server if you allow that…

Whatever you say. You win.

> Ssh has a public/private key pair on the server.   The leap of faith there is based on that key pair, not on a "group secret."

If you'd pause a moment from winning, I said that requiring knowledge of the group secret
to do the leap of faith is somewhat better than the straight leap of faith that ssh uses.

But we're far afield  from my original point: that I'd rather use a server on my home
network to get my configuration, rather than trusting some random ISP who I happen
to be connected to at any point in time. That doesn't work for roaming, and it's questionable
whether it's an especially good idea even when I'm not.
> So before the working group has any conversations about technologies that depend on a security solution that doesn't yet exist, I would like us to have a security solution upon which to base those…
This is in the context of extant draft not of my making. Are you suggesting that we
shouldn't comment on that draft?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 17:07:22 -0400

> to do the leap of faith is somewhat better than the straight leap of faith that ssh uses.

The public key can be used to authenticate the server in future connections as being the same server that you contacted when you first made the leap of faith.   The "group secret" proves to the server that you know the password to the network, but it can't be used by the network to prove that it is trustworthy.   And there is no additional token, so every time you use that server, you are making the same leap of faith you made the first time.   Leap of faith authentication provides some additional security because you can only attack it the first time it's used—when the leap of faith is made.   If you make a leap of faith every time you connect, that's no different than having no security at all.

> whether it's an especially good idea even when I'm not.

This is the key point: your home network is just a random network to your device, unless you have a secure mechanism for identifying it.   I do agree with your basic point that you can't just trust any random network; what I am trying to point out is there is currently no mechanism we've specified that allows your device to securely distinguish your home network from those other networks.

> Are you suggesting that we shouldn't comment on that draft?

If I wanted to say such an inappropriate thing, I would just say it, and then presumably there would be a recall petition, and I'd be able to go back to being an individual contributor, and my life would get a lot simpler.   I want desperately for the working group to comment on the draft, and I appreciate you commenting.   Please don't take debate from me as implying that you should shut up.   When I accuse you of handwaving, it's because I want you to get specific, not because I want you to shut up.   You're in no way obliged to get specific—that's just what _I_ want.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 14:30:52 -0700

> The public key can be used to authenticate the server in future connections as being the same server that you contacted when you first made the leap of faith.   The "group secret" proves to the ser…

Yes, it just limits the bad guys to those who know that shared secret. I'll leave it
to crypto-heads whether that's enough of an advantage to warrant l2/l3 entanglement
(which is what you really should rip me for :)

> This is the key point: your home network is just a random network to your device, unless you have a secure mechanism for identifying it.   I do agree with your basic point that you can't just trust…

Yes, of course. And it's why zeroconf is incompatible with security: you have to enroll,
and enrollment without checking who you're talking to is insecure. Ssh isn't *really*
zeroconf if you consider it: it asks you first whether you want to take that leap of faith
which requires actually considering the possibility that something bad might happen.

What I'd really like is for my device to "home" itself on a network or server with
my human participation to, like ssh, say "yes, it's ok" because I'm at home on
my wifi when I first bought it, and "no, it's not ok because I'm still at Bestbuy".

Further, I'd say that it really isn't the "Network" that I want to trust, but
some server (or two), probably running on my home network but not necessarily.
In fact, I think we should stop talking about trusting a "network" altogether because
it's really distinct hosts that we ought to trust or not, even if one of those hosts
happens to be my home router (router != "network", of course).

> If I wanted to say such an inappropriate thing, I would just say it, and then presumably there would be a recall petition, and I'd be able to go back to being an individual contributor, and my life…

As far as I can tell, the draft is still ISP-DHCP centric which to my mind is a non-starter,
for many, many reasons. I haven't read the newest version, so apologies if I'm out of date.
I'd suggest to the authors to rethink the entire scheme *without* DHCP, and without any
requirement that there's a link-level relationship to do what they're trying to do: it should
work from the other end of the internet directly addressed with a nice shiny ipv6 address.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 18:39:57 -0400

> (which is what you really should rip me for :)

I think WPA2 Enterprise uses L3 to get the access control information, so we can forgive you for this minor faux pas.   :)

> which requires actually considering the possibility that something bad might happen.

Right.   Minimal touch, not zero-touch.

> my wifi when I first bought it, and "no, it's not ok because I'm still at Bestbuy".

Agreed.   I think this is a good model.   I'd like to see the working group work on something like this (ad hat off).

> happens to be my home router (router != "network", of course).

Yup.

> work from the other end of the internet directly addressed with a nice shiny ipv6 address.

Yeah, I _think_ Daniel is just addressing the provisioning of the customer edge home gateway, not hosts on the homenet.   So in that context it makes a little more sense, but I still think it's problematic in any case where the provider isn't shipping customers devices with custom firmware.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 15:52:36 -0700

> Yeah, I _think_ Daniel is just addressing the provisioning of the customer edge home gateway, not hosts on the homenet.   So in that context it makes a little more sense, but I still think it's pro…
Oh, ok. This goes back to the duality problem with DHCP then (discovery, configuration).
Has anybody ever posited a DHCP configuration-only protocol where you could have
normal transport (ie, not to a broadcast address, you could have, say, (d)TLS, it doesn't
have to be link local, etc, etc)?

Or maybe what they really want is tr-069?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Oct 2013 18:58:52 -0400

> Or maybe what they really want is tr-069?

Doesn't TR-069 use DHCP?

Sheng Jiang has proposed a mechanism for securing DHCP messages using public key encryption.   It's up for discussion in the DHC working group at the moment.

I haven't looked at how to use DTLS to secure DHCP messages.   It would be nice if it were possible.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Oct 2013 16:02:20 -0700

> I haven't looked at how to use DTLS to secure DHCP messages.   It would be nice if it were possible.
Tr-069 is just a plain old tcp protocol afaik. The cpe might use a dhcp option to find
the tr-069 headend though. TR-069 is pretty isp-oriented too, so i doubt they'd have a
problem adding stuff like dnssec roots to their data model.

Mike

---

From: Daniel Migault <[email-masked]>
Date: Wed, 23 Oct 2013 19:06:41 +0200

Hi,

Thanks for all comments. I am doing a small recap. Let me know if I forgot
something. I provide context and questions so people can catch up the
discussion and can comment.

Best Regards,
Daniel

1) Replacing Time Option by the Network Time Protocol (NTP) Server Option
for DHCPv6. [RFC5908]

To avoid DNS request, the Option MUST provide at least an IP addresses.
This option only provides IPv6 addresses. The main advantage is that the
authenticity of the information does not relay anymore on a trusted
relation with the DHCPv6 Server and the DHCPv6 Client, but mechanisms to
authenticate [RFC5906] offers a way for NTP responses to be authenticated.

Issues:
   a) How TA for NTP is provisioned is out of scope of the draft... but it
exists.
   b) We assume that Home Networks are IPv6, but NTP Servers MUST also run
over IPv6. Can we reasonably assume this? If not any proposition for
reusing/encapsulating [RFC2132] option-42 ?

>From then one can assume the device can get time in a secure way and
enables signature checks.
Any remarks on that point?

2) Security Models

I am not sure I have been clear enough on the security model or the use
case I am considering in my draft. I hope I am clarifying this point now.

My device -- say a CPE or smartphone, my PC -- only performs DNSSEC
resolutions, that is to say always perform signature checks, and so MUST
have valid KSKs, even when a emergency key roll over is performed.

Suppose a CPE is attached with a wire connection and performs DNSSEC
validation for my Home Network. Suppose a KSK roll over is performed by
.tld. There are two possibilities:
    - a) information received by the DHCP Server is reliable, valid KSKs
are provided to the CPE via the OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. The CPE
updates its TA, and performs DNSSEC validation.
    - b) information received by the DHCP Server is not reliable. KSK is
authenticated by a trusted authority (CERT). The trusted authority is a
third party. It can be any authority trusted by the CPE.

Suppose a smartphone is  attached to a random WLAN AP and a KSK roll over
is performed by .tld. Updating KSKs is necessary. The smartphone can only
accept KSK validated by a trusted third party. Otherwise it ignores the
KSKs provided by the DHCP Server. One way to update my KSKs is to reach a
trusted network like my Home Network using a VPN for example.

Suppose a smartphone attached to your home network WLAN AP or a wire line.
The attachment is secured with WPA2 for example. The smartphone updates its
KSKs the same way the CPE does it.

Suppose the smartphone is attached to a random WLAN AP. The DHCP Server
provides a KSK for the attached domain. This KSK MUST only be used for that
domain and MUST be removed when the smartphone changes its administrative
domain.

Remarks:
   - a) We need to define what a Trusted DHCP Server is.
   - b) KSKs other than KSKs with local scope are between configuration and
"local" setting for connectivity.
   - c) In case certification authorities are used, we hope that their keys
will be not subject to emergency key roll over.

Do these scenarios address the security model and clarify the scope of the
draft ?

3) Trust DHCP Server

The draft assumes a trust relation between a DHCP Server and a DHCP Client.
Removing the Time Option reduces the necessity of this requirements. I
assumed there are different relations between DHCP Client and Servers: When
you receive an information from the DHCP Server two things matters:
    - a) Do you trust the DHCP Server = information emitted by the DHCP
Server
    - b) Do you trust the information you receive =  can anyone on path
modify this information?

Suppose you have no alternate way to check the information, like receiving
the OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. It is important that you answer YES
to a) and b) if the DHCP Server provides information (TA) that modify the
settings of the device. Note also that security protocols help to address
b) but not a). Thus a) requires a configuration settings or interaction
with the end user.

All DHCP Servers are not the same and I consider two categories: Those you
trust information you get from and those you don't. You might share a key
with some, not with others and you might have different policies for each
category. In any cases long term TA like TLD TA, Root TA that modify the
settings of the devices MUST NOT be considered if a and b are not met.

Is that fine we consider these two categories: Trusted DHCP / Untrusted
DHCP?

A YES means OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR may be used for TLD TA, Root
TA. A NO means that OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR MUST only carry TA
with a local scope (like for the split zone).

4) What are the trusted networks?

Home and corporate networks may be considered as trusted network. There are
different way to define you are in a trusted network:
    - Ask the user
    - Authenticate the DHCP Server
    - other ways ??

5) CERT for KSKs

It seems that some do not like the idea that KSKs are provided via CERT.
First, I agree we should find a CA that is almost unlikely to perform key
roll over. Then, a "KSKs TA office" may be created ;-). It does not exist
yet, so I mentioned ISPs in my draft, but I could have specified any third
party. I have no problem with that.

Any remarks on the use of CERT for KSKs ?

On Wed, Oct 23, 2013 at 1:02 AM, Michael Thomas <[email-masked]> wrote:

>> Sheng Jiang has proposed a mechanism for securing DHCP messages using
>> public key encryption.   It's up for discussion in the DHC working group at
>> the moment.
>>
> ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Oct 2013 14:03:17 -0400 (EDT)

On Wed, 23 Oct 2013, Daniel Migault wrote:

> 2) Security Models
> 
> I am not sure I have been clear enough on the security model or the use case
> I am considering in my draft. I hope I am clarifying this point now.
> 

I am not sure if you need to address emergency rollovers. There are ways
using prepublishing of future KSKs to address emergency rollovers. CPE's
don't need to know anything about that. You are adding to confusion by
using "rollover" and not "emergency rollover" below. Rollovers cause no
problems. Well prepared emergency rollovers cause no problem. Badly done
emergency rollovers cause inevitable problems for everyone.

> .tld. There are two possibilities:

There should be no issue for the CPE. A proper DS will be in the root
for the old and new key before they roll. It can validate signatures
from the old and the new key. When it rolls, there is no problem.

The big problem for CPE's is when they miss a root key rollover because
they were on the shelve for a few years.

>     - a) information received by the DHCP Server is reliable, 
>     - b) information received by the DHCP Server is not reliable.

If this truly is an emergency rollover that was ill prepared, than the
DHCP server is in the same boat at the CPE. No one has the right
information. At best you can flush your entire cache and hope DS record
at the parent (or root) is valid.

> Suppose a smartphone is  attached to a random WLAN AP and a KSK roll over is
> performed by .tld. Updating KSKs is necessary.

No it's not. See http://tools.ietf.org/html/rfc6781

> KSKs the same way the CPE does it.

Didn't you just move the problem from the phone to the CPE. Where does
the CPE get its update from. How can the CPE trust it? And why can't the
phone use the same method?

> domain and MUST be removed when the smartphone changes its administrative

Right. Now this is the REAL problem that you might be able to solve with
DHCP. You enter a split-dns view and the network uses a DNS domain that
is not visible in the public view. The smartphone cannot resolve down
from its trusted root key to validate this domain. The smartphone and
the DHCP server have to agree on a "DNS lie". How to authenticate that?

The problem is, the dns domain relayed itself insecurely. Let's say my
phone uses some non-FQDN like "mail". When a DHCP network tells me the
current LAN domain is "google.com", they can intercept my mail meant to
go to google (We have TLS to protect us currently) 
Worse, if they can convey a trust anchor for "google.com" then they
could potentially MITM all my real google connections. (Imagine they
put their own TLS key in their local "google.cmo" TLSA record)

So if you want to convey a KSK for a dns domain, you need to establish
some way for the phone to be able to agree to the domain and trust
anchor. Let's assume that the transport is secure (like WPA2 enterprise
or whatever) - how does the phone make a choice about the vaildity of
the dns dmain received. And when it does, then it can also decide to
temporarilly trust that trust anchor.

The "temporarilly" bit is done by flushing the cache, which you must do
anyway. For example, when I use my VPN to connect to redhat.com, the VPN
reconfigures my DNS for "redhat.com" to point to a 10.a.b.c DNS server.
I can now resolve internal-only redhat.com names. But also, other DNS
names just get their internap IP. bugzilla.redhat.com gets an internal
IP address. When I disconnect, I need to access bugzilla.redhat.com by
its external IP. Therefor, the VPN software (openswan/libreswan) and
NetworkManager (for openvpn/vpnc) flush the cache and request-list
whenever the VPN comes up or goes down.

>    - a) We need to define what a Trusted DHCP Server is.

Yes. I would try something like "one you physically connect to, or use a
password for (eg wireless)". By connecting to such a network, the user
implicitely conveys trust in the dhcp server. (however, it should still
do due diligene before accepting random domains and trust anchors but I
don't know how it can do that)

> "local" setting for connectivity.

I think KSKs other that local scope should never be considered with a
possible acception of the root trust anchor.

> Removing the Time Option reduces the necessity of this requirements.

Not realy. See above example of a rogue network telling me it is
"google.com".

> party. I have no problem with that.

It creates the same problem the root key has. Now you have two such
problems.

Paul