[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - anotherset of comments

Hi all,

David Mcgrew wrote:
Mats, Colin, and others,

I belatedly realized that there is another advantage to using the RTP padding over other schemes: compactness. If someone implements CBC without using the RTP padding, then the plaintext needs to be turned into a prefix-free code so that the receiver can unambiguously remove any padding that may be present. Because of this, AES CBC ciphertext will expand by an extra 16-octet block on messages for which no padding is needed, if the conventional method is used (see Appendix A of http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf for more detail). OTOH, if the RTP padding is used, then the padding bit indicates the presence of padding, and there is never need to further expand the ciphertext. Also, the NIST document cited above makes it clear that any suitable padding method is considered acceptable. So this makes me think that we should recommend RTP padding for use with modes that require padding.
Will someone concerned with compactness use a mode that requires
padding in the first place? Won't they rely on the pre-defined modes?

I honestly don't see how we can recommend a padding that we *know*
is "flawed", in particular when the flaw occurs in the absence
of integrity---something we had to fight allow at all!

I am fine with keeping the RTP padding as a sort of "default",
be honest about its pros and cons, but I would not go as far as
to *recommend* it.

As a side note, I would still prefer a CBC variant that doesn't use padding 
Agreed, but that is for a future extension of SRTP.
as I'd mentioned before, but at any rate the compactness benefit of using RTP padding deserves to be mentioned.
Absolutely, but so does the security problems.

/M


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt