Subject: [Lwip] Stephen Farrell's Discuss on draft-ietf-lwig-ikev2-minimal-05: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 03 Dec 2015 06:58:23 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-lwig-ikev2-minimal-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'll be a yes ballot but I'd like to chat briefly if that's ok, just
to check the level of consensus behind the algorithm choices
documented here.  For example, is A.3.2 recommending that only
AES_CBC and AES-CCM_8 ought be implemented?  And would we still
recommend 1536 D-H and wouldn't 2048 by itself be sufficient?
Shouldn't you be clear about that kind of stuff? (I mean what algs
you're telling folks to implement in appendix A.)  Did the WG
discuss all those kinds of decision? (Or are they just what you
implemented?) 

The reason this is a discuss is just so that we're clear about the
algorithm stuff - I suspect a bunch of folks will just do what this
document says (or have already) so ensuring these choices are good
ones that the WG actually thought about now is I think worthwhile.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Would it be worth waiting on 25519 for this? Would the code-size and
CPU improvements be better than publishing now? I guess it could be
that the CPU improvement mightn't be as good on smaller CPUs (not
sure), but I just figured it'd be good to ask since work on 25519
for IPsec is under way and it should have some benefits. (I'm fine
though if the answer here is "no, not yet" in which case, there's no
need to even respond to me:-)

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Dec 2015 02:25:31 +0200

Stephen Farrell writes:
> AES_CBC and AES-CCM_8 ought be implemented?

No. This document does not give any recommendations for the
algorithms. The normal IPsec way is that we do not list mandatory to
implement algorithms in protocol documents. We have separate documents
for them, i.e. RFC4307 for IKEv2 (or most likely the RFC4307bis
version which is now work in progress in the IPsecME WG) and RFC7321
for ESP and AH.

The algorithms in the appendex A is just subset of the algorithms
which are most likely to be useful for the person implementing minimal
IKEv2. The actual algorithms that will be used are most likely be
something that depends on the environment.

I.e. if this is used in the 802.15.4 environment, where the hardware
already has everything needed for the AES-CCM, then IKEv2 SA and ESP
SA are most likely using AES-CCM too. 

> And would we still recommend 1536 D-H and wouldn't 2048 by itself be
> sufficient?

The RFC4307bis in the IPsecME WG will most likely say that 2048 bit
MODP group is mandatory to implement, but I would expect that
constrained devices might want to use ECP or smaller MODP groups
instead. 

> Shouldn't you be clear about that kind of stuff? (I mean
> what algs you're telling folks to implement in appendix A.) Did the
> WG discuss all those kinds of decision? (Or are they just what you
> implemented?)

What will be used and what will be implemented will quite often be
same in the constrained use cases. I.e. they first decide what they
will use, and will only implement that. This will most likely make
those implementations non-conforming to the IKEv2, as they might not
implement all mandatory to implement algorithms. On the other hand
RFC4307bis etc tries to keep algorithms for constrained devices as a
SHOULD, so minimal IKEv2 implementations using suitable algorithms for
them will be able to talk to the full IKEv2 implementations as they
implement those algorithms too.

On the other hand, in the constrained environment the "server" and
"client" end of the connections are usually tied together, i.e. they
follow same profile which will then specify the algoritms which will
be used.

All of that is outside the scope of this document. This document do
assume that we follow normal mandatory to implement algorithms as
specified by the already existing separate RFCs.

In the IPsecME WG, there was discussion whether we should have two
profiles in the RFC4307, one for the constrained devices, and another
for normal devices. I.e. whether the mandatory to implement algorithms
for constrained devices should be different than what is required for
full implementations.

This is still ongoing discussion on the IPsecME WG, and this document
will assume implementors follow whatever the final bis document will
say.

> ones that the WG actually thought about now is I think worthwhile.

As I said earlier, this document does not try to propose any specific
set of algorithms, it mostly just removed those algorithms which was
seen unneeded for minimal implementations.

> Would it be worth waiting on 25519 for this?

There is no implementations implementing that yet, so I think it is
too early to put that in. Also those implementations we had for this
minimal ikev2, did not support anything else than MODP Diffie-Hellman,
so we could not claim that we have implementation experience about
those groups.

> Would the code-size and CPU improvements be better than publishing
> now?

As this document does not restrict or give any guidance for selection
of the algorithms (except it says that in the constrained environment
there will most likely be exactly one configured algorithm set), there
is no problem of someone picking that curve in the future for their
environment when that curve has been standardized for IPsec.

> I guess it could be that the CPU improvement mightn't be as
> good on smaller CPUs (not sure), but I just figured it'd be good to
> ask since work on 25519 for IPsec is under way and it should have
> some benefits. (I'm fine though if the answer here is "no, not yet"
> in which case, there's no need to even respond to me:-)

I think we would need to get some implementation experience on the
constrained devices before we can say how well the curve25519 will
work on those devices. In theory it should work ok, but theory does
not always agree with the actual implementations :-)
-- 
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2015 17:33:14 +0000

Hi Tero,

Sorry for the slow response

> version which is now work in progress in the IPsecME WG) and RFC7321

Sure, but since we're cut'n'pasting here I figured you might want
to do more (I see below you don't and that's fine).

> SA are most likely using AES-CCM too. 

Fair enough.

> constrained devices might want to use ECP or smaller MODP groups

Meh, I'd say though that not mentioning 1024 RSA or 1536 DH would
be a lot better. Given that you're not specifying what's MTI why
is it a good idea to include those? As is, someone will clam that
they're ok using 1024 bit is ok when they didn't really need to
do that.

The rest is fine,
Cheers,
S.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Dec 2015 15:51:32 +0200

Stephen Farrell writes:
> be a lot better.

About the RSA key sizes: The 1024 bit RSA is direct copy from the
RFC7296, so thats why it is there.

About the DH key sizes: Current mandatory to implement Diffie-Hellman
group in IKEv2 is 1024-bit DH, but as we are going to change that in
RFC4307bis, I removed it from the list already. The rfc4307 will be
saying MUST for 2048 bit DH, so thats why that is there, but as this
is for constrained devices, there may be some use for 1536-bit DH
still.

> Given that you're not specifying what's MTI why is it a good idea to
> include those? As is, someone will clam that they're ok using 1024
> bit is ok when they didn't really need to do that.

As I said 1024-bit RSA is still mandatory to implement in IKEv2. If
you feel that it is not safe anymore, then we most likely need to put
that in the RFC4307bis too, i.e. change the mandatory to implement
authentication methods of IKEv2. Now we just change the crypto
algorithms, but do not change requirements for certificates or
authentication methods.

Anyways that is something that needs to be discussed in the IPsecME WG
when working on the 4307bis (I will start a thread).

1536-bit DH is still considered to be several thousand times harder to
break than 1024-bit DH, so it should be ok for small IoT devices for
some time. Also quite a lot of information transmitted by those
devices are not really things that require confidentiality for years.

Yes, you do not want to leak that your room temperature is lowered by
5 degrees so burglers do not know that you are not at home, but quite
often does not matter if NSA gets that information after cracking your
1536-bit DH using years of CPU time. They most likely already had that
information from your plane tickets. And nothing prevents using
stronger groups if confidentiality is really an issue.
-- 
[email-masked]