[tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01

[Eric Rescorla <[e-mail]>]

$Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01-rev.txt,v 1.1 2009/07/26 22:40:47 ekr Exp $

TECHNICAL
S 3.1.
This mixing of the KDF interface and the NIST 800-108 interface
is extraordinarily confusing.


To recap:
The input to the KDF requires:

- Master Key
- Context (i.e., the conn-data)
- Output length

Now, as it happens, you're constructing your KDFs a la SP800-108,
so you then use the relevant PRF with an input block constructed
as:

           ( i || Label || Context || Output_Length)

But that is not a meaningful part of the interface to the KDF
as far as AO is concerned. If you were (for instance) to define
a new TLS PRF based KDF, you would not use i internally because
the TLS PRF generates an arbitrary length string. Again, it's
important to distinguish between the TCP-AO requirements and
what this document happens to do. 


S 3.1.3.
Wait, I don't remember agreeing to this. I'm happy to use these
as labels in soem IANA registry, byt people's UI is not our
business.


EDITORIAL
S 2.2.

   The security issues driving the migration from SHA-1 to SHA-256 for
   digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately
   render SHA-1 weak for this application of SHA-1 in HMAC mode.  The
   security strength of SHA-1 HMACs should be sufficient for the
   foreseeable future, especially given that the tags are truncated to
   96 bits.  However, while it's clear that the attacks aren't practical
   on SHA-1, these types of analysis are mounting and could potentially
   pose a concern for HMAC forgery if they were significantly improved,
   over time.  In anticipation of SHA-1's growing less dependable over
   time, but given its wide deployment and current strength, it is a
   "MUST" for TCP-AO today.  AES-128 CMAC is considered to be far
   stronger algorithm, but may not yet have very wide implementation.
   It is also a "MUST" to implement, in order to drive vendors toward
   its use.

This is simply not true. It's not at all clear that AES-128-CMAC is
stronger than HMAC-SHA1, and I don't believe you could get anything
like a consensus of cryptographers to say that it was. The
MUST-MUST was taken on the basis of a WG hum. I'm fine with that,
but this justification needs to be removed.




S 2.3.
       (1)  Key Derivation Functions (KDFs) which name a pseudorandom
            function (PRF) and use a Master_Key and some connection-
            specific Input with that PRF to produce Conn_Keys, the keys
            suitable for authenticating and integrity checking
            individual TCP segments.

This is confusing. KDFs may or may not be constructed with PRFs.
However, THESE KDFs are so constructed. If you're giong to have
a document which applies to future KDFs, don't say PRF here.



S 3.1.
                      An octet of all zeros.  An optional data field
                      used to indicate a separation of different
                      variable length data fields.

This is just dangling.


   When invoked, a KDF runs a certain PRF, using the Master_Key as the
   seed, and Input as the message input and produces a result of
   Output_Length bits.  This result may then be used as a cryptographic
   key for any algorithm which takes an Output_Length length key as its
   seed.  A KDF MAY specify a maximum Output_Length parameter.

Again, misplaced concreteness.


Woah, I think my numbered list cut and paste here seems needs some
major re-editing. It was intended for the mailing list, not for
direct import into the document. 


S 3.1.1.

It's a mistake to talk about "Output Length" as a property of the KDF.
In principle, this KDF could generate any output length of your
choice by using i=0, i=1, etc.. Why are you nailing it down?


S 3.1.2.
I strongly object to the use of this magic key string here. 



S 3.2.
This whole Conn_Key(KDF) thing is confusing. What's it doing?