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

[Sean Shuo Shen <[e-mail]>]

>> 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 don't know what FIPS boundary requirements consider, but I would
>expect it would include any required property of the fields. In this
>case, it would be the presumed uniqueness of the fields on a per-segment
>basis, which AFAICT cannot be assumed.
>> 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. 
>If there were no assumption, then I would agree, but the above indicates
>a clear assumption that we cannot clearly ensure.
Ok we discussed:
nonce=PRF(key, index) . 
index =segment length + tcp header without dport&sport. The index can
include all the tcp header including options, but the fields (like port
numbers) that won't change within a connection can be omitted, fields that
are set to be zero in mac culculations can also be omitted.
The problem is:
In a tcp connection, before a seqnum rollover (when rollver happens, both
hash key and PRF key need to be renewed), index must be different when the
authenticated content described in tcpm-tcp-auth-opt-00 is different. Hence
the calculation nonce=PRF(key, index) will give different values.
Proof: 
When the authenticated content changes, there are just two cases: seqnum
changes or not. 
If seqnum changes the index changes.
If seqnum does not change, segment length either changes or not:
	If segment length changes, index changes;
	If segment length does not change, changes can only come from TCP
header
 	including option, in this case, the index also changes.
Thus in all cases, the index must change when authenticated content changes,
hence different nonce value are produces. Done.

If a statement is proved, it is not an assumption. Of course a proof needs
other assumptions, just like we can not play Euclidean Geometry without
assuming Parallel Postulate, we can not play Real Analysis without assuming
Axiom of Choice. Here we should agree that a PRF produces different values
given different input, this is not an assumption which we should deeply
argue before using it. Just like, although we know a hash function is not
injective, we still believe it produces different tags for different
messages because of the small probability of collision, without believing
this the MAC protection for tcp makes no sense.

>>> 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.

>Again, I feel that a good MAC doesn't depend on a nonce for variety.
Nonce is one way, of course not the only way, to contribute variety. 

Sean





_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg