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

[David Mcgrew <[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