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

[Ilari Liusvaara <[e-mail]>]

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 <[e-mail]> 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