Subject: [saag] A little more detail on ToFU for DHCPv6

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 14:15:06 -0400

I just reviewed the thread, and noticed that there hasn't actually been an
explanation of how this is supposed to be useful.

For those who are not intimately familiar with DHCP, here is how it works:

   - a client notices that it has joined a link
   - the client sends a solicit message
   - zero or more DHCP servers respond within a certain window (1s, by
   default).
   - the client picks one of these responses based on various criteria, or
   if it has no basis for preferring one, at random, or possibly just the
   first or last one that arrived.   The details of this selection process are
   not specified in RFC 3315.
   - the client is now wedded to that DHCP server until it moves to a new
   link or the server goes away

When a client connects to a link, either it will be a link the client has
previously connected to, or not.   If it is a link to which the client had
previously connected, there may be a rogue DHCP server on the link that
wasn't present last time the client connected.   ToFU, with no user
confirmation, blocks the rogue DHCP server from being chosen by the client,
assuming that the previously used server is still present.

When a client connects to a link to which it has never previously
connected, it will pick a DHCP server.   This DHCP server may or may not be
a rogue DHCP server.   If it is a rogue DHCP server, the client is
potentially screwed, and the end user will potentially notice this,
depending on what sort of attach the rogue server is attempting.   The user
can detect this and say "don't use this server anymore."

If the client is connecting to a Boingo hotspot, Boingo can (a) filter out
rogue DHCP packets and (b) sign the key it uses using a PKI cert chain that
can be validated.   The client can be configured to prefer keys signed by
that entity.   This can also be done for enterprise clients.   There's no
reason why this has to be difficult, and we can use the PKI infrastructure
to make it work, or we can use DANE, in theory.

So the ToFU use case is for connecting to a network speculatively.   In
this case, the worst case scenario if you don't have ToFU is that you wind
up talking to a rogue DHCP server that is able to get information out of
you by faking your configuration.   What ToFU does is make it a lot harder
for the rogue server to do this: it has to be the first server you talk to
on that link.

I don't think there's any point in re-keying in a typical case, and I don't
think there's any point in interacting with the user in a typical case.
There should not be security pop-ups.   If the network isn't working, the
user will stop using it; that's the UX we want.

So this is why I think ToFU adds value.   Does that make sense, or am I
missing something?

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Sep 2016 11:43:23 -0700

Hi, Ted,

On 9/1/2016 11:15 AM, Ted Lemon wrote:
> So this is why I think ToFU adds value.   Does that make sense, or am
> I missing something?

Wouldn't this also then ensure that you're locked-in to a spoofer?

I.e., it seems like there needs to be a way for users to "reset" things
if needed.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 14:48:35 -0400

Yes, I think you are right.   This is the "one step back" to which Rich was
referring--he responded privately.   I have copied my answer, because I
think it's worth exploring this carefully, and I'm curious to hear your
answer as well as Rich's:

If the "wrong" server is giving you a working connection, you're no worse
off than you were without ToFU; if it's not, then you're presumably going
to connect to a different network, or complain, and somebody with network
fu will help you.   I think this is better than popping up security
warnings, although I could be convinced otherwise.   A "try to fix my
network" button could help as well--if someone is pressing it, maybe the
server the client bonded to sucks.   Heuristics for detecting filtered
connections could also work.

Bear in mind that a rogue server that's present on the wire and presenting
a cert at time T, but is not present at time T+100, will not prevent the
client that bonded to the rogue at time T from getting configured by
another server at time T+100.   It's only if the rogue _and_ the other
server are present that the client will prefer the rogue.

An additional heuristic here might be to always prefer the server to which
we most recently bonded when there is a choice; this would favor the
incumbent server over the intermittent rogue.

But ultimately there is no perfect solution; the question is, is this
better than not using ToFU?
​

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 14:51:44 -0400

Another thing to say, which I think is why we don't hear about this much,
is that most network infrastructure equipment lets you filter DHCP server
messages from leaf links that aren't authorized to have a DHCP server
attached to them.   So you can argue that this is massive overkill because
really we won't need this solution anyway.   I think that's why Randy felt
it was worth not bothering with ToFU.   However, I think ToFU potentially
works well on home networks, where the network operator doesn't have enough
network fu to know how to filter DHCP, but where we can assume a stable
incumbent DHCP server with a stable key.

On Thu, Sep 1, 2016 at 2:48 PM, Ted Lemon <[email-masked]> wrote:

> Yes, I think you are right.   This is the "one step back" to which Rich
> was referring--he responded privately.   I have copied my answer, because I

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Sep 2016 13:43:59 -0700

Hi, Ted,

TOFU is worse thank doing nothing because it requires user intervention
to override when it's wrong.

I.e., it doesn't create the vulnerability, but it makes the following
tradeoff:

    - if you connect to the right server first, TOFU protects you from
subsequent "attacks" of new servers popping up

    - if you connect to the wrong server first, TOFU amplifies the
strength of that attack by requiring additional action to "break" the
association

IMO, "trust but verify" should be used here, sort of how we deal with
unknown X.509 certs.

    1) if not "trusted" (on first use or any use where we haven't cached
trust), ask the user whether they want a one-time override or to keep
the cert

    2) if the cert is kept, then silently trust it. anyone who keeps
certs should know how to flush them if they make a mistake

I.e., neither the concern nor the fix are new.

Joe

On 9/1/2016 11:48 AM, Ted Lemon wrote:
> Yes, I think you are right.   This is the "one step back" to which
> Rich was referring--he responded privately.   I have copied my answer,
> because I think it's worth exploring this carefully, and I'm curious
> to hear your answer as well as Rich's:
>
> If the "wrong" server is giving you a working connection, you're no
> worse off than you were without ToFU; if it's not, then you're
> presumably going to connect to a different network, or complain, and
> somebody with network fu will help you.   I think this is better than
> popping up security warnings, although I could be convinced otherwise.
>   A "try to fix my network" button could help as well--if someone is
> pressing it, maybe the server the client bonded to sucks.   Heuristics
> for detecting filtered connections could also work.
>
> Bear in mind that a rogue server that's present on the wire and
> presenting a cert at time T, but is not present at time T+100, will
> not prevent the client that bonded to the rogue at time T from getting
> configured by another server at time T+100.   It's only if the rogue
> _and_ the other server are present that the client will prefer the rogue.
>
> An additional heuristic here might be to always prefer the server to
> which we most recently bonded when there is a choice; this would favor
> the incumbent server over the intermittent rogue.
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Sep 2016 13:47:52 -0700

While we're adding other things:

TOFU has two purposes:

a) caching trust, i.e., reducing the window of opportunity of an
attacker (but it then amplifies the strength of a successful attack, as
noted in my other post)

b) raising the bar for the attacker in general (they have to participate
in the security protocol; they can't just "fling" messages). This was
the basis of BTNS, i.e., to leverage the additional work of requiring an
attacker to complete a DH exchange, even if the receiver didn't (or
couldn't) verify the sender's identity.

Is (b) relevant for the way you're using this trust for DHCP too? I.e.,
would this then make it more computationally intensive for an attacker
in a way that is considered useful to "raise the bar"?

Joe

On 9/1/2016 11:51 AM, Ted Lemon wrote:
> Another thing to say, which I think is why we don't hear about this
> much, is that most network infrastructure equipment lets you filter
> DHCP server messages from leaf links that aren't authorized to have a
> DHCP server attached to them.   So you can argue that this is massive
> overkill because really we won't need this solution anyway.   I think
> that's why Randy felt it was worth not bothering with ToFU.   However,
> I think ToFU potentially works well on home networks, where the
> network operator doesn't have enough network fu to know how to filter
> DHCP, but where we can assume a stable incumbent DHCP server with a
> stable key.
>
> On Thu, Sep 1, 2016 at 2:48 PM, Ted Lemon <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Rich was referring--he responded privately.   I have copied my
>     answer, because I think it's worth exploring this carefully, and
>     I'm curious to hear your answer as well as Rich's:
>
>     If the "wrong" server is giving you a working connection, you're
>     no worse off than you were without ToFU; if it's not, then you're
>     presumably going to connect to a different network, or complain,
>     and somebody with network fu will help you.   I think this is
>     better than popping up security warnings, although I could be
>     convinced otherwise.   A "try to fix my network" button could help
>     as well--if someone is pressing it, maybe the server the client
>     bonded to sucks.   Heuristics for detecting filtered connections
>     could also work.
>
>     presenting a cert at time T, but is not present at time T+100,
>     will not prevent the client that bonded to the rogue at time T
>     from getting configured by another server at time T+100.   It's
>     only if the rogue _and_ the other server are present that the
>     client will prefer the rogue.
>
>     An additional heuristic here might be to always prefer the server
>     to which we most recently bonded when there is a choice; this
>     would favor the incumbent server over the intermittent rogue.
>
>     But ultimately there is no perfect solution; the question is, is
>     this better than not using ToFU?
>     ​
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 1 Sep 2016 20:53:46 +0000

> TOFU has two purposes:

I think it has a third: very weak authentication.  For example, most uses of ssh within an organization, where the primary motivation is integrity and privacy. When I'm using key-based authen, I'm not giving my password away.  Nowadays we'd relate it to opportunistic encryption, perhaps.

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Sep 2016 14:00:12 -0700

> I think it has a third: very weak authentication.  For example, most uses of ssh within an organization, where the primary motivation is integrity and privacy. When I'm using key-based authen, I'm…
TOFU doesn't authenticate anything except "same as before", but that's
just because you cached the info the first time you saw it.

We used DH without signatures for IPsec to protect a connection once
established - regardless of with whom it was established.

I'm not sure how this is related to "opportunistic encryption" because
I've seen that defined far too many ways (including mis-defined as
applying to BTNS).

Joe

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 1 Sep 2016 21:04:57 +0000

> I'm not sure how this is related to "opportunistic encryption" because I've
> seen that defined far too many ways

Which is why I said perhaps :)
--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Alan DeKok <[email-masked]>
Date: Thu, 1 Sep 2016 17:20:07 -0400

On Sep 1, 2016, at 2:15 PM, Ted Lemon <[email-masked]> wrote:
> 
> I just reviewed the thread, and noticed that there hasn't actually been an explanation of how this is supposed to be useful.
> 
> 	• a client notices that it has joined a link
> 	• the client sends a solicit message
> 	• zero or more DHCP servers respond within a certain window (1s, by default).
> 	• the client picks one of these responses based on various criteria, or if it has no basis for preferring one, at random, or possibly just the first or last one that arrived.   The details of this selection process are not specified in RFC 3315.
> 	• the client is now wedded to that DHCP server until it moves to a new link or the server goes away
> When a client connects to a link, either it will be a link the client has previously connected to, or not.   If it is a link to which the client had previously connected, there may be a rogue DHCP server on the link that wasn't present last time the client connected.   ToFU, with no user confirmation, blocks the rogue DHCP server from being chosen by the client, assuming that the previously used server is still present.

  In all of this discussion, I see nothing about 802.1X.

  i.e. if a user does 802.1X before DHCP... they have a security association with the AAA server.  Is there any way to leverage that for DHCP?

  While there are many situations where the users don't do 802.1X, there are many situations where they *will* do 802.1X.  Those situations should be addressed in the document.

  Why not have the AAA server introduce the DHCP server?  i.e. send over a copy of the certificate, or hints about the certificate to the DHCP client.  The client is free to ignore that information, of course.  But that information should probably be used in preference to any guesses made by the client.

> When a client connects to a link to which it has never previously connected, it will pick a DHCP server.   This DHCP server may or may not be a rogue DHCP server.   If it is a rogue DHCP server, the client is potentially screwed, and the end user will potentially notice this, depending on what sort of attach the rogue server is attempting.   The user can detect this and say "don't use this server anymore."

  If a client is connecting via 802.1X, it can be instructed as to which DHCP server to use.  In which case rogue DHCP servers just aren't a problem, no matter what else is going on (or not) in the network.

> If the client is connecting to a Boingo hotspot, Boingo can (a) filter out rogue DHCP packets and (b) sign the key it uses using a PKI cert chain that can be validated.   The client can be configured to prefer keys signed by that entity.   This can also be done for enterprise clients.   There's no reason why this has to be difficult, and we can use the PKI infrastructure to make it work, or we can use DANE, in theory.

  Or via 802.1X.  Which is widely deployed in enterprise environments, and in mobile networks.

  Alan DeKok.

---

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

On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch <[email-masked]> wrote:

> TOFU is worse thank doing nothing because it requires user intervention to
> override when it's wrong.
>
It's as if you haven't read anything I've written.   Can you go back and do
that, and then respond to what I wrote, and not just slogan at me?   Sorry
to be less than appreciative--I do appreciate having a discussion, but the
discussion needs to be talking about real issues in order to be useful.

The reality is that when a user gets attacked by a rogue server, there is
_always_ going to have to be user intervention.   To evaluate the proposal
meaningfully, we have to answer two questions: does ToFU make such
interventions more or less likely, and does it make them appreciably worse
or better?

> trust), ask the user whether they want a one-time override or to keep the
> cert
>

I'm sorry, but this is nonsense.   You should never ask a user to trust a
cert--they are not equipped to make this decision, and you are training
them to be susceptible to malware.   Either you have a basis for trusting a
cert, or you do not.   If you do not, then you simply don't trust it.  Full
stop.   You do not ask the user whether to trust it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 19:02:58 -0400

I'm going to give a somewhat unhelpful response, but the question that pops
to mine when you suggest that is, why don't we also do this for web pages
and for ssh?   That is, if you have 802.1x, why not use that security
association to authenticate ssh servers?   I think the answer is clearly
that you would never do this; I can see why you might think that it would
be okay to do it for DHCP, but I still think it's worth trying to
explicitly answer the question.

In any case, from my perspective, what you're suggesting sounds like
something that would never be deployed.   When and how effectively is
802.1x deployed?   Are those the same sites that we are trying to help with
DHCP authentication?   If you have 802.1x, why aren't you doing DHCP
filtering?   I don't think this is an important use case, but if it is, a
pre-shared cert will solve the problem, and you don't want to use ToFU
anyway.

On Thu, Sep 1, 2016 at 5:20 PM, Alan DeKok <[email-masked]>
wrote:

> > I just reviewed the thread, and noticed that there hasn't actually been
> an explanation of how this is supposed to be useful.
> >
> >       • the client picks one of these responses based on various
> criteria, or if it has no basis for preferring one, at random, or possibly
> just the first or last one that arrived.   The details of this selection
> process are not specified in RFC 3315.
> > When a client connects to a link, either it will be a link the client
> has previously connected to, or not.   If it is a link to which the client
> had previously connected, there may be a rogue DHCP server on the link that
>   i.e. if a user does 802.1X before DHCP... they have a security
> association with the AAA server.  Is there any way to leverage that for
> DHCP?
>
>   While there are many situations where the users don't do 802.1X, there
> are many situations where they *will* do 802.1X.  Those situations should
> be addressed in the document.
>
>   Why not have the AAA server introduce the DHCP server?  i.e. send over a
> copy of the certificate, or hints about the certificate to the DHCP
> client.  The client is free to ignore that information, of course.  But
> that information should probably be used in preference to any guesses made
> by the client.
>
>   If a client is connecting via 802.1X, it can be instructed as to which
> DHCP server to use.  In which case rogue DHCP servers just aren't a
> problem, no matter what else is going on (or not) in the network.
>
> > If the client is connecting to a Boingo hotspot, Boingo can (a) filter
> out rogue DHCP packets and (b) sign the key it uses using a PKI cert chain
> that can be validated.   The client can be configured to prefer keys signed
> by that entity.   This can also be done for enterprise clients.   There's
> no reason why this has to be difficult, and we can use the PKI
> infrastructure to make it work, or we can use DANE, in theory.
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Sep 2016 16:12:18 -0700

On 9/1/2016 3:57 PM, Ted Lemon wrote:
> On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     TOFU is worse thank doing nothing because it requires user
>     intervention to override when it's wrong.
>
> It's as if you haven't read anything I've written.
/You said two things:

1) "/When a client connects to a link to which it has never previously
connected, it will pick a DHCP server.   This DHCP server may or may not
be a rogue DHCP server.   If it is a rogue DHCP server, the client is
potentially screwed, and the end user will potentially notice this,
depending on what sort of attach the rogue server is attempting.   The
user can detect this and say "don't use this server anymore."" and later
"I don't think there's any point in re-keying in a typical case, and I
don't think there's any point in interacting with the user in a typical
case.   There should not be security pop-ups.   If the network isn't
working, the user will stop using it; that's the UX we want."

You also then said:
2) "If the "wrong" server is giving you a working connection, you're no
worse off than you were without ToFU; if it's not, then you're
presumably going to connect to a different network, or complain, and
somebody with network fu will help you.   I think this is better than
popping up security warnings, although I could be convinced otherwise.  
A "try to fix my network" button could help as well--if someone is
pressing it, maybe the server the client bonded to sucks.   Heuristics
for detecting filtered connections could also work."

That's what I disagree with. Did I miss another post where you said
something different?

IMO, there is an existing UI for handling this - to make the user aware
of the TOFU case when it first occurs and ask for them to confirm
whether they want to continue that trust or make it a one-time case.
I.e., trust-now or on first use (TNOOFU), not just TOFU.

//
>
> The reality is that when a user gets attacked by a rogue server, there
> is _always_ going to have to be user intervention.

Your version of user intervention and mine are different. You say simply
"stop using the network". IMO, investing in the trust should be opt-im
and explicit, not silent and automatic. Those are very different things.

>   To evaluate the proposal meaningfully, we have to answer two
> questions: does ToFU make such interventions more or less likely, and
> does it make them appreciably worse or better?
>
>         1) if not "trusted" (on first use or any use where we haven't
>     cached trust), ask the user whether they want a one-time override
>     or to keep the cert
>
> I'm sorry, but this is nonsense.   You should never ask a user to
> trust a cert--they are not equipped to make this decision, and you are
> training them to be susceptible to malware.   Either you have a basis
> for trusting a cert, or you do not.   If you do not, then you simply
> don't trust it.  Full stop.   You do not ask the user whether to trust it.

Presumably you're aware that this is how most systems do things,
including web browsers, operating systems, etc?

Are you arguing that you should always pay for network/OS "fu" to have
someone help when this happens? That's not the how the real world
already works.

Joe

---

From: Alan DeKok <[email-masked]>
Date: Thu, 1 Sep 2016 19:23:54 -0400

> On Sep 1, 2016, at 7:02 PM, Ted Lemon <[email-masked]> wrote:
> 
> I'm going to give a somewhat unhelpful response, but the question that pops to mine when you suggest that is, why don't we also do this for web pages and for ssh?

  Because of historical designs and implementations.  Which shouldn't *prevent* us from doing the Right Thing moving forward.

  Network access has to bootstrap from somewhere.  Right now, without 802.1X, it's largely "la la la, I trust everyone".  I submit that this is a bad idea.

  Securing DHCP helps.  But wouldn't it be nice to know that the organization who granted you network access also granted you network credentials?  i.e. IP addresses?

  No?

  Why not?

>   That is, if you have 802.1x, why not use that security association to authenticate ssh servers?

  The ABFAB working group leverages the AAA infrastructure to authenticate users to SSH servers.  Which is pretty darned similar.

  But to answer your question, the answer is simple.  Bootstrapping network access is not the same as accessing services on the net.

>   I think the answer is clearly that you would never do this; I can see why you might think that it would be okay to do it for DHCP, but I still think it's worth trying to explicitly answer the question.

  I find it worth trying to explain what problem you're trying to solve, instead of posing riddles.

  In the case of 802.1X,  we have secure network access.  The network proves it's identity to the end device, and they securely exchange credentials.  Once that's done, all that information is forgotten, and we do DHCP.  No authentication.  No security.  This draft helps do secure DHCP, but there's no tie between network access (ethernet) and network access (IP addresses).

  Uh... really?  Is this really the *best* we can do?

> In any case, from my perspective, what you're suggesting sounds like something that would never be deployed.   When and how effectively is 802.1x deployed?

  Everywhere.  3G, Wifi, wired, enterprise, ISP, telco...

>   Are those the same sites that we are trying to help with DHCP authentication?

  I would suggest yes.

>   If you have 802.1x, why aren't you doing DHCP filtering?

  Sure.  But DHCP filtering happens in the network.  There's no way for the DHCP client to know that DHCP filtering is happening.

  Why not *explicit* security?

>   I don't think this is an important use case, but if it is, a pre-shared cert will solve the problem, and you don't want to use ToFU anyway.

  Hmm... if you say so.

  Alan DeKok.

---

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

> is _always_ going to have to be user intervention.

not just on attack.  if you gmobd, the first time the client meets any
new server, it needs to ask the user if server with cert <blah> should
be trusted.  and, similarly to ssh, you probably want it to pin that
credential.

randy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 21:29:44 -0400

I am arguing that you are far better off being unable to use something that
is not secure than you are being trained by software written by people who
should know better to behave in a way that almost guarantees that you will
eventually be victimized.   Any UI asking a user to make a decision about
trust should be crafted in such a way that it doesn't train the user to do
things that will screw them later.   We fail horribly at this, in general.
  Users aren't stupid, but it will never be the case that they will be able
to figure out how to make trust decisions unless we really take seriously
how we present those decisions to them, and do not present decisions to
them that they will not be able to make correctly when an attacker asks
them to do the same thing.

On Thu, Sep 1, 2016 at 7:12 PM, Joe Touch <[email-masked]> wrote:

> *You said two things: 1) "*When a client connects to a link to which it
> has never previously connected, it will pick a DHCP server.   This DHCP
> server may or may not be a rogue DHCP server.   If it is a rogue DHCP
> server, the client is potentially screwed, and the end user will
> potentially notice this, depending on what sort of attach the rogue server
> is attempting.   The user can detect this and say "don't use this server
> anymore."" and later "I don't think there's any point in re-keying in a
> typical case, and I don't think there's any point in interacting with the
> user in a typical case.   There should not be security pop-ups.   If the
> network isn't working, the user will stop using it; that's the UX we want."
>
> You also then said:
> worse off than you were without ToFU; if it's not, then you're presumably
> going to connect to a different network, or complain, and somebody with
> network fu will help you.   I think this is better than popping up security
> connections could also work."
>
> IMO, there is an existing UI for handling this - to make the user aware of
> the TOFU case when it first occurs and ask for them to confirm whether they
> want to continue that trust or make it a one-time case. I.e., trust-now or
> on first use (TNOOFU), not just TOFU.
>
>
> _always_ going to have to be user intervention.
>
>
> "stop using the network". IMO, investing in the trust should be opt-im and
> explicit, not silent and automatic. Those are very different things.
>
>   To evaluate the proposal meaningfully, we have to answer two questions:
> does ToFU make such interventions more or less likely, and does it make
> them appreciably worse or better?
>
> Presumably you're aware that this is how most systems do things, including
> web browsers, operating systems, etc?
>
> someone help when this happens? That's not the how the real world already
> works.
>
> Joe
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 21:45:23 -0400

On Thu, Sep 1, 2016 at 7:23 PM, Alan DeKok <[email-masked]>
wrote:

> > I'm going to give a somewhat unhelpful response, but the question that
> pops to mine when you suggest that is, why don't we also do this for web
> pages and for ssh?
>
>   Because of historical designs and implementations.  Which shouldn't
> *prevent* us from doing the Right Thing moving forward.
>

No, it's because it would be a bad idea.   You are trusting the wrong
entity if you allow 802.1x to assure you that you are talking to your bank.

>   Network access has to bootstrap from somewhere.  Right now, without
> 802.1X, it's largely "la la la, I trust everyone".  I submit that this is a
> bad idea.
>

Sure, for contexts in which the 802.1x functional model works.

>   Securing DHCP helps.  But wouldn't it be nice to know that the
> organization who granted you network access also granted you network
> credentials?  i.e. IP addresses?
>

There are several unwarranted assumptions in this question:

   - you've been explicitly, not implicitly, granted access to the network
   - the operator of layer 2 is also the operator of the DHCP server

In situations where both of these assumptions are true, yes, you might as
well use the same keys to authenticate layer 2 and layer 3.

>   The ABFAB working group leverages the AAA infrastructure to authenticate
> users to SSH servers.  Which is pretty darned similar.
>

This is a fascinating collection of work--I just peeked at the arch
document.   That said, I can't imagine a situation in which I would find
myself using it.   I believe that such situations exist, but my point is
that this is not a good general approach--it is solving a very constrained
problem.

>   But to answer your question, the answer is simple.  Bootstrapping
> network access is not the same as accessing services on the net.
>

Yup.   I think we agree that when it's possible to bootstrap both layer 2
and layer 3 using the same keying infrastructure, that's the right thing to
do.

> instead of posing riddles.

I thought I already did that.   It was not my intention to be annoying--I'm
just trying to figure out if the reasoning I presented made sense, and I'm
getting answers that don't really seem to connect to that.

  In the case of 802.1X,  we have secure network access.  The network
> proves it's identity to the end device, and they securely exchange
> credentials.  Once that's done, all that information is forgotten, and we
> do DHCP.  No authentication.  No security.  This draft helps do secure
> DHCP, but there's no tie between network access (ethernet) and network
> access (IP addresses).
>

DHCP has for a long time had the ability to do this using pre-shared keys,
which would be supported by AAA and would work with 802.1x.   There are
zero deployments of the pre-shared key solution.   The reason is that it
doesn't really make sense in the DHCP use model.

> 802.1x deployed?

I never use 802.1x at all in my daily life.   The only time I've ever seen
it deployed is at IETF and at my company's office in Redwood City, where, I
hasten to add, it works so poorly that I sometimes use the guest network,
or the wired network, which does not use 802.1x.

> >   Are those the same sites that we are trying to help with DHCP

I think those are very much the exception in terms of real-world DHCP
usage.  In order to justify the rather massive effort that would be
involved in making this work for DHCP, the first question I would ask is,
do you actually need to authenticate the client again if you are using
802.1x?   I think the answer is a resounding no.   I think if the IETF
developed a solution to this problem, exactly zero people would deploy it.
  If you think that's not the case, do you know of people who are clamoring
for this feature?

>   Sure.  But DHCP filtering happens in the network.  There's no way for
> the DHCP client to know that DHCP filtering is happening.
>

Sure.   Use the same cert to identify both the 802.1x server and the DHCP
server.   Done.   You don't need to use ToFU for this use case, and I don't
think you should.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 1 Sep 2016 21:47:18 -0400

I disagree that users are not stupid.  But then again software that forces
a security choice is just as stupid.

For a Starbucks environment I can see a placard at the desk that has the
fingerprint of the local DHCP server.  So if the software says "do you
trust this?" (ala SSH) then there is some reason to believe that users
would have something to compare it to.

For my home network, I know what it should be, and I can tell my guests.

The issue would be locations where the admins don't know or don't care.

I think SSH works pretty well in general.  But it's definitely a PITA when
a server gets re-keyed, and I'm a pretty technical user.  I don't think an
average user would know what to do, and SSH certainly doesn't have a
button to accept the new key when it's been changed.  It just gives a
pretty large error and quits.

I don't know what UI a ToFU DHCP client could provide that would be
better..  but SSH is definitely not the epitome of UI.

-derek

On Thu, September 1, 2016 9:29 pm, Ted Lemon wrote:
>> presumably
>> of
>> is
>> and
>> questions:
>>> cached
>>> the
>> already
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Sep 2016 21:47:38 -0400

No, you explicitly do not need to ask the user whether to trust a specific
server.   That is not the use case for ToFU DHCPv6.   For that, you just
install a pre-shared cert.   I guess you could do the cert installation
using a ToFU-like UI, but I think that's a bad idea--it trains the user to
make leaps of faith that I don't think are warrented.

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Sep 2016 21:33:11 -0700

On 9/1/2016 6:29 PM, Ted Lemon wrote:
> I am arguing that you are far better off being unable to use something
> that is not secure than you are being trained by software written by
> people who should know better to behave in a way that almost
> guarantees that you will eventually be victimized.   Any UI asking a
> user to make a decision about trust should be crafted in such a way
> that it doesn't train the user to do things that will screw them
> later.   We fail horribly at this, in general.   Users aren't stupid,
> but it will never be the case that they will be able to figure out how
> to make trust decisions unless we really take seriously how we present
> those decisions to them, and do not present decisions to them that
> they will not be able to make correctly when an attacker asks them to
> do the same thing.

I understand your position, but disagree exactly because users have many
years of experience with the counterexample for matters that have much
more direct consequences - namely, Internet commerce.

You asked my position, and that's it. I appreciate that we disagree.

Joe

>
> On Thu, Sep 1, 2016 at 7:12 PM, Joe Touch <[email-masked]
>     1) "/When a client connects to a link to which it has never
>     previously connected, it will pick a DHCP server.   This DHCP
>     server may or may not be a rogue DHCP server.   If it is a rogue
>     DHCP server, the client is potentially screwed, and the end user
>     will potentially notice this, depending on what sort of attach the
>     rogue server is attempting.   The user can detect this and say
>     "don't use this server anymore."" and later "I don't think there's
>     any point in re-keying in a typical case, and I don't think
>     there's any point in interacting with the user in a typical case.
>       There should not be security pop-ups.   If the network isn't
>     2) "If the "wrong" server is giving you a working connection,
>     you're no worse off than you were without ToFU; if it's not, then
>     you're presumably going to connect to a different network, or
>     complain, and somebody with network fu will help you.   I think
>     this is better than popping up security warnings, although I could
>     be convinced otherwise.   A "try to fix my network" button could
>     help as well--if someone is pressing it, maybe the server the
>     client bonded to sucks.   Heuristics for detecting filtered
>     That's what I disagree with. Did I miss another post where you
>     said something different?
>
>     IMO, there is an existing UI for handling this - to make the user
>     aware of the TOFU case when it first occurs and ask for them to
>     confirm whether they want to continue that trust or make it a
>     one-time case. I.e., trust-now or on first use (TNOOFU), not just
>     TOFU.
>
>     //
>>
>>     The reality is that when a user gets attacked by a rogue server,
>>     there is _always_ going to have to be user intervention.
>
>     Your version of user intervention and mine are different. You say
>     simply "stop using the network". IMO, investing in the trust
>     should be opt-im and explicit, not silent and automatic. Those are
>     very different things.
>
>>     questions: does ToFU make such interventions more or less likely,
>>     and does it make them appreciably worse or better?
>>
>>             1) if not "trusted" (on first use or any use where we
>>         haven't cached trust), ask the user whether they want a
>>         one-time override or to keep the cert
>>
>>     trust a cert--they are not equipped to make this decision, and
>>     you are training them to be susceptible to malware.   Either you
>>     have a basis for trusting a cert, or you do not.   If you do not,
>>     then you simply don't trust it.  Full stop.   You do not ask the
>>     user whether to trust it.
>
>     Are you arguing that you should always pay for network/OS "fu" to
>     have someone help when this happens? That's not the how the real
>     world already works.
>
>     Joe
>
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Sep 2016 01:31:19 -0400

> On Sep 2, 2016, at 12:33 AM, Joe Touch <[email-masked]> wrote:
> 
> I understand your position, but disagree exactly because users have many years of experience with the counterexample for matters that have much more direct consequences - namely, Internet commerce.

One might note that Web-based e-commerce is squarely in the world of mandatory,
not opportunistic, security.  And, in that space,
 work still remains to be done
to design adequate security reporting UIs.

For opportunistic security, look at SMTP, where Google's email transparency report
shows outbound TLS use varying from 84--87% and inbound from 76--80%.  But this uses
unauthenticated TLS.  And we're discussing TOFU, not anonymous encryption.

Pertinent RFC 7435 text:

*  The trust-on-first-use (TOFU) authentication approach assumes that an
   unauthenticated public key obtained on first contact (and retained
   for future use) will be good enough to secure future communication.
   TOFU-based protocols do not protect against an attacker who can
   hijack the first contact communication and require more care from the
   end user when systems update their cryptographic keys.  TOFU can make
   it difficult to distinguish routine key management from a malicious
   attack.

*  While the use of OS is preempted by a non-OS explicit policy, such a
   non-OS policy can be counter-productive when it demands more than
   many peers can in fact deliver.  A non-OS policy should be used with
   care, lest users find it too restrictive and act to disable security
   entirely.

*  When less than complete protection is negotiated, there is no need to
   prompt the user with "your security may be degraded, please click OK"
   dialogs.  The negotiated protection is as good as can be expected.
   Even if not comprehensive, it is often better than the traditional
   outcome of either "no protection" or "communications failure".

*  ... Failure to encrypt may be more often a symptom of an
   interoperability problem than an active attack.  In such a situation,
   occasional fallback to cleartext may serve the greater good.  Even
   though some traffic is sent in the clear, the alternative is to ask
   the administrator or user to manually work-around such
   interoperability problems.  If the incidence of such problems is non-
   negligible, the user or administrator might find it more expedient to
   just disable Opportunistic Security.

*  While the use of OS is preempted by a non-OS explicit policy, such a
   non-OS policy can be counter-productive when it demands more than
   many peers can in fact deliver.  A non-OS policy should be used with
   care, lest users find it too restrictive and act to disable security
   entirely.

The bottom line is that opportunistic security that is intrusive is
counter-productive.  What this means for TOFU with DHCP is that mere
key pinning should not be a blanket, on by default mechanism.  If
the feature cannot be made essentially unnoticeable to users, it must
be off by default, and enabled by knowledgeable users only in appropriate
circumstances.

As for applicability of TOFU in DHCP, it seems to me that at least for
most WiFi networks, one really wants to know that one is connecting to
a legitimate switch, more than that the DHCP response is authentic.

Once one has joined the right network, one might hope that some day
the network will protect end-nodes from unauthorized DHCP servers
or ARP spoofing of the router IP address, ...  Indeed one might
expect public WiFi networks to not allow wireless end-nodes
to communicate with each other, presenting an illusion of a
point-to-point private Layer2/3 connection to each node.  At
that point DHCP authentication is not needed.

So there needs to be a fairly detailed use-case analysis that
delineates the situations in which TOFU is useful with DHCP,
and how false alarms are kept to a sufficiently low rate to
rarely if ever be seen by users.

Does it make sense to authenticate DHCP and the network separately?
Would TACK be a practical approach to reducing key rotation false
alarms?  Is secure DHCP useful on shared broadcast networks that
don't isolate end-nodes from each other? ...

We don't seem to be discussing any detailed use-cases, and similarly
detailed proposed designs.  A useful outcome from the current thread
seems unlikely...

-- 
	Viktor.

---

From: Randy Bush <[email-masked]>
Date: Fri, 02 Sep 2016 14:58:34 +0900

[ in yokohama, i was asked to help with with the dhcp6 draft.  i was a
  fool to agree.  will not make same mistake again. }

but this is of interest to me.  i think of the space as 'introduction'
and it is a large and deep problem across many protocols.

> For a Starbucks environment I can see a placard at the desk that has
> the fingerprint of the local DHCP server.  So if the software says "do
> you trust this?" (ala SSH) then there is some reason to believe that
> users would have something to compare it to.

we started experimenting in this space at work, where wifi passwords are
changed monthly (don't ask), and are quite long and painful.  qr-codes
pasted on wall were the favorite.

i am less comfortable with scanning a qr code in a coffee shop.  but i
would hope that, if we started using qr codes in this space, we would
develop scanware with which we could be comfortable.

randy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 2 Sep 2016 08:45:30 +0200

Hi Ted,

On 9/2/16 1:02 AM, Ted Lemon wrote:
> pops to mine when you suggest that is, why don't we also do this for
> web pages and for ssh?   That is, if you have 802.1x, why not use that
> security association to authenticate ssh servers?   I think the answer
> is clearly that you would never do this; I can see why you might think
> that it would be okay to do it for DHCP, but I still think it's worth
> trying to explicitly answer the question.
I'll take a swing.

In the case of a web or ssh server, the organizational stretch and
complexity necessary to establish this trust may be a bridge too far. 
PANA et al would have gone a lot further than it otherwise did.  In the
case of DHCP, however, usually this stuff lives within the same
organization, and so there is hope that one could establish such a binding.

> something that would never be deployed.   When and how effectively is
It's effectively 802.11ai (e.g., WPA-Enterprise) and is fairly widely
deployed in that context.

>   Are those the same sites that we are trying to help with DHCP
> authentication?   If you have 802.1x, why aren't you doing DHCP
> filtering?   I don't think this is an important use case, but if it
> is, a pre-shared cert will solve the problem, and you don't want to
> use ToFU anyway.

At this point, no.  But that could easily become a "yes".  In fact it
might be the best way to go in the long term.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 2 Sep 2016 09:36:16 +0200

Hi again,

On 9/2/16 3:45 AM, Ted Lemon wrote:

>     organization who granted you network access also granted you
>     network credentials?  i.e. IP addresses?
>
>
>   * you've been explicitly, not implicitly, granted access to the network
>

802.1X makes it explicit.

>   * the operator of layer 2 is also the operator of the DHCP server
>

That's probably worth exploring a bit more, and there's not going to be
a single definitive example here.  However, it may be that pushing this
stuff into L2 access is still a better idea than trying to tweak DHCP. 
On the other hand, a model that maybe borrows from the trust of 1X *when
it exists* and does something else when it doesn't may be worth
exploring.  But isn't this also related to capport?

Eliot

---

From: Josh Howlett <[email-masked]>
Date: Fri, 2 Sep 2016 09:49:00 +0000

On Thu, Sep 1, 2016 at 7:23 PM, Alan DeKok <[email-masked]> wrote:
> > > That is, if you have 802.1x, why not use that security association to authenticate ssh servers?

> > The ABFAB working group leverages the AAA infrastructure to authenticate 

> This is a fascinating collection of work--I just peeked at the arch document.   That said, I can't imagine a
> situation in which I would find myself using it.   I believe that such situations exist, but my point is that this is
> not a good general approach--it is solving a very constrained problem.
 
Just to be clear, ABFAB's scope is much broader than SSH. Our implementation supports a number of applications via Unix GSS-API & Windows SSPI (including OpenSSH and Putty).

I have for some time been meaning to test our ABFAB implementation with a DNS implementation supporting TSIG (RFC 2845), such that trust could be established in DNS using a AAA infrastructure (as opposed to PKI-based approaches). It would be interesting to consider whether an approach analogous to TSIG could be taken with DHCP. Folks running DHCP are often also in the business of running AAA; the ability to back off trust decisions to a common infrastructure might be attractive. 

Josh.

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Sep 2016 12:19:18 +0100

>   fool to agree.  will not make same mistake again. }

Thanks though for being willing.

> and it is a large and deep problem across many protocols.

Yes. It'd be really interesting if there were a way to make progress
there. TBH, I'm not sure how we can do that though.

Suggestions very welcome.

> develop scanware with which we could be comfortable.

I like QR codes too for this kind of thing. When I suggested using 'em
for a thing though I had a bunch of people tell me that too few people
have readers they actually use for QR codes to be that useful. I'm not
sure if there're any public numbers about that though.

Cheers,
S.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Sep 2016 08:30:59 -0400

> be off by default, and enabled by knowledgeable users only in appropriate

This seems to me to be the key point of contention--I agree with everything
you wrote above it, but it's important to understand what we are talking
about here, and I think using the term "key pinning" severely confuses the
discussion.

As I understand it, and I'm sure you will correct me if I am wrong, since I
know you know more about this than I do, key pinning is when you have a
cert that signs a key, and you remember _that key_ as the correct key for
the identity being claimed with the cert.   If you later get a new cert
also claiming that identity but for a different key, you reject it as a
registry attack.

This is not at all what we are talking about here.   We are in fact
assuming that a given DHCP server identity will be protected by the same
key forever.   If you want to use a new key, you should use a new identity,
to avoid key pinning.   This is a key point that I missed, which may have
led us down this branch of the discussion.  You do not want to ever have a
new key for the same server identity, because doing so will produce exactly
the bad outcome you are concerned about, and would add no value at all.

For ToFU, the thing that I think you took for key pinning is simply a key
caching heuristic that does not require user involvement to be useful.   If
I get a DHCP message signed by a key that I previously cached, and there
were no problems with the previously-cached key, then I will prefer that
DHCP server over another DHCP server that also responded either using no
authentication, or using a key that I have not cached.

If I get responses from more than one DHCP server whose key I have cached,
I will choose from the signed responses using the same algorithm I would
normally use to choose from a selection of unsigned responses.   This
assures that the worst case scenario is the same behavior I currently get
with unsecured DHCP.   The only UI to add here is a "the network is flaky"
button, which could actually be another heuristic.   If "the network is
flaky" then the DHCP key I picked may be the wrong one, so mark it as
suspect and try the other.

> a legitimate switch, more than that the DHCP response is authentic.

Yes, exactly.

> that point DHCP authentication is not needed.

Right.   I think this is actually pretty typical for professionally-managed
hotspot networks already.

> rarely if ever be seen by users.

Yup.

> Does it make sense to authenticate DHCP and the network separately?

Yes.   In many networks layer two is operated by a different entity than
layer 3, and requiring them to share keys is inappropriate.

> alarms?

Keys should never, ever be rotated for ToFU.   Server identities are not
precious.   If you want to rotate keys, change both the key and the
identity.

> Is secure DHCP useful on shared broadcast networks that

I think so.

> seems unlikely..

Thinking about your response has already been useful to me in thinking
about the details of how to specify this.    Thank you for that.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Sep 2016 08:35:56 -0400

> 802.1X makes it explicit.

Right, what I meant here is that arguably the absence of 802.1x is a base
assumption for what we are working on.   If you have 802.1x, you probably
don't need DHCP security, although perhaps you would want encryption.   But
if you want encryption, you can use PKI for the server key--you don't need
ToFU.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Sep 2016 08:40:34 -0400

I'm sorry, but you guys are getting distracted by the shiny tech.   A QR
code is a way to _ensure_ that the rogue DHCP server gets to pwn you, not a
way to protect you from a rogue DHCP server.   If I want to attack everyone
in a Starbucks, all I have to do is set up my rogue server and paste a
nicely printed QR code over the one that's up, while the barista is making
my quad three-pump glatte.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Sep 2016 13:54:16 +0100

On 02/09/16 13:40, Ted Lemon wrote:
> I'm sorry, but you guys are getting distracted by the shiny tech.   

No. The QR code thing is just an example mechanism.

The interesting bit is the general problem of introduction.

(And how we all constantly side-track discussion of that
because there're so many dimensions to the problem;-)

S.

> A QR

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Sep 2016 09:00:18 -0400

The point is that in the case of DHCP opportunistic security, I think that
the cases where you could use an introduction mechanism are cases where it
would reduce, not enhance security.   A way of ensuring that your rogue
server wins the fight is not what we are trying to achieve here.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Sep 2016 14:11:56 +0100

On 02/09/16 14:00, Ted Lemon wrote:
> would reduce, not enhance security.   

I'm assuming Randy changed the subject line to change the subject
though:-) While I am a fan of OS for DHCP, that's just one small
part of the bigger issue. For example, introducing a new homenet
router is part of the story here and may have subtly different
issues compared to DHCP alone. But public key retrieval for secure
interpersonal messaging (e.g. PGP/SMIME or IM) also has introduction
problems.

That said, I don't actually agree with you about key continuity
but I'll answer that mail directly.

S,

> A way of ensuring that your rogue

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Sep 2016 14:17:19 +0100

Ted,

> precious.   If you want to rotate keys, change both the key and the

I very much disagree.

Having taken the LoF I do think there is benefit in allowing key
continuity (maybe via something like TACK) in cases like the home
router for an advanced user. While rolling to new keys in those
scenarios isn't that huge a priority, we've seen with SSH that the
inability to roll keys leads eventually to badness and I can't see
a reason why that'd be different here.

And I'm not sure what "identity" you mean in the case of a DHCP
server. If the identifier is the server's IP address then that
may not be easily changed. Or is there some other DHCP identifier
you meant?

S.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 2 Sep 2016 09:18:00 -0400

On Sep 1, 2016, at 9:45 PM, Ted Lemon <[email-masked]> wrote:
> 	• you've been explicitly, not implicitly, granted access to the network

  There are, of course, cases where network access is open and unauthenticated.  In those cases, authenticating the DHCP server doesn't add a lot of security.

> 	• the operator of layer 2 is also the operator of the DHCP server

  I would wager that where 802.1X is deployed, 99.9% of the time, the 802.1X and DHCP operators communicate with each other.  The *implementations* may not, but the operators do.

> Yup.   I think we agree that when it's possible to bootstrap both layer 2 and layer 3 using the same keying infrastructure, that's the right thing to do.

  My point is that once layer 2 is bootstrapped, we can bootstrap layer 3 off of that.

> I never use 802.1x at all in my daily life.   The only time I've ever seen it deployed is at IETF and at my company's office in Redwood City, where, I hasten to add, it works so poorly that I sometimes use the guest network, or the wired network, which does not use 802.1x.

  Get better IT people / software, then.

  EDUROAM uses 802.1X to authenticate millions of people, dozens of times a day each.  It's deployed world-wide.  It works with all known end-user equipment.  I'm personally aware of companies who have 8K+ switches, where all public ports (non server room) are 100% 802.1X.

  There is no *technical* reason why 802.1X can't work.

> I think those are very much the exception in terms of real-world DHCP usage.  In order to justify the rather massive effort that would be involved in making this work for DHCP,

  a) write a standard to derive a DHCP key from the 802.1X authentication
  b) implement that in DHCP clients and servers.

  It's not conceptually complex.  The code isn't even that difficult.  Maybe a few thousand lines on each of client / server.  There is no technical reason why this can't work.

> the first question I would ask is, do you actually need to authenticate the client again if you are using 802.1x?   I think the answer is a resounding no.

  That's not what I'm proposing.

  I'm proposing that the client get a secure introduction to the DHCP server.  So that it knows it's not being spoofed.

>   I think if the IETF developed a solution to this problem, exactly zero people would deploy it.   If you think that's not the case, do you know of people who are clamoring for this feature?

  People aren't clamouring for it because either they don't know it's a problem, or they get told it's impossible.  When I explain my proposal, most people using 802.1X go "Yeah, that would add to security.  I'd use that if it was available".

  Make no mistake, many large organizations have IT people who are desperate for new features... but who aren't allowed out of their little silos.  They don't talk to vendors, and they definitely don't show up to IETF.

> Sure.   Use the same cert to identify both the 802.1x server and the DHCP server.   Done.   You don't need to use ToFU for this use case, and I don't think you should.

  There are good reasons to *not* use the same cert for multiple applications.  Using the same CA infrastructure is a better idea.

  Alan DeKok.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Sep 2016 14:26:21 +0100

Hi Alan,

>   b) implement that in DHCP clients and servers.

I think that'd also be a fine thing if someone is willing to do the
work.

I don't think it means that there's anything wrong with doing this
work on DHCP as well.

We should not get in the way of folks who want to define useful things
just because we have a different (maybe better, maybe not) idea, and
especially if we don't have the cycles to bring our different idea to
fruition.

If one were to argue that ToFU security for DHCP were a negative that's
different of course. (As Randy does for example.)

S.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 2 Sep 2016 09:37:48 -0400

> I think that'd also be a fine thing if someone is willing to do the

  Consider it done.

  Alan DeKok.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Sep 2016 09:53:15 -0400

> my quad three-pump glatte.

The coffee shop should not require any trust. I neither trust their clientele
or the actual network owners. Whether DHCP or DNS or HTTP.

Coffee shop passwords are not for your security, They are to keep people on the
streets from using shop resources without buying a pumpkin spice latte.

Similarly, a hotspot landing page is not there to provide security or waive
liability, It is there for the shop to provide you with their advertisements.

Next, trust your local ISP as much as the coffee shop :)

Paul

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Sep 2016 09:58:30 -0400

Alan, I think what's going on here is simply that the world looks very
different depending on where you sit.   If you think it's worth solving the
802.1x:DHCP keying problem, I'm certainly interested in helping you to make
that happen.   But it feels somewhat orthogonal to this effort, unless
there's a way to link them using PKI.   And I will point out that many have
died on that hill in the past--you are not the first person to want to do
this, and one of the reasons I'm skeptical is that I've seen it tried
before.   I recommend you talk to Alper Yegin about it.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Sep 2016 15:16:44 +0000

On Fri, Sep 02, 2016 at 08:30:59AM -0400, Ted Lemon wrote:

> > What this means for TOFU with DHCP is that mere

Thing is, users have no knowledge of (or reason to know) which DHCP
server is legitimate for a given network.  Thus the "identity" you
speak of is meaningless, the user is connecting to a given network,
not to a given DHCP server, all that matters is the underlying key.

It does the user no good to be able authenticate the last DHCP
server they used if they start cold when they see a new one.  The
whole point is to not trust a new one if one has acquired and
"pinned" DHCP key material for the network in question.

> authentication, or using a key that I have not cached.

So the attacker just has to block messages from the preferred DHCP
server for a few seconds, and he wins.

> precious.   If you want to rotate keys, change both the key and the

It seems to me that allowing transparent changes of the identity
largely defeats any potential benefit of TOFU for DHCP.  Given that
keys don't last forever, the issue must be given some attention.

> may not be easily changed. Or is there some other DHCP identifier

Ditto, I don't see how a fluid identity avoids defeating all benefit
from TOFU.

-- 
	Viktor.

---

From: Joe Touch <[email-masked]>
Date: Fri, 2 Sep 2016 08:57:21 -0700

On 9/1/2016 10:31 PM, Viktor Dukhovni wrote:
> not opportunistic, security. 
Again, I won't use the term "opportunistic" because it is insufficiently
defined.

Security is always based on a particular level of information and trust
in that information, whether that information is a key, a crypto
algorithm, or a protocol.

E-commerce allows for clients with unsigned keys and servers with keys
signed by known CAs or unknown CAs, and even servers without keys (yes,
there still are such pages floating around).

There's no "squarely mandatory" there. It's up to the user whether to
use a page without a displayed lock and whether to accept keys whose CAs
aren't known and trusted in advance. The e-commerce world does just fine
with the user-in-the-loop.

DHCP isn't special here. The same kind of lock (maybe server keys can be
signed by the same CAs used for the web?) or at least a very similar
interface is more than reasonable here, IMO.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Sep 2016 12:04:32 -0400

On Fri, Sep 2, 2016 at 11:16 AM, Viktor Dukhovni <[email-masked]>
wrote:

> server is legitimate for a given network.

True.

> Thus the "identity" you

Not true.   The identity is the identity of a DHCP server with which the
client either has or has not previously communicated.

> "pinned" DHCP key material for the network in question.

This is not quite the right mental model to have for how DHCP works.
There is no DHCP server for a network, any more than there is an ssh server
for a network.   There are zero or more DHCP servers reachable on any
particular network.   Also, only some networks can be identified as the
same network you were on before with the same identifier.   E.g., trusting
that "linksys" is my home network is doomed.

So if you have 802.1x, then what you are saying makes sense.   But very few
networks have 802.1x, because the 802.1x security model only works in a
very restricted set of circumstances.   Someone mentioned eduroam, but this
is actually a very, very special case.   Imagine if every environment
anyone worked in had something like eduroam.   How would the IETF NOC make
all of those different trust regimes work on the network at the same time?
  It's a cool hack, but it is not a general solution.

Back to the "DHCP server for the network" question, this question only
makes sense if the network can be identified.   Consider how this would
work on the IETF network: you'd have a DHCP server that would somehow be
able to make a claim of authenticity with regard to its relationship to
eduroam, and _also_ be able to claim authenticity with regard to its
relationship to the IETF network.

How are you going to make that work?   Too many moving parts.
Operationally challenging.   And what do you get in return for all this
work?

> server for a few seconds, and he wins.

How would an attacker do this?   Can we detect whatever method the attacker
would use?   You are right that if the attacker can do this, the attacker
can be sure of winning with respect to a particular conversation, but to do
this full time would bring down the network, and would be detected.   Also,
attackers can already do this with unauthenticated DHCP.

> keys don't last forever, the issue must be given some attention.

Why is a long-term identity useful?   When is a long-term identity useful?

> Ditto, I don't see how a fluid identity avoids defeating all benefit

Tofu makes it hard for a rogue DHCP server to supplant a legitimate DHCP
server on a network to which you have previously connected.   Unless you
are rolling your keys really frequently, it substantially reduces the
likelihood that a rogue DHCP server will be able to supplant the legitimate
DHCP server.   That is all it does in the case of ToFU.

It does not assert a meaningful identity for the DHCP server, so talking
about persistent identities for DHCP servers doesn't really make sense.
If you want a persistent identity, you should be using PKI, and the
identity is the identity claimed in the PKI cert and, likely, the cert that
signed it, _not_ the server identifier.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 2 Sep 2016 12:49:21 -0400

On Sep 2, 2016, at 12:04 PM, Ted Lemon <[email-masked]> wrote:
> So if you have 802.1x, then what you are saying makes sense.   But very few networks have 802.1x, because the 802.1x security model only works in a very restricted set of circumstances.

  I would argue that *most* networks today have 802.1X.  e.g. 3G, which is entirely authenticated.  And that most other networks (e.g. corporate) has no technical barriers to adoption of 802.1X.

  The remaining networks are open WiFi networks.  And with Hotspot 2.0, are also moving to 802.1X.

>   Someone mentioned eduroam, but this is actually a very, very special case.   Imagine if every environment anyone worked in had something like eduroam.   How would the IETF NOC make all of those different trust regimes work on the network at the same time?

  For AAA / 802.1X, there are existing standards, internet drafts, and implementations to make all this work.  There is no *technical* barrier to adoption.

>   It's a cool hack, but it is not a general solution.

   The solution for 802.1X in the IETF network exists today.

> Back to the "DHCP server for the network" question, this question only makes sense if the network can be identified.   Consider how this would work on the IETF network: you'd have a DHCP server that would somehow be able to make a claim of authenticity with regard to its relationship to eduroam, and _also_ be able to claim authenticity with regard to its relationship to the IETF network.
> 
> How are you going to make that work?

  The home AAA server shares the derived DHCP keys with the IETF AAA server, which in turn shares them with the local DHCP server, which uses them to sign packets.

  About 90% of this exists today.  All that is needed is a standard which describes how the keys are derived and shared over RADIUS, and then implementations on the client / server side.

>   Too many moving parts.   Operationally challenging.

  It's about 2K lines of new code, and ~100 lines of configuration file updates for my AAA / DHCP implementation.  The DHCP client side shouldn't be that much more code.  The IETF network already does EDUROAM.

  i.e. pretty trivial.

>   And what do you get in return for all this work?

  Increased security.  For not much more work than ToFU key management.

> Tofu makes it hard for a rogue DHCP server to supplant a legitimate DHCP server on a network to which you have previously connected.   Unless you are rolling your keys really frequently, it substantially reduces the likelihood that a rogue DHCP server will be able to supplant the legitimate DHCP server.   That is all it does in the case of ToFU.

  That's all good.

  Alan DeKok.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Sep 2016 10:50:10 -0400

> "pinned" DHCP key material for the network in question.

And wit the zillions of "starbucks" and "linksys" networks out there, I
wouldn't know a rogue one even if it hit me. Even pinning in to GPS
coordinates would probably throw me deep into False Positive Land.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Sep 2016 10:55:44 -0400

Sure, but if you go to the same Starbucks, wouldn't you want to be able to
have a heuristic for distinguishing between a server that worked before and
one that is competing with it?

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 8 Sep 2016 17:19:04 -0700

On Friday, September 2, 2016 9:05 AM, Ted Lemon wrote:

> On Fri, Sep 2, 2016 at 11:16 AM, Viktor Dukhovni <mailto:[email-masked]> wrote:
> Not true.   The identity is the identity of a DHCP server with which the client either has or 
> has not previously communicated.

I am reading that whole thread again, and I think the quoted exchange captures the nature of the 
problem. We are worried about two kinds of attacks: spoofing the DHCP server, and snooping on 
DHCP traffic. Encryption, including opportunistic encryption, removes the "passive snooping"
attack, and forces the attacker to mount an active spoofing attack. That seems useful, but
in practice active spoofing is quite common, and snooping is only a moderate concern -- it
can also be addressed by information reduction, e.g., the DHCP anonymity profile. But then,
there is no way to address the spoofing issue without also addressing the identity issue.

The identity cannot be just the identity of the server. Suppose that I have somehow trusted 
the server that I used in the nice coffee shop yesterday. If I see the same server available on
my office network, should I trust it? Of course not! So the "identity" question must include
first the identity of the network. It is something like "should I trust this DHCP server on that
network?" 

Once the network is identified, we may debate if TOFU is good enough to validate the 
Identity of the DHCP server. But if we don't somehow identify the network, this whole debate
Is meaningless!

-- Christian Huitema

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Sep 2016 20:41:04 -0400

Is there no DHCP server on your network at work?   Presumably at work you
use proper authentication, not ToFU, and so this problem goes away.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 9 Sep 2016 08:16:33 -0400

On Sep 8, 2016, at 8:19 PM, Christian Huitema <[email-masked]> wrote:
> my office network, should I trust it? Of course not!

  Similar things apply in 802.1X.  Let's say you connect to a network which has a certificate signed by a known CA.  Should you send that network your user credentials?

  Of course not.

  The CA signs hundreds of thousands of certificates a year.  That network could be anyone.  So you shouldn't trust the network.

  The solution in 802.1X land is to tie SSID to a self-signed ca.  My network uses my CA, and no one else can spoof it.   That CA is provisioned to the end-user machines via some out of band method.  e.g. a wired network in a physically trusted environment.

  It's annoying to manage, but it's the only way to be sure you trust the known network, and *don't* trust other networks. 

> So the "identity" question must include

  How do you identify the network?  Pretty much any publicly available information can be spoofed.

  You're left using a possibly spoofed MAC address / SSID to index a table of previously-discovered DHCP server certs.  It's better than nothing, I suppose.

> Identity of the DHCP server. But if we don't somehow identify the network, this whole debate

  I'm in favour of moving DHCP security forward.  I'm also in favour of tying security together through multiple protocols.

  Alan DeKok.