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

From: [email-masked]
Date: Tue, 2 Sep 2014 19:22:41 +0200

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. 

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.

BR,

Tobias

-- 
Dr. Tobias Heer | Head of Embedded Software Development - Functions | 
Hirschmann Automation and Control GmbH
Stuttgarter Str. 45-51 | 72654 Neckartenzlingen | Germany
Phone: +49 7127 14 - 1280 | Mobile: +49 171 441 49 22 | Fax: +49 7127 14 - 
1600
[email-masked] | www.beldensolutions.com | 
www.blog.beldensolutions.com

Hirschmann Automation and Control GmbH, Neckartenzlingen
Register Court: Stuttgart, Trade Register No.: HRB 225927
VAT No.: DE 814 212 604
Managing Director: Christoph Gusenleitner, Henk Derksen, Wolfgang Schenk, 
Johannes Pfeffer

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

---

From: Tom Henderson <[email-masked]>
Date: Wed, 03 Sep 2014 21:56:49 -0700

On 09/02/2014 10:22 AM, [email-masked] wrote:
> archives. This dates back to 2010 so I don't remember every detail. We
> use established algorithms that similar protocols used and discussed the
> 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

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

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

- Tom

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Sep 2014 08:48:19 +0100

Hiya,

On 04/09/14 05:56, Tom Henderson wrote:
> respectively)?  

I would advocate putting in the 2048 bit group yes. I figure
you probably don't need the 4096 one on the basis that before
one would go there you'd want to switch to some form of ECC.
So I'd not argue to define a codepoint for the 4096 bit group
for now myself, but equally, I'd not argue against doing so.

> Or is there not enough support for this proposal?

I'm fine that that's a WG chair call.

And now that we've discussed the topic, I've cleared that
point in any case, moving to a no-objection overall.

Thanks for the discussion.

Cheers,
S.

---

From: Tom Henderson <[email-masked]>
Date: Thu, 04 Sep 2014 06:56:04 -0700

> for now myself, but equally, I'd not argue against doing so.

I'm fine with that (adding the 2048 bit group).  I propose to add it as 
"value 11" in the list.  I'll wait a few days for concurrence or lazy 
consensus before making the change, however.

- Tom

---

From: Rene Hummen <[email-masked]>
Date: Sat, 6 Sep 2014 07:25:14 +0000

On 04 Sep 2014, at 15:56, Tom Henderson <[email-masked]> wrote:

> I'm fine with that (adding the 2048 bit group).  I propose to add it as "value 11" in the list.  I'll wait a few days for concurrence or lazy consensus before making the change, however.

+1

René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/