Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions

[Tom Henderson <[e-mail]>]

On 09/02/2014 10:22 AM, [e-mail] wrote:
> Hello,
>
> I am sorry for the late response...
>
>  >>
>  >>> (3) Continuing to support the 1536 MODP DHE group but not
>  >>> supporting the 2048 equivalent seems a bit odd, as does not having
>  >>> a code point for the 4096 but group. Similarly, making the 1536 bit
>  >>> group the MTI (in 5.2.7) is odd as is the assertion that "web
>  >>> surfing" can use a lower security level.
>  >>
>  >> I am not aware of the criteria that were used for choosing the DHE
>  >> groups. Can someone else comment on this?
>  >
>  > I don't recall offhand, other than that we went through a round of
>  > review with CFRG back in 2012 and we ended up modifying our crypto
>  > selections based on the feedback received.  Bob and Tobias have been the
>  > caretakers of the crypto selections in HIPv2 in general, so I defer to
>  > them.
>
> Ok, so let's wait to hear from Bob/Tobias on this one.
>
> I tried to reconstruct the approach that we took from the mailing list
> archives. This dates back to 2010 so I don't remember every detail. We
> use established algorithms that similar protocols used and discussed the
> choices here on the list. Here is the discussion thread:
>
> http://www.ietf.org/mail-archive/web/hipsec/current/msg03327.html
>
> There was some counseling from CFRG as well if I am not mistaken.
> However, if there is the need for a different set of algorithms or if
> there is consensus that more algorithms are required, there is no reason
> not to add another one.

How could we move this issue forward?  Stephen, would you advocate 
putting in 2048-bit and 4096-bit groups (perhaps with values 11 and 12 
respectively)?  Or is there not enough support for this proposal?

>
> The sentence with the web-surfing is a carry over from RFC5201. I think
> we should change it to a more generic statement along the lines of the
> mailing list post from 2010:

> Group 10 is meant for devices with low computation capabilities and
> should be used only if long-term
> confidentiality is not required.

I'll plan to put the above into the next revision, as it seems 
non-controversial.

- Tom