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

Hi David,

>> 1. interface:
>> I agree that MAC interface without a nonce may make implementation
easier.
>> But nonce may not expand the size of MAC because it can be generated by
both
>> sides of a TCP connection. For example, the nonce in UMAC can simply be a
>> counter from 0 to a certain upper bound.

>Agreed, it is true that in some cases the nonce need not be carried
>explicitly along with the MAC value, but instead can be reconstructed by
the
>receiver using other information.  It is also possible to use "Partially
>Implicit Nonces", in the terms of Section 3.2.1 of draft-mcgrew-auth-enc,
>which trades off nonce size against protocol robustness.  Perhaps this is
>worth investigating for TCP-AO, though I still think that nonceless MACs
>should be favored because of their simplicity.
>However, the implicit nonce idea does nothing to address the fact that
>nonce-based algorithms are undesirable whenever it is difficult to ensure
>nonce coordination, i.e. when key management is absent.

If a nonce is used for MAC and requires a key, I think it's reasonable to
let the nonce key updated together with the hash key, similar as some other
security schemes in which encryption keys and integrity protection keys are
generated/renewed synchronously. Though the key management solution for TCP
AO is not proposed yet, adding nonce key generation/distribution together
with hash key won't affect much on overall performance. 

>> Even if nonce requires randomness,
>> a PRFed value of a counter or sequence number (I remember Joe Touch
>> mentioned in Vancouver that key generation of TCP AO should not use any
>> bytes of TCP packets, but I think nonce should be ok.) can provide
>> randomness. Noticing the good performance of MACs like UMAC, maybe we
should
>> keep the door open to MACs with nonce.

>I'm optimistic that worthwhile nonceless MACs can be made.  For example,
>UMAC can easily be turned into a nonceless MAC by changing its definition
>from
>MAC = AES(K, Nonce) (+) Hash(Message)
>To 
>MAC = AES(K, Hash(Message))
>The latter form is actually closer to the initial version of UMAC.
>MACs of this form don't meet requirement R6, though.
Yes, I agree. 

Regards

Sean

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