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

[神明達哉 <[e-mail]>]

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

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

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

--
JINMEI, Tatuya