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

From: Allison Mankin <[email-masked]>
Date: Mon, 23 Jun 2003 14:13:12 -0700

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.
> 
> 4.  In section 3.2.1, the document says: "the master key(s), which MUST be 
> random and kept secret."  This is quite a high bar.  I suggest that 
> pseudo-random is sufficient.  Please see the RFC 2828 definitions of 
> "random" and "pseudo-random."  The document says that it is following these 
> terms.  Also, see RFC 1750.  Similarly, the requirement on the master salt 
> should also be reduced to pseudo-random.
> 
> 5.  The last paragraph is section 3.2.3 says:
> 
>    "If no valid context can be found for a packet corresponding to a
>     certain context identifier, that packet MUST be discarded from
>     further SRTP processing."
> 
> Elsewhere, "discarded from further processing" is used.  This seems better 
> to me.  It is discarded, which seems different that no further SRTP 
> processing.  Also, SRTCP should be covered by this statement.
> 
> 6.  In section 4.1.1, I am confused by the term "fixed key" in the following:
> 
>     "For a fixed Counter Mode key, each IV value used as an input MUST be
>     distinct, in order to avoid the security exposure of a two-time pad
>     situation (Section 9.1).  To satisfy this constraint, an
>     implementation MUST ensure that the values of the SRTP packet index
>     of ROC || SEQ, and the SSRC used in the construction of the IV are
>     distinct for any fixed key.  The failure to ensure this uniqueness
>     could  be catastrophic for Secure RTP.  This is in contrast to the
>     situation for RTP itself, which may be able to tolerate such
>     failures.  It is RECOMMENDED that, if a dedicated security module is
>     present, the RTP sequence numbers and SSRC either be generated or
>     checked by that module (i.e., sequence-number and SSRC processing in
>     an SRTP system needs to be protected as well as the key). "
> 
> I think that "fixed" means "any particular key" but I am not sure.
> 
> 
> 
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Jun 2003 18:34:57 -0400

[inline]

--> Allison Mankin <[email-masked]> writes:
> > 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.
> > 
> > This point is made more clearly later in the paragraph.  Then, at the
> > end of the same paragraph, the document says:
> > 
> > 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?

-- 
Colin Perkins
[email-masked]

---

From: Mats Näslund <[email-masked]>
Date: Tue, 24 Jun 2003 11:00:37 +0200

Hi,

> 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

---

From: David Mcgrew <[email-masked]>
Date: Tue, 24 Jun 2003 09:05:00 -0700

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:

>>>seem straightforward to address.  Wait for more comments before sending 
>>>in a revision, but so far things are going well.
>>>
>>>Allison
>>>
>>>