Date: Tue, 24 Jun 2003 09:05:00 -0700
To: Mats Näslund <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
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 <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 seem straightforward to address. Wait for more comments before sending in a revision, but so far things are going well.
Allison
I have six comments.Yes No-Objection Discuss * Abstain Russ Housley [ ] [ ] [ X ] [ ]
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 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