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

[Mats Näslund <[e-mail]>]

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