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

Hi Joe, 
>> I presume you're looking for a nonce that would be unique per unique
>> segment. It would be preferable to insert either that nonce or an index
>> thereto in the MAC itself, than to make assumptions of the uniqueness of
>> any fields of the TCP segment or a hash that would be derived from them.

Yes, I am discussing the possibility that unique nonce are generated by both
sides without carrying extra info in MAC. Inserting an index (like a
counter) or even the nonce itself certainly can make life easier, if we
don't care the extra bytes together with the MAC.

>FWIW, it might be possible for TCP to retransmit a segment with the same
>offset and size but with different options. In particular, if the user
>sets an option between a segment's initial transmission and subsequent
>retransmission, this could occur. I'm checking to see if this could also
>occur with TCP flags (e.g., FIN if a user closes a connection while data
>is outstanding).

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

Regards

Sean

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