Message-Id: <4.3.2.7.2.20030624055635.023c01e0@mira-sjcm-1.cisco.com>
Date: Tue, 24 Jun 2003 09:05:00 -0700
To: Mats =?iso-8859-1?Q?N=E4slund?= <mats.naslund@era.ericsson.se>,
 Colin Perkins <csp@csperkins.org>
From: David Mcgrew <mcgrew@cisco.com>
Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set
 of comments
Cc: Allison Mankin <mankin@psg.com>, mbaugher@cisco.com,
 "Rolf Blom (EAB)" <rolf.blom@era.ericsson.se>,
 "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>,
 "Karl Norrman (EAB)" <Karl.Norrman@era.ericsson.se>, oran@cisco.com,
 avt@ietf.org
In-Reply-To: <3EF81335.2050606@era.ericsson.se>
References: <20030623183457.0534f0a4.csp@csperkins.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Mats, Colin,

The RTP padding is simple, and I can definitely see the value of using a=20
standard mechanism.  However, it is not clear to me that we actually need a=
=20
padding method.  AFAICT CBC is the only interesting mode that needs=20
padding.  The other 'NIST standard' encryption modes (OFB, CFB,  ECB, and=20
counter) and the new and interesting OCB mode don't.  Also, there is a CBC=
=20
encryption variant that avoids padding by switching to CFB mode to encrypt=
=20
the last block; it's been proven secure, though unfortunately NIST hasn't=20
included it in a standard, at least not explicitly.   If we used this CBC=20
variant - it would be the variant that would make the most sense for voice=
=20
traffic - then AFAICT we don't need a padding method at all.

I think that a brief discussion of the security details would be=20
useful.  If we allow chosen-plaintext attacks (e.g., the attacker can=20
manipulate the plaintexts directly or indirectly, causing the encryption of=
=20
data of her choice), then the padding method can affect=20
confidentiality.  Otherwise, I believe that it only affects message=20
authentication.  If message authentication is used (before decryption, as=20
required in SRTP), it defeats Vaudenay's attacks against CBC padding [1],=20
and likely defeats all similar attacks.  The threat is that when message=20
authentication isn't used, there are attacks that can violate=20
confidentiality.   Using the RTP padding method with CBC would provide the=
=20
same level of security as does the ESP padding: it's perfectly good unless=
=20
there's no authentication, in which case there are some=20
confidentiality-violating attacks.  At present, the two ciphers defined for=
=20
SRTP don't require padding, and aren't vulnerable to any=20
confidentiality-violating attacks even when message authentication is not=20
used, as you (Mats) point out.

One of the complicating factors is algorithms that provide message=20
authentication.  Block cipher modes of operation that provide that=20
service  (CBC MAC, XCBC MAC, OCB [2]) use their own padding schemes.   In=20
each of these modes, the padding method that is used is vital to security,=
=20
or at least is used in the security proof.   XCBC is widely regarded as the=
=20
'right' way to do CBC MAC, and is expected to be adopted by the industry,=20
and it is closely tied to its particular padding scheme.  So if we mandate=
=20
the RTP padding method for SRTP, we need to make clear that it is just for=
=20
encryption modes (that need padding), and not for authentication=20
modes.  Perhaps it would make more sense to state that encryption modes=20
that need a padding scheme SHOULD use the RTP padding method, unless they=20
need to use another method for security reasons.  OTOH, I personally would=
=20
rather see the pad-less variant of CBC, though crypto hardware vendors with=
=20
existing products might choose otherwise.

On a side note, the RTP padding could be used in conjunction with=20
encryption as a length-hiding mechanism.  The sender can hide the length of=
=20
a packet by adding padding, which the receiver will discard.  The=20
encryption will hide the last padding byte, so that an adversary cannot=20
tell by looking at a ciphertext packet what the length of the payload of=20
the corresponding plaintext packet is.  I don't think that we stated this=20
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=
=20
WTLS, Serge Vaudenay, online at=20
http://lasecwww.epfl.ch/php_code/publications/search.php?ref=3DVau02a

[2] NIST Table of Submitted Modes of Operation, online at=20
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/

At 11:00 AM 6/24/2003 +0200, Mats N=E4slund wrote:

>Hi,
>
>Colin Perkins wrote:
>>[inline]
>>--> Allison Mankin <mankin@psg.com> 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=20
>>>seem straightforward to address.  Wait for more comments before sending=
=20
>>>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=20
>>>>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
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt