Subject: [dhcwg] AD review of draft-ietf-dhc-sedhcpv6-05

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Feb 2015 15:31:47 -0600

The mechanisms defined in this draft seem okay, modulo the secdir review which may turn up things I would miss.   However, the use model described is completely wrong, and I can't publish the document until that's fixed.

The problem is that there are a number of statements in section 7 that are simply not factual, and are going to cause massive pushback if we submit it without fixing them.   I'll go through these in order.

>    Because          
>    the client may have to validate the authentication in the condition          
>    of without connectivity wider than link-local, authentication with           
>    certificates may not always be feasible.

This statement doesn't make sense as written.   PKI certificate revocation can't be checked without network connectivity, but PKI certificates certainly can, if the DHCP client has a list of acceptable root certs and the server-supplied cert has a signature chain that validates.   And the client could check for certificate revocation before making the information received from the DHCP server available for general use.

So if there is a point to be made here, it must be something other than what the text actually says.   If the text can just be deleted, that would be fine, but if it can't, the WG needs to figure out what it's supposed to say.   It definitely doesn't make sense for it to say what it says.

>    So, this document only             
>    sticks on Leaf of Faith model, to make sure the client talks to the          
>    same previous server.

I realize that I am a repeat offender in the use of the term "leap-of-faith authentication," but the generally accepted term these days is Trust On First Use (TOFU).

>    Message integrity is provided.  But there is a chance for the client         
>    to incorrectly trust a malicious server at the beginning of the first        
>    session with the server (and therefore keep trusting it thereafter).         
>    But the leap of faith mechanim guarantees the subsequent messages are        
>    sent by the same previous server, and therefore narrows the attack           
>    scope.

This is all fine.

>    This may make sense if the network can be reasonably                 
>    considered secure and requesting pre-configuration is deemed to be           
>    infeasible.  A small home network would be an example of such cases. 

This is not.   The DHCP client has no way of knowing what kind of network it's connecting to on first use.   I think what you mean to say here is something like this:

    TOFU is a good model for connecting to networks the client does not recognize: if the network connection turns out to work, then remembering the successful authentication of the DHCP server for future uses of the network can prevent future attempts to attack clients on that network.

    When connecting to known networks, it may be desirable for the client to be pre-configured with a cert for DHCP servers on that network.   This can prevent attacks on first use of the network.   Examples of such networks can include the device owner's home network and networks operated by the device owner's employer.   However, in both cases the TOFU model still provides substantial protection from future attacks, as long as the validation occurs when no attack is in progress.

>                                                                                 
>    For environments that are neither controlled nor really trustworthy,         
>    such as a network in a cafeteria, while the leap of faith model,             
>    i.e., silently trusting the server at the first time, would be too           
>    insecure.  But some middle ground might be justified, such as                
>    requiring human intervention at the point of the leap of faith.

This statement doesn't make any sense, again because the client has no way of knowing that it is attaching to such a network.

The real use model has to be one of the following:

- Automatic TOFU
- TOFU only when confirmed by the end user
- Pre-configured cert

I think of these three, automatic TOFU actually provides a great deal of security in all three scenarios and it is okay to say so.   TOFU confirmed by the end user may or may not be better: the risk you might be trying to mitigate here is connecting to an entirely untrustworthy network.   But it's not at all clear to me that asking the user to help in this case is a good strategy, because users are notoriously uneducated about security, and may make exactly the wrong decision when asked to confirm a cert.

The third model, pre-installed certs, makes sense in a number of cases: the corporate case, the large Wifi provider case (e.g., Boingo) and the secure homenet case (although the UI issues there could be ... interesting).

In the case of Boingo and the corporate use case, a PKI cert that could be trusted as a signer would actually be a really great idea.   Otherwise every DHCP server has to have the same cert, and that creates a bit of a security vulnerability: an attack on an unattended server in some cafe that provides, e.g., Boingo hotspot service, would compromise the entire network, not just the network in that cafe.   Very short key valid lifetimes could render stolen certs less useful.

I do not think the draft actually needs to go through all these use cases in detail, because they are purely speculative.   But I mention them here because I think there is a lack of clarity in this section which needs to be addressed, and talking about the possible use cases is a good way to address that problem.

>    As for authentication on a server, there are several different               
>    scenarios to consider, each of which has different applicability             
>    issues.  If the server allows the leap of faith model, any malicious         
>    user can pretend to be a new legitimate client.  While the server can        
>    always be considered to have connectivity to validate certificate, it        
>    is feasible to check client certificates.

This doesn't make any sense to me.   What's the threat model that makes TOFU useful?   I can't think of one.   It doesn't help against DoS attacks.   I suppose it prevents one client from taking another client's address, but I'm not sure that's worth the effort.   And why install a cert on a client?   What's the use case?

>    Network administrators may wish to constrain the allocation of               
>    addresses to authorized hosts to avoid denial of service attacks in          
>    "hostile" environments where the network medium is not physically            
>    secured, such as wireless networks or college residence halls.  A            
>    server may have to selectively serve a specific client or deny               
>    specific clients depending on the identity of the client in a                
>    controlled environment, like a corporate intranet.  But the support          
>    from skilled staff or administrator may be required to set up the            
>    clients.

This is not true.   The use model I would expect to see here is that the client generates a key, possibly one key per server for privacy reasons, and then just uses that.   If the client has to register somehow to use the key, then you'd send it to a captive portal for registration, and that would be how the key would get into the server's database.   Requiring the network administrator to install a key on the laptop is not only too much work, it's actually potentially dangerous, because the network administrator may not be trustworthy with respect to the contents of the device's memory.

If it were up to me, I would simply delete section 7, and all the references to it elsewhere in the document, and simply provide the mechanism without saying how to use it.   I know Jinmei wanted to talk about use cases, but I think it harms the draft to do so when we haven't really seen how people will choose to use it.

In section 8, there are further problems, but I don't think there's much point in talking about them until we've talked about this.

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 9 Feb 2015 01:57:34 +0000

Hi, Ted,

Two quick responses below. I will try to give an update this week after discussion with you and co-authors.

>I realize that I am a repeat offender in the use of the term "leap-of-faith
>authentication," but the generally accepted term these days is Trust On First
>Use (TOFU).

So, shall I replace "leap of faith" by "Trust On First Use (TOFU)"? I am fine with it. Just need a double confirmation.

>If it were up to me, I would simply delete section 7, and all the references to it
>elsewhere in the document, and simply provide the mechanism without saying
>how to use it.   I know Jinmei wanted to talk about use cases, but I think it
>harms the draft to do so when we haven't really seen how people will choose
>to use it.

The section 7 was mainly contributed by Jinmei. So I will leave it to Jinmei's decision, either deleting this section or fixing Ted's concern soon. Jinmei, if you decide to keep the session, I need the new text by Thursday (Feb. 12), ideally after confirmation from Ted.

>In section 8, there are further problems, but I don't think there's much point in
>talking about them until we've talked about this.

Let's assume section 7 has been properly addressed, I need to work on section 8 parrallel in order to produce an update by Friday. Ted, could you give the details either public or private email?

Many thanks and best regards,

Sheng

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

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Feb 2015 10:58:08 -0800

At Sat, 7 Feb 2015 15:31:47 -0600,
Ted Lemon <[email-masked]> wrote:

> If it were up to me, I would simply delete section 7, and all the
> references to it elsewhere in the document, and simply provide the
> mechanism without saying how to use it.   I know Jinmei wanted to
> talk about use cases, but I think it harms the draft to do so when
> we haven't really seen how people will choose to use it.

What I wanted to see was an explanation of "why we need this
mechanism".  It doesn't have to be use cases; actually, a more formal
"threat analysis" documentation might be better.  In the previous
discussion on this fundamental point, (IIRC) no one showed persuading
explanation beyond "someone previously said they wanted to have it".
The idea of publishing "threat analysis" was rejected because it was
considered too time consuming.  So, as a compromise, we chose to add a
"use cases" section in this document.  That's also why the section is
largely speculative as you said in a different paragraph.

If this section raises concerns, we should certainly address them.
But totally removing the section will bring us to the very fundamental
discussion: we're providing a new protocol with on one
understanding/explaining why it's necessary.  And, whether it's a "use
cases" section or a formal analysis document, I believe there was a
pretty clear sense of the wg that we shouldn't publish the protocol
with completely ignoring the "why".

So, I guess we should probably reconfirm the sense of the wg again:
whether it's okay to publish the protocol part without explaining why
we need it.  If the mood of the wg has now changed and they say it's
okay, we should probably just drop this section and move forward.

I, for one, still believe it doesn't make sense to just publish the
protocol if no one understands why we need it.  Like before, however,
I'm fine with dropping the use case section from the protocol document
and publish a formal threat analysis first.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 14:30:03 -0500

On Feb 9, 2015, at 1:58 PM, 神明達哉 <[email-masked]> wrote:
> mechanism".

In my mind, the answer to this is that at present no mechanism exists for security DHCP messages between servers and clients that does not have a serious key distribution problem.   By using public-key-based authentication, we provide a mechanism for securing such messages that can be reasonably deployed without the key distribution problems inherent in the shared-secret-based authentication mechanism specified in RFC 3315, either using some form of PKI or else Trust-on-first-use (TOFU).

Why do we need to say more than this?

---

From: 神明達哉 <[email-masked]>
Date: Wed, 11 Feb 2015 09:55:31 -0800

At Mon, 9 Feb 2015 14:30:03 -0500,

> Why do we need to say more than this?

(Trying to recall the original discussion of "why") because, I guess,
a brief statement like this is too high level and is not very clear
about specifically what kind of problem this mechanism solves and why
it's better than an existing one(s).

Authenticating the server on a client using TOFU is probably the
clearest case: we can eliminate the need for manual key distribution
or exchanging keys in plain text at the risk of getting attacked on
first use.

Other cases are not that obvious: using a server certificate on the
client will require some tricky considerations (mainly due to the
chicken-and-egg nature - while it can be addressed as you noted in
your comment, but that wouldn't be obvious); if you think about some
more details, you'd realize using TOFU for authenticating the client
on a server doesn't make sense; if you need to manually configure
clients's public keys on a server, the operational cost wouldn't be
much different from the existing authentication mechanism as of
RFC3315; yet it wouldn't be too obvious how to securely and reliably
publish public keys or certificates of arbitrary clients.

Section 7 of the current draft is an attempt to address these
questions, but as you rightly pointed out, they are largely
speculative and can be controversial or even considered plain wrong
depending on expected assumptions.

Based on the conversation so far, I can think of the following options
for the next step:

1. revise Section 7 to something we can agree on.  it might not be
   feasible because of its speculative nature.  But if we can make it,
   that would be the most reasonable next step for a post WGLC
   document.
2. if the sense of the wg has changed and they now don't see the need
   for explaining why we need it beyond the very high level view like
   the you showed above, just remove Section 7 and move forward.  As I
   said in my previous response, I personally don't like this option,
   but if that's the new consensus of the wg I'm willing to accept it.
3. another radical idea: narrow down the scope of this document to the
   case of "TOFU + server authentication on a client".  I believe
   everyone understands the merit of this use case (to the extent of
   its own risks) and agrees the proposed solution is a good way to
   achieve it.  If we see clearer need for other cases where a good
   solution would be a mechanism like the one described in this
   document, then we can publish another document at that point by
   extending this one.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Feb 2015 14:36:58 -0500

>   that would be the most reasonable next step for a post WGLC

I think this is a lot of work with no clear benefit, since we can't actually know how people will use this until we make it possible for them to try it.

>   but if that's the new consensus of the wg I'm willing to accept it.

Thanks, this would be my preference.

>   document, then we can publish another document at that point by

I don't think this makes sense, because the point of the document is just to describe a mechanism, not suggest ways for using it.   I think item 3 above is a good idea, but should be pursued in a separate document, probably as a result of some experience from the field.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 12 Feb 2015 02:16:28 +0000

>Thanks, this would be my preference.

Separating the use cases could make us more focus on the solution and protocol procedures. We could always come back in the future to summarize the use cases in the practice. Maybe, the industry or market could develop more cases than we can clearly describe for now.

Best regards,

Sheng

>I don't think this makes sense, because the point of the document is just to
>describe a mechanism, not suggest ways for using it.   I think item 3 above is
>a good idea, but should be pursued in a separate document, probably as a
>result of some experience from the field.
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Feb 2015 09:57:06 -0800

At Thu, 12 Feb 2015 02:16:28 +0000,

> Separating the use cases could make us more focus on the solution and protocol procedures. We could always come back in the future to summarize the use cases in the practice. Maybe, the industry or…

To be clear: my current position is still against this option.  I'm
always in the camp of "problem first, then solution".  And that's
also the case of this document since around May 2014:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15520.html

Trying to publish a random idea in a (pretty) formal document like RFC
just because someone thinks it may be useful someday looks to me like
throwing random spaghetti to the wall with the wish that someone may
consider it a fine art.  Maybe that's how "innovations" work, and I
may be in the minority.  But at least around last May our consensus
should have been against that approach, hence the current organization
of the draft.  Just because it triggers a hot discussion doesn't
automatically dismiss the original concern and justify ignoring it.

Unless and until we see a clear wg consensus that we now allow it to
ship even if no one can explain what kind of problem it will solve, I
object to moving forward with just removing this section.  And, IMO,
this consensus change will require another round of WGLC.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2015 17:14:53 -0500

> http://www.ietf.org/mail-archive/web/dhcwg/current/msg15520.html

This is a fine idea in theory.   However, section 7 does not represent a valid problem statement.

> But at least around last May our consensus

It wasn't clear to me that there was a consensus to add the speculative use cases to the document, but I will leave that to the chairs to decide.

> this consensus change will require another round of WGLC.

That's a reasonable request.

But that said, let's be clear: we do actually have a problem.   The problem is that the authentication scheme described in RFC 3315 is not deployable, because it relies on a key distribution model that doesn't work with a typical DHCP deployment.   This document uses a key distribution model that would work better.   So this is definitely an improvement over RFC 3315.

It is however true that we do not know who would use this.   This document is very speculative.   And I can imagine other ways to solve this problem--for example, doing a shared secret exchange using public keys.   But these are problems that the working group has been aware of for over a decade, and we've made no forward progress.

The reason I support issuing this document as an RFC is that I think it would work, and would work better than what we have now, and I'd like to see if anybody will implement it.   Until there is a document to implement, clearly nobody is going to implement anything.

So that's why despite the lack of a use case document or a list of known use cases other than section 7, I think we should publish the document.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 13 Feb 2015 01:14:11 +0000

>It wasn't clear to me that there was a consensus to add the speculative use
>cases to the document, but I will leave that to the chairs to decide.
>
>But that said, let's be clear: we do actually have a problem.   The problem is
>that the authentication scheme described in RFC 3315 is not deployable,
>because it relies on a key distribution model that doesn't work with a typical
>DHCP deployment.   This document uses a key distribution model that would
>work better.   So this is definitely an improvement over RFC 3315.
>
>It is however true that we do not know who would use this.   This document
>is very speculative.   And I can imagine other ways to solve this problem--for
>example, doing a shared secret exchange using public keys.   But these are
>problems that the working group has been aware of for over a decade, and
>we've made no forward progress.
>
>The reason I support issuing this document as an RFC is that I think it would
>work, and would work better than what we have now, and I'd like to see if
>anybody will implement it.   Until there is a document to implement, clearly
>nobody is going to implement anything.
>
>So that's why despite the lack of a use case document or a list of known use
>cases other than section 7, I think we should publish the document.

There are two changes feedback from AD review, that would require another WGLC in my opinion:

1) remove the section that descript notional use cases, which does not represent a valid problem statement. It will result no use case description in the document. But the original problem, that no mechanism exists for security DHCP messages between servers and clients that does not have a serious key distribution problem, should be sufficient to motivate the proposed mechanism.
2) remove the limitation that only clients use PKI- certificates and only servers use public keys. The new text would allow clients use public keys and servers use PKI-certificates.

I will apply the above two changes and submit an update version today. Then DHC chairs may launch a short WGLC to see whether the WG could reach consensus on this. It would form the follow-up action.

Best regards,

Sheng

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Feb 2015 17:31:58 -0800

At Fri, 13 Feb 2015 01:14:11 +0000,

> 1) remove the section that descript notional use cases, which does not represent a valid problem statement. It will result no use case description in the document. But the original problem, that no…

I don't think we have a consensus on removing that section yet.  IMO
the right process is
- revise the draft addressing other comments from Ted
- start discussion on the wg about how to handle the usage section
- apply any result of the discussion to the draft and revise it.  at
  this point we may remove the section, revise it, or address the
  underlying issue in a different way.
- then start another WGLC

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2015 21:00:42 -0500

> - then start another WGLC

I don't understand why this section was added in the first place.   I objected to the idea of adding these use cases back when it was being talked about because I didn't think what was being proposed made sense; the result was the current version, which is more specific, but consequently is even worse because the use cases for this proposal are completely hypothetical.   I didn't have time to review the document again until the AD review, but the idea that there was consensus to include this text is only correct if you discount the objections I raised back in June of last year.

As far as I can tell the only person other than you who was in favor of adding this text was Ralph, and I am not convinced that he reviewed it again after it was added--the last comment I see from him in the archive is expressing support for the general idea, but objecting to the particulars, and that predates the addition of section 7 to the document.

I tend to agree that there is a need to get some clarity on the consensus for or against this text, and it may be that the right thing to do is give up on advancing this document during my tenure as AD.   If we wait for Terry to take over, then I can participate as a regular working group participant who has enough free time to actually stay on top of the discussion.

I don't see any reason to think that Terry would object to this work, and a rush to get this out before March when we are not in agreement doesn't seem like a good idea.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 13 Feb 2015 05:54:08 +0000

>I tend to agree that there is a need to get some clarity on the consensus for
>or against this text, and it may be that the right thing to do is give up on
>advancing this document during my tenure as AD.   If we wait for Terry to
>take over, then I can participate as a regular working group participant who
>has enough free time to actually stay on top of the discussion.
>
>I don't see any reason to think that Terry would object to this work, and a rush
>to get this out before March when we are not in agreement doesn't seem like
>a good idea.

OK. At least, we reach the consensus that we should continue to discuss this, rather than any rushing.

Personally, I don't take any strong position whether we should have use case description or not. My reading from Ted's comments is he did not really object (although he may prefer to not) to have use case description, but the current text for use case description has some serious issues. Am I right, Ted? If so, let's try to fix these text. Correct use case description are not harmful. However, we may state that these use cases are notional. Maybe, the industry or market could develop more cases than we can clearly describe for now.

Best regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Feb 2015 07:49:52 -0500

> Personally, I don't take any strong position whether we should have use case description or not. My reading from Ted's comments is he did not really object (although he may prefer to not) to have u…

If there were some clear description of actual use cases that did not exclude other plausible use cases, and that we thought would actually be useful, I would not necessarily object to that, but in that case it should be expressed as suggestions, not clear statements of what is right, because we have zero deployment experience and would just be speculating.

All things being equal, I think that such text is better left as future work, because it would be speculative.   But if we can come up with some solid use cases and explain how to do them, I'm okay with that.   The trick is that it can't just be a few paragraphs roughly outlining how to do it--it would have to be quite detailed.

If the consensus of the working group is to do that, I'll have some free time after March and would be happy to participate in making it happen--I do have some ideas for use cases.