Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6?

From: Feng Hao <[email-masked]>
Date: Thu, 1 Sep 2016 08:48:47 +0000

Maybe PAKE could be useful here for bootstrapping the initial trust?

If no password is used (i.e., empty password), it works essentially the same as TOFU (so backward compatible). In other cases (non-empty password), you get better assurance of security and the authentication is based on the knowledge of a secret password. This is arguably more convenient than checking the server key fingerprint (which is long and difficult to remember).

Cheers,
Feng

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: 01 September 2016 06:59
To: Viktor Dukhovni <[email-masked]>
Cc: Security Area Advisory Group <[email-masked]>
Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6?

[ moving this back to saag.  multiple escalations are too much
  for me ]

> When uses TOFU for SSH to a small set of servers, or to connect to a 
> small, mostly stable set of networks, it can be a reasonable fit.

ssh referrs to this as a "leap of faith," (which n weaver prefers to my gmobd) not authentication.  users are strongly advised not to go there.

otoh, if you get the target host's ssh key fingerprints out of band, you have whatever level of authenticity the out of band mechanism has.

randy

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 1 Sep 2016 04:53:53 -0400

> On Sep 1, 2016, at 1:58 AM, Randy Bush <[email-masked]> wrote:
> 
> ssh referrs to this as a "leap of faith," (which n weaver
> prefers to my gmobd) not authentication.  users are strongly
> advised not to go there.

And yet, users do just that, and are better off for it, than
using unencrypted telnet.

> otoh, if you get the target host's ssh key fingerprints out of
> band, you have whatever level of authenticity the out of band
> mechanism has.

Nobody is claiming that LoF/TOFU opportunistic security is
magically immune to attacks on the initial association, or
that these scale to a large and/or dynamic set of peers.

What is reasonable to claim, is that just as SSH with
LoF/TOFU is generally stronger than cleartext telnet,
DHCP may LoF/TOFU may likewise benefit users.

It seems your objection is opportunistic security generally,
rather than its application to DHCP.  I am not surprised
that this is case, we are acculturated to not accepting
less than complete security, and thus often choose to give
users nothing because we can't give them everything.

A productive path forward in this case would be put the
abstract objection aside, and ponder whether TOFU is
a reasonable option for users who want some assurance
that when they return to a frequently used network, they
are not instead unwittingly joining some other hostile
network.

While Boingo and the like are well positioned to get
CA certificates (perhaps even EV certs), it is much less
likely to happen with various home networks, ...

The question then becomes one of user experience.
Specifically, whether TOFU failures due to changing keys
are inevitably going to train users to ignore all failures,
and thus negate any benefit they might derive from cached
keys.

If DHCP never carries confidential traffic (so passive
eavesdropping is not at issue) and thus might only
be useful against active attacks, it is possible that
DHCP might not be a good fit for O/S if overly frequent
exceptions train users to ignore security warnings...

So bottom line, I think that the *applicability*
question for O/S to DHCP warrants some thought,
beyond reflexive distaste for opportunistic security.

Opportunistic security works when it is not intrusive, and
raises few false alarms.  It fails when it routinely gets
in the way and is of low value to the user.

-- 
	Viktor.

---

From: Lishan Li <[email-masked]>
Date: Thu, 1 Sep 2016 21:42:31 +0800

Dear Randy,

Sure, Tofu is not as good as one might desire. However, currenly, there is
no
anything else which is more likely to be deployed. This issue has troubled
the
draft for one year. And DHC WG needs some work for DHCP security and want
this
work move forward as soon as possible.

So, I think that we should now focus on specifying something than can be
deployed
easily, such as tofu. If we find something elas which is better than tofu
in the
future, we can specify a new work to state it.

What do you think of it? Thanks a lot for your continuous help and guidance.

Best Regards,
Lishan

2016-09-01 13:58 GMT+08:00 Randy Bush <[email-masked]>:

> > When uses TOFU for SSH to a small set of servers, or to connect
> > to a small, mostly stable set of networks, it can be a reasonable
> > fit.
>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 1 Sep 2016 06:58:38 -0700

> and thus negate any benefit they might derive from cached
If changing keys occurs with any frequency you're going to be beset by a
lot more notifications that are not associated with bad actors then
those that are. What is one's alternative to clicking through such a
warning and proceeding?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 17:06:32 +0000

You don't.   All you know is "this is the same server that worked last time."   The question is, in the case of DHCP, is that a useful piece of data?   I think it is; I'm certainly interested in hearing arguments that it is not.   E.g., does using that information make us _more_ vulnerable in some way we haven't thought of?   Does it not _really_ make us less vulnerable?   It would be helpful if these questions could be addressed.
________________________________________
From: Salz, Rich [[email-masked]]
Sent: Wednesday, August 31, 2016 22:07
To: Lishan Li; Randy Bush
Cc: JINMEI Tatuya; [email-masked]; Ted Lemon
Subject: RE: [saag] Whether TOFU should be considered in secure DHCPv6?

> In my initial thought, tofu is one method to achieve authentication. Looking forward to your further guidance.-

Authentication is:  you connect to something, and verify that the identity it gives you is the one you expect.  For example, the DNS name in a certificate, when properly presented by a web server, allows you to authenticate that server.

In TOFU, how are you verifying the identity of the server? For example, with SSH, unless you have out-of-band verification of the server's SSH key, you have no idea if the server you are connected to is the one you want to connect to.

TOFU gives you "well if you come  back here, you're coming back to the same entity you first came to."  But how do I know that it's really Randy Bush's server, and not his evil twin Randy Shrub?

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 1 Sep 2016 13:27:24 -0400

> On Sep 1, 2016, at 9:58 AM, joel jaeggli <[email-masked]> wrote:
> 

This, finally, is the essential question!

One might only enable key pinning for a few selected networks,
where one reasonably either long-term key stability or some
way of knowing that the key is scheduled to change.

The specification might recommend that DHCP clients not
do key pinning by default, and only do so when the user
asks for it, and has been suitably warned to not use the
feature indiscriminately.

One might also design-in a mechanism for signed
key rotation, along the lines of the TACK proposal, and
thereby further reduce the chance of false alarms, because
the few networks the user does visit frequently and verify
will be able to transparently roll-over their authentication
keys.

If one gets this wrong, the feature might not be better
than nothing, and might just give security a bad name.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 1 Sep 2016 18:09:11 +0000

> You don't.   All you know is "this is the same server that worked last time."
> The question is, in the case of DHCP, is that a useful piece of data?   I think it
> is; I'm certainly interested in hearing arguments that it is not.   E.g., does
> using that information make us _more_ vulnerable in some way we haven't
> thought of?   Does it not _really_ make us less vulnerable?   It would be
> helpful if these questions could be addressed.

I agree that knowing "this is the same server as last time" is useful.  More importantly, knowing "this is not the same server as last time" is perhaps more useful (evil coffee shop scenario).

Is it an improvement? I think so, but perhaps it's a "two steps forward, one step back" kind of thing.  On the other hand, an enterprise being able to configure it's DHCP server in the workstations it gives out is a nice hook to have.

> Authentication is:  you connect to something, and verify that the identity it
> gives you is the one you expect.  For example, the DNS name in a certificate,
> when properly presented by a web server, allows you to authenticate that
> server.
> 
> In TOFU, how are you verifying the identity of the server? For example, with
> SSH, unless you have out-of-band verification of the server's SSH key, you
> have no idea if the server you are connected to is the one you want to
> connect to.
> 
> TOFU gives you "well if you come  back here, you're coming back to the same
> entity you first came to."  But how do I know that it's really Randy Bush's
> server, and not his evil twin Randy Shrub?
> 
> --

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Sep 2016 06:44:39 +0900

> Sure, Tofu is not as good as one might desire.

we know what tofu is and what it isn't.  for ENCRYPTED dhcpv6, tofu is
fine.  for SECURE dhcpv6, imiho, it is not.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Sep 2016 06:46:09 +0900

> All you know is "this is the same server that worked last time."

the part i like best is when you get an auth failure on the second use.
was the first one the mitm or the second?  or both?

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Sep 2016 06:48:12 +0900

> On the other hand, an enterprise being able to configure it's DHCP
> server in the workstations it gives out is a nice hook to have.

in yokohama, enterprise was the goal on which we agreed, specifically
not the coffee shop.  which was why we agreed no tofu.

randy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 18:53:10 -0400

Yes, that's what you told us to do, and then we got a comment from Stephen
that he thought we should do ToFU, so here we are.

I always thought ToFU was a good idea, so I'm happy to go with Stephen's
request.

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Sep 2016 08:12:37 +0900

> Yes, that's what you told us to do, and then we got a comment from
> Stephen that he thought we should do ToFU, so here we are.

not exactly.  that is what we agreed in order to actually try to have
*secure* dhcpv6.  because we did not understand how to actually provide
a *secure* solution outside of the enterprise-like space.  as far as i
can see, we still don't. 

randy