Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: We 're talking about the key wrap function here . Of course there 's a requirement to remove padding , but it 's explicitly clear in the AES Key Wrap RFCs . Seems like this text might be wrong now . 
 Thinking about this a bit , I think I will redo to just make it so decrypt has to remove the pad - I think this is way hold historic text that makes no sense given we use key wrap 
 Section 2.3 The decryption function returns a plaintext value P that is at least M bytes long , or returns an indication that the decryption operation failed because the ciphertext was invalid ( i.e. it was not generated by the encryption of plaintext with the key K ) . It seems that E can pad P. That is fine . Why not have D strip any padding that was put on by E ? These functions have the property that  , E(K , P ) ) = ( P concatenated with optional padding ) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value . The EKTKey MUST NOT be used more that T times . 
 I think the goal was to avoid having a length indicator in the encrypted data as the stuff outside this knows the size ( and thus how much pad to remove ) . Thoughts on what we should say here in the draft ? 
 should we clarify , how the code knows the length of the padding on the decryption side ? 
 I 'm unsure what the question is . I reviewed that section of the current draft and it sounds clear . Perhaps the confusion is over the padding ? The AES Key Wrap logic defines how to insert and remove padding . You can see how that 's implemented here : There is a " with padding " function that inserts required padding per the RFC . So , what 's the question ? 
 .. I think the question is on clarifying when the padding gets and removed . Is it out of enc / dec or inside . We might just need to clarify tht 
 It 's defined in the RFC . I do n't think we should be trying to explain it again here .
Paragraph (version A):
The decryption function returns a plaintext value P that is at least
M bytes long, or returns an indication that the decryption operation
failed because the ciphertext was invalid (i.e. it was not generated
by the encryption of plaintext with the key K).
Paragraph (version A):
These functions have the property that D(K, E(K, P)) = ( P
concatenated with optional padding) for all values of K and P.  Each
cipher also has a limit T on the number of times that it can be used
with any fixed key value.  The EKTKey MUST NOT be used for encryption
more that T times.  Note that if the same EKT packet is retransmitted
3 times, that only counts as 1 encryption.
Paragraph (version B):
The decryption function returns a plaintext value P that is M bytes
long, or returns an indication that the decryption operation failed
because the ciphertext was invalid (i.e. it was not generated by the
encryption of plaintext with the key K).
Paragraph (version B):
These functions have the property that D(K, E(K, P)) = P for all
values of K and P.  Each cipher also has a limit T on the number of
times that it can be used with any fixed key value.  The EKTKey MUST
NOT be used for encryption more that T times.  Note that if the same
EKT packet is retransmitted 3 times, that only counts as 1
encryption.
Paragraph (version A):
An EKTCipher determines how the EKTCiphertext field is written, and
how it is processed when it is read.  This field is opaque to the
other aspects of EKT processing.  EKT ciphers are free to use this
field in any way, but they SHOULD NOT use other EKT or SRTP fields as
an input.  The values of the parameters L, and T MUST be defined by
each EKTCipher.
Paragraph (version B):
An EKTCipher determines how the EKTCiphertext field is written, and
how it is processed when it is read.  This field is opaque to the
other aspects of EKT processing.  EKT ciphers are free to use this
field in any way, but they SHOULD NOT use other EKT or SRTP fields as
an input.  The values of the parameters L, and T MUST be defined by
each EKTCipher.  The cipher MUST provide integrity protection.