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

[Brian Haberman <[e-mail]>]

On 7/10/15 1:17 PM, 神明達哉 wrote:
> At Fri, 10 Jul 2015 11:14:12 -0400,
> Brian Haberman <[e-mail]> wrote:
> 
>>      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.
> 
> Thanks for the careful read and detailed review.  I'm responding to a
> few selected points...
> 
>> 1. General
>>
> 
>> * 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.
> 
> 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...

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.

> 
>> * 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.
> 
> 
> 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.

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.

> 
>> * 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?
> 
> 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.

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