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

From: Lishan Li <[email-masked]>
Date: Wed, 31 Aug 2016 17:47:52 +0800

Dear all,

According to the comments from Stephen and Randy, we have updated secure
DHCPv6. Thanks a lot for your previous help and guidance.

we previously dropped the idea of using TOFU for the authentication part
of dhcpv6, but we are now considering re-introducing it.  We dropped
the idea mainly based on a suggestion from Randy, and we are now
revisiting the decision based on a suggestion from Stephen.  We'd like
to resolve this conflict by understanding these suggestions in more
detail and by seeing if we can find some middleground/compromise/whatever
that everyone can at least live with.

So, it would be great if
- Randy could re-explain why we should drop TOFU, and whether it's
  acceptable to re-introduce it (and any conditions we should meet to
  do so).
- Stephen could explain why we should include TOFU, and whether it's
  acceptable to keep it out of scope.

Thanks
Lishan

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Aug 2016 12:42:50 +0100

Hiya,

> DHCPv6. Thanks a lot for your previous help and guidance.

And thanks for doing the work.

>   acceptable to keep it out of scope.

My basic argument here is that earlier specs for DHCP security
have not been deployed, so I think we should focus now on
specifying something that can be deployed easily, even if that
is not as good as one might desire. That's basically following
the logic of RFC 7435 [1] and, I think, argues for supporting
ToFU.

If, however, there's a good argument that something else is
what is more likely to be deployed, then I'd be convinced by
that.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc7435

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 31 Aug 2016 21:01:15 +0900

>   acceptable to re-introduce it (and any conditions we should meet to

tofu is a food; i often have it for breakfast with negi and shoyu.

i suspect that this is GMOBD, get married on blind date <tm>, with a
best man in the middle who has downgrade intentions.

[ please excuse extreme use of idiomatic american, but it was hard to
  resist ]

randy

---

From: Lishan Li <[email-masked]>
Date: Wed, 31 Aug 2016 20:38:32 +0800

Dear Stephen,

Thanks a lot for your kind reply.

In the current version, we describe the applicability part as follows:
The mechanism provides encryption in all cases, and can be used for
authentication based either on pre-sharing of authorized certificates, or
else using trust-on-first-use.

In the body of the draft, we mainly describes one possible scenario
based on pre-sharing of authorized certificates in detail. In this way,
the secure DHCPv6 can be deployed easily.

Best Regards,
Lishan

---

From: Randy Bush <[email-masked]>
Date: Thu, 01 Sep 2016 09:20:01 +0900

lishan,

> used for authentication based ... using trust-on-first-use.

uh, what is wrong with this picture?

---

From: Lishan Li <[email-masked]>
Date: Thu, 1 Sep 2016 09:37:36 +0800

Dear Randy,

This picture makes sense to all authors. But we don't know whether it makes
sense to you and Stephen or not.
So we want to get the precious comments from you and Stephen on this.

Thanks,
Lishan

---

From: Randy Bush <[email-masked]>
Date: Thu, 01 Sep 2016 10:42:47 +0900

>> uh, what is wrong with this picture?

what is authenticated?  tofu and authentication are antithetical.

randy

---

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

Dear Randy,

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

Best Regards,
Lishan

---

From: Randy Bush <[email-masked]>
Date: Thu, 01 Sep 2016 11:04:55 +0900

> In my initial thought, tofu is one method to achieve authentication.

it is not.  you have zero assurance of any authenticity.

calling it "secure" dhcpv6 when the parties will accept anything from
any monkey in the middle attacker is oxymoronic.

but i have had my say.

randy

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 1 Sep 2016 02:07:25 +0000

> 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: "Paul Hoffman" <[email-masked]>
Date: Wed, 31 Aug 2016 19:43:45 -0700

> uh, what is wrong with this picture?

Uh, the fact that you removed relevant parts of the quotation?

For those of you who want to follow more completely, the Abstract of 
draft-ietf-dhc-sedhcpv6-13 says:

    The mechanism provides encryption in all cases, and
    can be used for authentication based either on pre-sharing of
    authorized certificates, or else using trust-on-first-use.

So, we're back to the same problem described in glorious detail in RFC 
7435. In this case, if a DHCPv6  client wants to only use 
fully-authenticated security, and the DHCPv6 server has a certificate 
that the client can't validate, the client fails to communicate with the 
server. Some people will want that result and thus want to be able to 
configure to always require validation; others won't want to be blocked 
from the Internet and therefore will want either TOFU or (more likely) a 
warning each time an unvalidated connection is made.

--Paul Hoffman

---

From: Lishan Li <[email-masked]>
Date: Thu, 1 Sep 2016 11:37:53 +0800

Dear Paul,

Thanks a lot for your nice reply and guidance.
We just want to apply opportunistic security into secure DHCPv6 deployment.
So, how about the following policy for secure DHCPv6 deployment?
1. If the client/server is pre-configured with authorized certificates,
then it can achieve the authentication.
2. If the certificate cannot be validated and require validation, then it
is blocked from the Internet.
3. If the certificate cannot be validated and don't want to blocked from
the Internet, then it may want either TOFU or a warning each time an
un-validated connection is made.

Best Regards,
Lishan

2016-09-01 10:43 GMT+08:00 Paul Hoffman <[email-masked]>:

> fully-authenticated security, and the DHCPv6 server has a certificate that
> the client can't validate, the client fails to communicate with the server.
> Some people will want that result and thus want to be able to configure to
> always require validation; others won't want to be blocked from the
> Internet and therefore will want either TOFU or (more likely) a warning
> each time an unvalidated connection is made.
>
> --Paul Hoffman
>
>

---

From: Randy Bush <[email-masked]>
Date: Thu, 01 Sep 2016 14:58:51 +0900

[ 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