Subject: Re: [lisp] I-D Action: draft-ietf-lisp-crypto-01.txt

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 2 Jun 2015 14:53:19 +0300

On Tue, May 05, 2015 at 06:46:57AM +0000, Brian Weis (bew) wrote:
> Hi Ilari,
> 
> Thanks for your comments.
> 
> On May 2, 2015, at 12:22 AM, Ilari Liusvaara <[email-masked]> wrote:
> 
> > On Fri, May 01, 2015 at 04:04:03PM -0700, Dino Farinacci wrote:
> >> Folks, this draft contains the following changes:
> >> 
> >> B.1.  Changes to draft-ietf-lisp-crypto-01.txt
> >> 
> >>   o  Posted May 2015.
> >> 
> >>   o  Create cipher suites and encode them in the Security LCAF.
> >> 
> >>   o  Add IV to beginning of packet header and ICV to end of packet.
> >> 
> >>   o  AEAD procedures are now part of encryption process.
> > 
> > At least I can follow how the algorithms work. Remaining issues/notes:
> > - It composes AEAD mode instaed of using ready-made one. The composed
> >  mode is if nothing else slow (SHA-1 is already slower than some
> >  ready-made AEAD modes).
> 
> These are the algorithms we’re comfortable with for now. We could
> have specified the combined AEAD mode cipher modes, but they add
> complexity in the form of maintaining a counter for the nonce.

What kind of memory is the association data in? Something that isn't
volatile or which can't sustain fast updates?

Any reason why "count and if you lose position, just rekey" wouldn't
work.

Note that designing AEAD algorithms is quite nontrivial. And making
one with bad performance is easy too.

> > - Key derivation looks to be missing hashing in important parameters
> >  (like group and exchange keys) into secrets.
> 
> Not sure which parameters you mean? The DH shared secret is the
> key for the KDF, I’m not sure why we’d provide any other keys as input 
> to the KDF.

The problem is that by manipulating things like ciphers, groups or
exchange keys (even one-sided), attackers can make strange things
happen.

Hashing such parameters is especially important if some sort of
connection "figerprint" is provoded for MITM detection.

If unsure what to hash, just dump the LCAFs into session key
derivation as a whole.

At least TLS took nasty attacks from not hashing in the exchange keys
(g^x, g^y  or xG, yG).

Also, found another potential issue. There is no nonce field, which
means that public keys can't be safely reused, but must be regenerated
for each use.

This would be especially troublesome for computationally-limited and
memory-limited devices.

If one has no space for auxillary tables, one needs to do DH operation
to generate a key (which doubles key exchange CPU usage). With tables
one can push it to about one third of DH operation, but at cost of
tens (ECDH) or hundreds (DH) of kB of static tables.

Of course, when reusing DH keys, one shouldn't keep them valid for
too long. IIRC, Daniel J. Bernstein recommended ten seconds a while
back, and considered several hours some products did as too long.

> > - Some NIST-spec KDF? I think there are RFCs that describe KDFs.
> 
> Yes, there’s RFC 5869 but the NIST KDFs are also widely used.

I think RFC 5869 is much more used in IETF protocols than NIST KDFs.

> > - 1024-bit DH is regarded as quite weak nowadays.
> > - Two new ECDH functions from CFRG were recently annouced[1].
> >  Should be faster than DH1024/DH2048 with way smaller keys.
> 
> We do need less computationally demanding ciphers for deices that do
> crypto in ARM based platforms, which explains the 1024-bit DH (and yes,
> we realize it is weak). As stated in the Future Work section we will
> be looking at these ECDH functions and should have some results
> before the Prague meeting. If we can replace the 1024-bit DH we will.

Something came up when investigating the TLS Logjam mess. Experts
guess that NSA has computed "logarithm tables" for a few common
1024-bit DH groups. Those tables allow breaking DH very quickly.

The authors of research on TLS Logjam recommended regarding use of DH:
- Use ECDH (beweare of weak 160-bit curves and backdoored curves)
- Named (fixed) groups need to be 2048 bits at least (beware of back-
  doored groups)
- If needing to use 1024-bit DH, generate your own group and change
  it frequently.
- Don't use <1024 bit DH at all.

-Ilari

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Jun 2015 08:26:51 -0700

Ilari, Brian is on vacation so I’ll take a stab at this. I’m sure he’ll reply when he returns.

> volatile or which can't sustain fast updates?

The AD is the LISP header. And for each packet there is a 24-bit nonce (designed for other purposes previously but can be used in this application as well). It can sustain fast updates.

> Any reason why "count and if you lose position, just rekey" wouldn't

The IV could be used for this purpose. But right at the moment, there is no way for the ETR to tell the ITR to rekey. So the rekeying interval is equivalent to the RLOC-probing interval.

> one with bad performance is easy too.

I don’t think we have that here.

> exchange keys (even one-sided), attackers can make strange things

Meaning if you use the DH public-keys too often, they can be hacked?

> connection "figerprint" is provoded for MITM detection.

We use the Map-Request nonce for such a fingerprint. And that will be seen only in two packets. Each new RLOC-probe contains a new nonce (this is a 64-bit nonce), and if the ITR changes its public-key (1024 or 2048 bits in length), then a rekey event is occuring.

> If unsure what to hash, just dump the LCAFs into session key

Well the context for the hash is in the spec. So please comment specifically on it. Thanks.

> At least TLS took nasty attacks from not hashing in the exchange keys

I have found with prelim testing that g^x is taking 8 times longer than xG. So I would like to hear from you about what ECDH groups are safe.

> means that public keys can't be safely reused, but must be regenerated

That is what we are doing. Or do you mean here for each packet encapsulated, that is considered “a use”?

> tens (ECDH) or hundreds (DH) of kB of static tables.

Hmm. We don’t want to require tables of any kind.

> back, and considered several hours some products did as too long.

We can do that with RLOC-probing, but 802.1AE MacSec is rekeying every 600ms. But this could be considered a completely different application. Do you have any thoughts about that?

> 1024-bit DH groups. Those tables allow breaking DH very quickly.

We don’t have any problems using longer keys since the Map-Request and Map-Reply packets right now for RLOC-probing are relatively small to the effective MTU size.

> - Don't use <1024 bit DH at all.

Does that mean we have to create dynamic cipher suites if we use 1024-bit keys?

> -Ilari

Thanks for your valuable comments.

Dino

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 7 Jun 2015 20:09:25 +0300

> The AD is the LISP header. And for each packet there is a 24-bit nonce (designed for other purposes previously but can be used in this application as well). It can sustain fast updates.

24-bit space would wrap around quite fast. But maybe that could be
implicitly extended.

> The IV could be used for this purpose. But right at the moment, there is no way for the ETR to tell the ITR to rekey. So the rekeying interval is equivalent to the RLOC-probing interval.

Well, most AEAD algorithms have too short nonces to randomly generate
(it is usually 96 bits, which is just too short for random generation).

> I don’t think we have that here.

The fastest secure hash currently known is slower than Chacha20-Poly1305
(and if one has hardware AES-GCM, that is faster still).

> Meaning if you use the DH public-keys too often, they can be hacked?

Meaning that if DH public keys are copied and pasted into unexpected
places, strange things can happen.

Best to ensure that key computations just fail to produce matching
keys if this happens.

I don't know much about this, considering how obscure the attacks are
here.

> We use the Map-Request nonce for such a fingerprint. And that will be seen only in two packets. Each new RLOC-probe contains a new nonce (this is a 64-bit nonce), and if the ITR changes its public-…

Not good. For secure fingerprint, one needs to hash at least the
crypto parameters (e.g. groups and ciphers) and exchange keys
(the public keys).

Otherwise attacker replacing those parameters and get identical
fingerprints on both sides, despite MITM position.

> I have found with prelim testing that g^x is taking 8 times longer than xG. So I would like to hear from you about what ECDH groups are safe.

CFRG recommended ECDH groups are Curve25519 and Curve448 (which is pretty
straightforward extension of Curve25519 to larger prime).

https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/?include_text=1

> That is what we are doing. Or do you mean here for each packet encapsulated, that is considered “a use”?

Each key exchange is "use".

> Hmm. We don’t want to require tables of any kind.

One does not need the tables, it just speeds up calculating public
key. Which one needs to do for each key exchange due to lack of nonce.

With nonces and reusing public keys, one could e.g. recalculate the
public key every 10 seconds.

> We can do that with RLOC-probing, but 802.1AE MacSec is rekeying every 600ms. But this could be considered a completely different application. Do you have any thoughts about that?

This was about how long to keep DH keys, not how long to keep the
resulting session key.

> We don’t have any problems using longer keys since the Map-Request and Map-Reply packets right now for RLOC-probing are relatively small to the effective MTU size.

I agree with the recommendation that fixed (discrete) DH groups should
be 2048 bits at least.

> Does that mean we have to create dynamic cipher suites if we use 1024-bit keys?

Yeah, and that creates all sorts of problems.

-Ilari

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Jun 2015 13:02:01 -0700

> On Jun 7, 2015, at 10:09 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

We are not using it as a counter. It is a random number selected for each packet. But we have an IV in the payload that can (recommended in spec) be used as a counter. It is 16 bytes in length. 

> (it is usually 96 bits, which is just too short for random generation).

We use the control-plane LISP nonce which is 64-bits. 

> (and if one has hardware AES-GCM, that is faster still).

Do you recommend poly1305 for a hash?

> I don't know much about this, considering how obscure the attacks are

Okay - let's crawl before we walk and see how this turns out. I have finished an implementation of the -01 spec and will present in Prague. I hope to try other cipher suites that are not in -01 and report on it. 

> crypto parameters (e.g. groups and ciphers) and exchange keys

We were told buy many to not transfer such information but to do a registry that defined cipher suite values. 

> fingerprints on both sides, despite MITM position.

Don't forget that the attacker has to also compromise the map-server. Because the Map-Replies are signed with a trust relationship between the real ETR and the map-server it registers EID-prefixes to. 

>  extension of Curve25519 to larger prime).
> 

Will check it out. Thanks.

> Each key exchange is "use".

Okay then I think we are good. 

> key. Which one needs to do for each key exchange due to lack of nonce.

We can leave this as an implementation option. Meaning we shouldn't spec "how its done". 

> This was about how long to keep DH keys, not how long to keep the

Got it. 

> I agree with the recommendation that fixed (discrete) DH groups should

Ack. 

> Yeah, and that creates all sorts of problems.

Thanks again and let's see Brian's comments. 

Dino