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

[David Mcgrew <[e-mail]>]

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.

As a side note, I would still prefer a CBC variant that doesn't use padding 
as I'd mentioned before, but at any rate the compactness benefit of using 
RTP padding deserves to be mentioned.

David


>Date: Tue, 24 Jun 2003 09:05:00 -0700
>To: Mats Näslund <[e-mail]>, Colin Perkins 
><[e-mail]>
>From: David Mcgrew <[e-mail]>
>Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of 
>comments
>Cc: Allison Mankin <[e-mail]>, [e-mail], "Rolf Blom (EAB)" 
><[e-mail]>, "Elisabetta Carrara (EAB)" 
><[e-mail]>, "Karl Norrman (EAB)" 
><[e-mail]>, [e-mail], [e-mail]
>
>Mats, Colin,
>
>The RTP padding is simple, and I can definitely see the value of using a 
>standard mechanism.  However, it is not clear to me that we actually need 
>a padding method.  AFAICT CBC is the only interesting mode that needs 
>padding.  The other 'NIST standard' encryption modes (OFB, CFB,  ECB, and 
>counter) and the new and interesting OCB mode don't.  Also, there is a CBC 
>encryption variant that avoids padding by switching to CFB mode to encrypt 
>the last block; it's been proven secure, though unfortunately NIST hasn't 
>included it in a standard, at least not explicitly.   If we used this CBC 
>variant - it would be the variant that would make the most sense for voice 
>traffic - then AFAICT we don't need a padding method at all.
>
>I think that a brief discussion of the security details would be 
>useful.  If we allow chosen-plaintext attacks (e.g., the attacker can 
>manipulate the plaintexts directly or indirectly, causing the encryption 
>of data of her choice), then the padding method can affect 
>confidentiality.  Otherwise, I believe that it only affects message 
>authentication.  If message authentication is used (before decryption, as 
>required in SRTP), it defeats Vaudenay's attacks against CBC padding [1], 
>and likely defeats all similar attacks.  The threat is that when message 
>authentication isn't used, there are attacks that can violate 
>confidentiality.   Using the RTP padding method with CBC would provide the 
>same level of security as does the ESP padding: it's perfectly good unless 
>there's no authentication, in which case there are some 
>confidentiality-violating attacks.  At present, the two ciphers defined 
>for SRTP don't require padding, and aren't vulnerable to any 
>confidentiality-violating attacks even when message authentication is not 
>used, as you (Mats) point out.
>
>One of the complicating factors is algorithms that provide message 
>authentication.  Block cipher modes of operation that provide that 
>service  (CBC MAC, XCBC MAC, OCB [2]) use their own padding schemes.   In 
>each of these modes, the padding method that is used is vital to security, 
>or at least is used in the security proof.   XCBC is widely regarded as 
>the 'right' way to do CBC MAC, and is expected to be adopted by the 
>industry, and it is closely tied to its particular padding scheme.  So if 
>we mandate the RTP padding method for SRTP, we need to make clear that it 
>is just for encryption modes (that need padding), and not for 
>authentication modes.  Perhaps it would make more sense to state that 
>encryption modes that need a padding scheme SHOULD use the RTP padding 
>method, unless they need to use another method for security 
>reasons.  OTOH, I personally would rather see the pad-less variant of CBC, 
>though crypto hardware vendors with existing products might choose otherwise.
>
>On a side note, the RTP padding could be used in conjunction with 
>encryption as a length-hiding mechanism.  The sender can hide the length 
>of a packet by adding padding, which the receiver will discard.  The 
>encryption will hide the last padding byte, so that an adversary cannot 
>tell by looking at a ciphertext packet what the length of the payload of 
>the corresponding plaintext packet is.  I don't think that we stated this 
>anywhere in the draft, though it seems like a legal use of RTP and SRTP to me.
>
>David
>
>[1] Security Flaws Induced by CBC Padding - Applications to SSL, IPsec, 
>and WTLS, Serge Vaudenay, online at 
>http://lasecwww.epfl.ch/php_code/publications/search.php?ref=Vau02a
>
>[2] NIST Table of Submitted Modes of Operation, online at 
>http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
>
>At 11:00 AM 6/24/2003 +0200, Mats Näslund wrote:
>
>>Hi,
>>
>>Colin Perkins wrote:
>>>[inline]
>>>--> Allison Mankin <[e-mail]> writes:
>>>
>>>>SRTP is on the agenda of the IESG again this week.
>>>>Some more comments on SRTP may still come in, but I thought
>>>>it would be worth sending on those of Russ Housley, the second Security
>>>>AD.  Steve Bellovin has supported the draft.  Russ has comments that 
>>>>seem straightforward to address.  Wait for more comments before sending 
>>>>in a revision, but so far things are going well.
>>>>
>>>>Allison
>>>>
>>>>
>>>>>>                    Yes    No-Objection  Discuss *  Abstain
>>>>>>
>>>>>>Russ Housley        [   ]     [   ]       [ X ]      [   ]
>>>>>
>>>>>I have six comments.
>>>>>
>>>>>1.  In section 1, spell out the first use of RTCP.
>>>>>
>>>>>2.  I find the structure of section 2 confusing.  I had to read it
>>>>>twice to understand it.  I think that a second level of indenting would
>>>>>be one way to fix it.  I am sure there are others.
>>>>>
>>>>>3.  In section 3.1, in the paragraph after figure 1, please delete:
>>>>>
>>>>>    "It is exact for the pre-defined transforms."
>>>>>
>>>>>This point is made more clearly later in the paragraph.  Then, at the
>>>>>end of the same paragraph, the document says:
>>>>>
>>>>>    "While it could seem more attractive to specify a fixed padding
>>>>>    scheme for all transforms, security and flexibility of transform
>>>>>    specifications REQUIRE that each transform specify a secure
>>>>>    padding method."
>>>>>
>>>>>I disagree.  IPsec and S/MIME both specify padding schemes that are 
>>>>>employed by all of the ciphers.  Please reword.  Do not use "REQUIRE"
>>>>>in the replacement.
>>>If IPsec and S/MIME both define a standard padding mechanism, why cannot
>>>SRTP do the same?  And, perhaps, use the standard RTP padding mechanism?
>>
>>
>>To comply with Russ' comment, I have no objection to deleting
>>"REQUIRE". I would hesitate to go beyond that.
>>
>>We will open up new issues in doing so. Do we use the IPsec pad?
>>The S/MIME pad? Perhaps none of them is general enough? What about
>>new modes? (If I remember correctly, e.g. XCBC had some padding issues.)
>>David referenced a paper showing that some common pad schemes
>>were "weak". (Even if these weaknesses are "theoretical", we have
>>made great effort to make SRTP "maximally" secure, and I would hate
>>to sub-optimize at this point.)
>>
>>It seems to me that the only future proof approach is to let each
>>transform specify its own padding, or at least point to were a
>>padding spec. can be found.
>>
>>/Mats
>>
>>
>>_______________________________________________
>>Audio/Video Transport Working Group
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt