Last Call Review of draft-ietf-sipbrandy-osrtp-09

Request Review of draft-ietf-sipbrandy-osrtp
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-05-16
Requested 2019-05-02
Authors Alan Johnston, Bernard Aboba, Andrew Hutton, Roland Jesske, Thomas Stach
Draft last updated 2019-05-27
Completed reviews Tsvart Last Call review of -09 by Allison Mankin (diff)
Secdir Last Call review of -09 by Sean Turner (diff)
Genart Last Call review of -09 by Elwyn Davies (diff)
Assignment Reviewer Sean Turner
State Completed
Review review-ietf-sipbrandy-osrtp-09-secdir-lc-turner-2019-05-27
Posted at
Reviewed rev. 09 (document currently at 10)
Review result Has Issues
Review completed: 2019-05-27


I had a read of the draft as well as the GENART and TSVART reviews (to avoid duplicating comments).

Summary: Ready with (minor) issues


0) I assume that the mismatch the TSVART refers to in the security considerations has to do with 1) changing 4568 to require encryption but not fail if authentication is not available, 2) pointing out that 4568's requirement is routinely ignore for end-to-end encryption because using TLS with intermediaries won't protect the SDP key, and 3) and reference errors (see the next issue).  On 1, that's kind the point of OSRTP - take the encryption you can get.  On 2, because it's the security considerations this document is just saying don't expect to get end-to-end.  Assuming, I've interpreted this I think this draft is okay. 

1) I think these are just reference errors, but it would be good to double check these (and I hadn't seen a response yet - might have missed it):

S4: Not sure about these references too RFC7435.  Maybe they should be to RFC 4568 instead?

s/The security considerations of [RFC7435] apply to OSRTP,
/The security considerations of [RFC4568] apply to OSRTP,

s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568]

s/understood that the [RFC7435]/understood that the [RFC4568]


0) The fact that it's Informational struck me as odd.

1) The fact there are no updates listed also strikes me as odd.


0) s2: Nits reports an error with the para.  I think it's:

s/RFC 2119 [RFC2119] RFC 8174 [RFC8174]
/RFC 2119 [RFC2119] [RFC8174]

1) s1, 2nd para: s/[RFC5939] ./[RFC5939].