[lisp] Review of draft-ietf-lisp-crypto-00

[Ilari Liusvaara <[e-mail]>]

> 4.  Encoding and Transmitting Key Material
> 
>    The Diffie-Hellman key material is transmitted in Map-Request and
>    Map-Reply messages.  Diffie-Hellman parameters are encoded in the
>    LISP Security Type LCAF [LCAF].
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |           AFI = 16387         |     Rsvd1     |     Flags     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Type = 11   |      Rsvd2    |             6 + n             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Key Count   |      Rsvd3    | Key Algorithm |   Rsvd4     |R|
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |           Key Length          |       Key Material ...        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        ... Key Material                       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |              AFI = x          |       Locator Address ...     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>           Diffie-Hellman parameters encoded in Key Material field
> 
>    The 'Key Count' field encodes the number of {'Key-Length', 'Key-
>    Material'} fields included in the encoded LCAF.  A maximum number of
>    keys that can be encoded are 3 keys, each identified by key-id 1,
>    followed by key-id 2, an finally key-id 3.
> 
>    The 'R' bit is not used for this use-case of the Security Type LCAF
>    but is reserved for [LISP-DDT] security.
> 
>    The 'Key Algorithm' encodes the cryptographic algorithm used.  The
>    following values are defined:
> 
> 
> 
> 
> 
> Farinacci                 Expires July 16, 2015                 [Page 4]
> 
> Internet-Draft       LISP Data-Plane Confidentiality        January 2015
> 
> 
>    Null:        0
>    Group-ID:    1
>    AES:         2
>    3DES:        3
>    SHA-256:     4

These don't look to be of the same type? And 3DES in 2015? If you want
serious backup for AES, there is Chacha20.

Also, one can't encrypt data with AES, one also needs mode for it.

Basically, for encryption strapped on top of DH, you need:

- (EC)DH group (or monoid)
- Hash function to use for key derivation.
- AEAD cipher.

>    When the 'Key Algorithm' value is 1 (Group-ID), the 'Key Material'
>    field is encoded as:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Group ID                             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Public Key ...                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>              Points to Key Material values from IANA Registry
> 
>    The Group-ID values are defined in [RFC2409] and [RFC3526] which
>    describe the Diffie Hellman parameters used for key exchange.

All the groups from RFC 2409 and the lowest from RFC 3526 look too
weak for modern use.

This might also be a good place to stick ECDH groups. Those would do
really nice things to the MTU:

- CFRG basic ECDH: 32 bytes/key
- CFRG high-security ECDH: 56 bytes/key
- ECDH "stratospheric" level: 66 bytes/key
- DH basic: 256 bytes/key.

And that "high-security ECDH" is considered stronger than even
IKE group 18 (1024 bytes/key!). And "stratospheric" is so big that
finding bigger curves is pretty difficult.


Also, if this one is selected, what will be the symmetric cipher?

>    When the 'Key Algorithm' value is not 1 (Group-ID), the 'Key
>    Material' field is encoded as:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    g-length   |              g-value ...                      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    p-length   |              p-value ...                      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Public Key ...                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>          Key Length describes the length of the Key Material field

What is the difference of AES vs. 3DES vs SHA256 here?


> 7.  Future Work

<this seems to be about crypto improvements>

What I think should be done about crypto:
- Actually specify how algorithm negotiation is supposed to work (I
  can't make heads or tails about that)
- Always use authenticated encryption (algorithms like AES-GCM and
  Chacha20-Poly1305), and also authenticate at least some of the LISP
  headers (those that aren't supposed to change)[1].
- Swap out 3DES for something more serious.
- Support ECDH, including modern Montgomery-curve ECDH (for stronger
  key exchange & smaller keys).
- Hash the map-request/map-reply packets into the encryption key
  computation[2], along with the DH result.



[1] IPSec ESP can be broken if no authentication is used.

[2] TLS didn't use to do this. Caused security issues.


-Ilari