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

From: Eric Rescorla <[email-masked]>
Date: Sun, 26 Jul 2009 16:46:51 -0700

$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?

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Mon, 27 Jul 2009 01:24:21 -0700

inline...

>is extraordinarily confusing.

I'm not sure it's "mixing". Isn't one is a subset of the other? The 
KDF interface is an interface. The NIST thing is the actual 
concatenated construct which fulfills the Context.

>- Context (i.e., the conn-data)

it's not just the Data_Block (updated lingo, per auth-opt-05). In 
order to follow SP800-180, the context is a few things concatenated, 
and Data_Block is one of the things.

>what this document happens to do.

I think this document is NOT just the generic interface - that's 
covered in auth-opt-05. This document reminds us of the generic 
interface, and then specifically defines how to do the SHA1 and 
AES-128 KDFs themselves. That's why we made it specific. Maybe I'm 
not understanding you?

>as labels in soem IANA registry, byt people's UI is not our

This is the years of IKE interop work which motivates this. 
Clarifying the UI representations to make it very easy on operators 
is a good thing. Others opinions on this UI guidance?

>but this justification needs to be removed.

Since this is others' text, I'll let those others respond.

>a document which applies to future KDFs, don't say PRF here.

it does say "which name", not "MUST name". Doesn't this cover your point?

>                       variable length data fields.

Done.

>direct import into the document.

send text.

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

discussed with Tim Polk. done. We're back to 0^128 as the key in -02.

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

Honestly, I thought that was the notation you requested upon review 
of -00... I'll ping you offline.

I'm posting -02 now, because there was naming I needed to update to 
stay in sync with auth-opt-05 anyway.

Thx for the review,
Gregory.

>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2009 07:56:53 -0700

At Mon, 27 Jul 2009 01:24:21 -0700,
> concatenated construct which fulfills the Context.

Well, as usual, the interface is abstract and the NIST thing is
a concrete implementation.

> and Data_Block is one of the things.

Yes, that's what it is now and my point is that that's wrong.

> AES-128 KDFs themselves. That's why we made it specific. Maybe I'm 

Apparently not. My point is that you shouldn't be exporting
the SP800-108 stuff into the TCP-AO document, and the way you
have defined the generic interface does that.

> This is the years of IKE interop work which motivates this. 

Well, years of TLS interop suggest the exact contrary.
We're not in the business of mandating UI.

> it does say "which name", not "MUST name". Doesn't this cover your point?

Not really, no. I think you need to separate the abstract requirements
from the concrete instantiations.

-Ekr