[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
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?