Subject: [dhcwg] AD Evaluation: draft-ietf-dhc-sedhcpv6

From: Brian Haberman <[email-masked]>
Date: Fri, 10 Jul 2015 11:14:12 -0400

All,
     I have performed an initial review of draft-ietf-dhc-sedhcpv6 as a
part of the publication process.  As a heads up, I have also solicited a
security-related review that should be available by the Prague meeting.

     The following comments/questions came up during my review.

1. General

* I am very concerned about the lack of discussion of *how* a PKI will
function in this approach. This is similar to the general failure of
SEND, in that you need addresses in order to communicate with the PKI
unless it is local to the link.  With symmetric keying, there is a known
process that can be carried out, albeit not in a scalable way. With a
PKI, I can see how it can work for a server verifying messages coming
from clients, but I don't see how it works robustly for clients
verifying messages coming from a server.  At a minimum, I would like to
see a section that discusses some of these limitations in detail.  I
cannot say how the security ADs will react to this approach though.

* While I see the benefit of TOFU in certain settings (e.g., enterprise
networks), I am skeptical of how well that will work in a wireless
hot-spot setting (e.g., Starbucks).  An attacker sitting at the table
next to me will have the advantage of low RTT in order to become the
"trusted" server. The draft should provide more guidance on how TOFU
should/could be applied in this context.

* I think the document as a whole would benefit from the inclusion of a
state diagram in order to ensure that all the possible scenarios and
message processing descriptions are complete.

2. I see the following text in Section 4:

   A trust relationship for a public key can be the result either of a
   Trust-on-first-use (TOFU) policy, or a list of trusted keys
   configured on the recipient.

How is a list of trusted keys any different than a set of
pre-established secret keys? In other words, would that approach be any
different than the status-quo?

3. In Section 4.2, I see:

   It is NOT RECOMMENDED that the same sender and recipient use various
   algorithms in a single communication session.

What constitutes a session? There is a rather weak definition in 3315
based on the client sending Solicit messages.  It could be good to give
a more concrete definition in this document.

4. Section 5.3 says that the signature field may be padded. How does the
receiver know where the padding is located within the signature?

5. Section 5.4, you specify the use of the NTP Timestamp format.  Do you
have any concerns on how that will function when the current epoch ends
February 8, 2036?  If so, you could use the NTP Date format.

6. Section 6.1

* The text about the number of timestamp options seems odd ("A Secure
DHCPv6 message SHOULD contain one and only one Timestamp option").  Do
you really mean "A Secure DHCPv6 message MUST contain 0 or 1 Timestamp
options"?  If that is the case, how does the recipient handle multiple
timestamp options in section 6.2?

* The 4th paragraph says "A Secure DHCPv6 message sent by a DHCPv6
server or a client, which may be encapsulated by a Relay-forward or
Relay-reply message..."  How does a client know if its message will be
handled by a relay?

* The text says a sender receiving an authentication failure response
SHOULD NOT retry the message with the same certificate.  I am not sure
why this is not a "MUST NOT". In what scenario would retrying with the
same certificate lead to a different response code?

* The text in 6.2 says that its an error for a DHCPv6 message to have
both a Public Key option and a Certificate option. However, the text in
6.1 is a little looser depending on how you parse the "or" in the 4th
paragraph.  This should be tightened up.

7. Section 6.2

* How does a client do certificate validation?

* How do TOFU policies interact with validation failures?

* The last paragraph states that any Relay messages that contain public
key, certificate, or signature options is invalid and MUST be discarded.
 The text in 6.3 says relays SHOULD NOT add any security options.  Why
isn't the guidance in 6.3 not a "MUST NOT"?

8. Section 6.4 - For clarity, I would suggest specifying that RDnew and
TSnew come from the received Timestamp option.

Regards,
Brian

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Jul 2015 10:17:01 -0700

At Fri, 10 Jul 2015 11:14:12 -0400,

>      The following comments/questions came up during my review.

Thanks for the careful read and detailed review.  I'm responding to a
few selected points...

> should/could be applied in this context.

TOFU won't be a good choice for scenarios like a public wifi at a
cafe.  An earlier version of the draft attempted to discuss the
applicability matters in a bit more detail:
https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-06#section-7
but, after a long follow-up discussion in the wg, we decided to remove
such considerations.  That was partly because the proposed deployment
discussion was largely speculative and it looked less likely that we
could get an agreed view as a group in the wg.  Also, some wg members
rather preferred to just define the protocol and leave how to deploy
it to people implementing and deploying it.  I'm not sure if it was a
"wg consensus" as not many people spoke up, but it looked it was only
me who wanted to include such discussions.  In the end, we decided to
remove most of these considerations and shipped it.

Knowing this background history, I'm not sure if we can now agree on
re-introducing (with possibly revising) the removed discussions, let
alone on specific text about it.  But I'll see other wg members'
opinions at the moment...

> function in this approach. [...]  At a minimum, I would like to

I guess this is a variant of the previous point.  I'm pessimistic
about the possibility of even getting a consensus on including such a
discussion, but if these concerns are going to be a blocking issue,
the only alternative is to drop the draft entirely, which is not good
either.  So we might be able to come up with some kind of concession.
If the "minimum" approach is acceptable for the IESG, that may be one
realistic possibility.

> different than the status-quo?

In my understanding it's certainly different but quite subtle:
https://mailarchive.ietf.org/arch/msg/dhcwg/wPM0csdxm8XZ_h203OWjgsQGZPg

Others seemed to have other ideas on such differences (see the thread,
warning: it's very long:-).  My hope was to understand what it is and
include the result in the draft, but, in the end, I failed even to
understand what the difference is.  Whether or not to include it in a
revised version of this draft, it would be nice if I can understand it
this time in this discussion.  But, again, I'll see what others think
about this at the moment.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jul 2015 19:28:08 -0400

> If the "minimum" approach is acceptable for the IESG, that may be one

The general intention of this work as it was originally envisioned was (at least in my mind!) to define a building block upon which a variety of solutions could be built.   There are a lot of different scenarios that one could imagine, but none that I think are seriously being contemplated.   The idea with this document is to say what to put on the wire, and then leave it as a next step to define various profiles that make sense in different contexts, like the corporate context or the hotspot context.

My opinion on this wasn't agreed to by everyone, so I'm not claiming to speak for the working group in this response, but this is how I see it.   I tend to agree with your general notion that the document is incomplete as it is, but I am hoping that having developed the wire protocol we can now move on to doing stuff with it.

The problem with just doing the wire protocol and the profiles in the same document is that the profiles aren't very baked, whereas the wire protocol is: we know what we want to do on the wire, but we really don't agree as to what we want to do in terms of PKI.   So the hope is that we can play around with various PKI solutions and get some consensus on one or more such solutions that could actually be documented.

To be clear, I know exactly what _I_ want to do with the specification; the problem is that there is no consensus in the working group that what _I_ want is the right thing.   I think Jinmei-san is in the same boat.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 Jul 2015 08:34:03 -0400

> opinions at the moment...

The problem is that a client doesn't have a good way to determine *what*
kind of environment it is in.  It seems like you need a mechanism for
reliably identifying the network prior to sending a SOLICIT.

> If the "minimum" approach is acceptable for the IESG, that may be one

In my opinion, you would have to strip the document down to just the
on-wire protocol and include an applicability statement that spells out
that these messages are building blocks for a solution rather than a
complete solution.

However, a brief discussion with a few folks indicate that punting on
the *how* to make this work in a solution may be met with severe resistance.

> about this at the moment.

I think we will get more-detailed feedback from the security review that
is ongoing related to this point.  What would help matters, for me, is
an example that highlights the differences between the two points.

But, it may be worthwhile to hold off until we get those additional
review comments.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 Jul 2015 08:39:20 -0400

On 7/10/15 7:28 PM, Ted Lemon wrote:
> On Jul 10, 2015, at 1:17 PM, �����_�� <[email-masked]> wrote:
>>> * I am very concerned about the lack of discussion of *how* a PKI
>>> will function in this approach. [...]  At a minimum, I would like
>>> to see a section that discusses some of these limitations in
>>> detail.  I cannot say how the security ADs will react to this
>>> approach though.
>> 
>> 
>> about the possibility of even getting a consensus on including such
>> a discussion, but if these concerns are going to be a blocking
>> issue, the only alternative is to drop the draft entirely, which is
>> not good either.  So we might be able to come up with some kind of
>> concession. If the "minimum" approach is acceptable for the IESG,
>> that may be one realistic possibility.
> 
> The general intention of this work as it was originally envisioned
> was (at least in my mind!) to define a building block upon which a
> variety of solutions could be built.   There are a lot of different
> scenarios that one could imagine, but none that I think are seriously
> being contemplated.   The idea with this document is to say what to
> put on the wire, and then leave it as a next step to define various
> profiles that make sense in different contexts, like the corporate
> context or the hotspot context.
> 
> My opinion on this wasn't agreed to by everyone, so I'm not claiming
> to speak for the working group in this response, but this is how I
> see it.   I tend to agree with your general notion that the document
> is incomplete as it is, but I am hoping that having developed the
> wire protocol we can now move on to doing stuff with it.

As I said in response to Jinmei, this document is not just the on-wire
protocol.  It would need to be stripped down some to avoid any of the
speculative statements about PKI.  That is, a clear applicability
statement that this document is not a complete solution would be needed.

> 
> The problem with just doing the wire protocol and the profiles in the
> same document is that the profiles aren't very baked, whereas the
> wire protocol is: we know what we want to do on the wire, but we
> really don't agree as to what we want to do in terms of PKI.   So the
> hope is that we can play around with various PKI solutions and get
> some consensus on one or more such solutions that could actually be
> documented.

This opens up another question... What happens if a profile leads to a
need for changes to the on-wire protocol?  I would hope that there are
some expected profiles that led to the formulation of the on-wire
protocol and that those are more baked than others.

> 
> To be clear, I know exactly what _I_ want to do with the
> specification; the problem is that there is no consensus in the
> working group that what _I_ want is the right thing.   I think
> Jinmei-san is in the same boat.
> 

That doesn't mean that you can't publish a draft describing what you
want to do with this wire protocol.

Regards,
Brian

---

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Jul 2015 09:13:57 -0700

At Mon, 13 Jul 2015 08:34:03 -0400,

> reliably identifying the network prior to sending a SOLICIT.

I see the issue.  I have some idea in response to it, but it'll
probably be another speculative discussion and can be unnecessarily
controversial in the context of this thread, so I'll hold off for now.

> that these messages are building blocks for a solution rather than a

I agree this can be one possible and realistic way to move forward,
and,

> the *how* to make this work in a solution may be met with severe resistance.

I'm also afraid it may not be acceptable.  So,

> But, it may be worthwhile to hold off until we get those additional

I'll hold off for now.  I also expect there will be a discussion on
the draft including these points in Prague.

--
JINMEI, Tatuya