Re: [tcpm] Comments on draft-ietf-tcpm-tcp-ao-crypto-01

[Gregory Lebovitz <[e-mail]>]

Hey Brian,
Thanks a ton for the very thoughtful review. Comments inline..

On Thu, Jan 14, 2010 at 9:49 AM, Brian Weis <[e-mail]> wrote:

> Hi Gregory,
>
> In prototyping TCP-AO, I noticed the following relatively minor issues with
> this draft, but not fixing them has interoperability consequences.
>
> 1. In order to have an interoperable KDF, the number of bytes for "i" (the
> counter) and "Output_length" need to be defined. If one side hashes a 4 byte
> value and the other a 1 byte value, the resulting KDF output will differ. I
> suggest amending the text something similar to as follows:
>
>  * In the description of "i", after the sentence "A counter, a binary
> string that is an input to each
> iteration of the PRF in counter mode." add the following sentence: "The
> counter is represented in a single octet."
>

Yup. Great catch. In NIST SP-800-108, this is called "r" and it is a fixed
value that must be indicated for a KDF in counter mode, and is defined as
"The length of the binary representation of the counter i. "

So I'll add your suggested text, with this minor modification:
 s/counter is/counter "i" is/

done.


>  * In the description of "Output_length" add a sentence after "The length
> in bits of the key that the KDF will produce." add "The Output_length is
> represented within two octets."
>

done.
I'm hoping that 2 octets, or 65535 bits, as a max length is enough for a key
length 10 or 20 years from now. If not, someone say so and we can change it
during IETF last call.


> I believe 255 iterations ought to be enough for an KDF, which is why I
> suggest one octect for "i". Also, the overall length of key being produce
> shouldn't be larger than 65535 bytes.


It's length in *bits* not *bytes*, big difference. Still think 65535 bits is
big enough to outlast the protocol's useful life on the wire?


> If you're concerned with arbitrary limiting the size of the values for all
> KDFs that might be defined in the future, you could instead make these
> statements part of the definition of KDF_HMAC_SHA1 and KDF_AES_128_CMAC. I
> doesn't matter to me, I just have observed that if everyone doesn't do it
> the same way there are issues!
>
> 2. This example in Section 3.1.1 doesn't match SP 800-108:
>
>       Traffic_Key = KDF_alg(Master_Key, 0 || Label || Context ||
> Output_length) ||
>                     KDF_alg(Master_Key, 1 || Label || Context ||
> Output_length)
>
> All of the KDFs in SP 800-108 start the counter at "1", not "0".


I just read through SP 800-108 again, and you are 100% right, all the KDF
examples have "for i = 1 to n". Excellent catch. Not sure where I got "0"
from.


> It would be very helpful to start the counter here at "1" as well. As one
> data point, I could not use my general-purpose KDF that conforms with SP
> 800-108 for TCP-AO, which was annoying. I also think this singly
> inconsistency could easily lead to errors in implementations that don't
> noticed the difference.
>

Agreed. In 3.1.1 I changed the example you showed above so that s/0/1/ and
s/1/2/. I also changed and text in the paragraph ahead of it to match. Last,
I added this text to the definition of "i":
   "i" always starts = 1

Thanks for catching these very small, but enormously imactful little bugs.
Much appreciated. Look for -02 to publish shortly after this email is sent.

Gregory.


> Thanks,
> Brian
>
> --
> Brian Weis
> Router/Switch Security Group, ARTG, Cisco Systems
> Telephone: [phone]
> Email: [e-mail]
>
>
>
>


-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks