RE: [saag] [Cfrg] Re: TCP-AO MAC algorithms

>>> For these reasons, and because of the potential to constrain the
>>> evolution of TCP, I would urge the MAC computation to treat the
>>> non-zeroed TCP header and pseudoheader fields as opaque.
> 
>> I also believe some other bits in TCP header might be different even if
the
>> TCP is retransmitting the same segment. But all of these changes can
easily
>> be included in the PRF input when the nonce is calculated (it won't be
heavy
>> work compared with the calculation of MAC) to make sure different nonces
are
>> used when the authenticated content changes. 

>Steve B. suggests not corrupting the FIPS boundary by using TCP header
>info. 
The FIPS boundary does matter only if the use of TCP header info is
cryptographic significant. For example, using seq num as a random seed
definitely is not a good idea. However, in a calculation like:
nonce=PRF(key, seqnum and other header info)
The seqnum et.al. are to provide difference of input to get different
output. It works like a index and totally allowed to be predictable (it can
even be a counter just like the nonce processing part of umac: PRF(key,
counter)). 
When we are not using a seqnum as a random source we don't have to worry
it's not random enough.

>I am suggesting not limiting TCP design by making assumptions
>about the TCP header's uniqueness in each transmitted segment.
In a tcp transmission, as long as the MAC protected content are different,
there will be enough difference in tcp header (seq num et.al., actually, the
possible difference in option field or other bits are also good to
contribute difference here). This difference will be good enough for both
sides to generate different nonce for MAC calculation. It's not to make any
assumption here. 

>We thus have two reasons not to do this; I hope that's sufficient reason
>to either have a shorter MAC coupled with an explicit nonce, a longer
>overall option field, or to seek algorithms that avoid the need for nonces.
The two ways mentioned above both have the advantage of simple
implementation. But implicit nonce generated by both sides is also
achievable, and the benefit of it will be: less bytes in MAC transmission,
more randomness (from PRF key, not from seqnum), more variety.

Sean


_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg