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

From: Mats Näslund <[email-masked]>
Date: Fri, 27 Jun 2003 19:09:24 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: David Mcgrew <[email-masked]>
Date: Fri, 27 Jun 2003 09:55:58 -0700

Mats, Colin, and others,

David

>Date: Tue, 24 Jun 2003 09:05:00 -0700
>To: Mats Näslund <[email-masked]>, Colin Perkins 
><[email-masked]>
>From: David Mcgrew <[email-masked]>
>Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of 
>comments
>Cc: Allison Mankin <[email-masked]>, [email-masked], "Rolf Blom (EAB)" 
><[email-masked]>, "Elisabetta Carrara (EAB)" 
><[email-masked]>, "Karl Norrman (EAB)" 
><[email-masked]>, [email-masked], [email-masked]
>
>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 <[email-masked]> 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
>>
>>