Last Call Review of draft-ietf-sipcore-callinfo-spam-04
review-ietf-sipcore-callinfo-spam-04-secdir-lc-lonvick-2019-09-12-00
| Request | Review of | draft-ietf-sipcore-callinfo-spam |
|---|---|---|
| Requested rev. | no specific revision (document currently at 04) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2019-09-14 | |
| Requested | 2019-08-31 | |
| Authors | Henning Schulzrinne | |
| Draft last updated | 2019-09-12 | |
| Completed reviews |
Opsdir Last Call review of -04 by Nagendra Nainar
Secdir Last Call review of -04 by Chris Lonvick Genart Last Call review of -04 by Joel Halpern |
|
| Assignment | Reviewer | Chris Lonvick |
| State | Completed | |
| Review | review-ietf-sipcore-callinfo-spam-04-secdir-lc-lonvick-2019-09-12 | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/ZBVdAEMibtOghU1VaVW880oY7aU | |
| Reviewed rev. | 04 | |
| Review result | Has Nits | |
| Review completed: | 2019-09-12 |
Review
review-ietf-sipcore-callinfo-spam-04-secdir-lc-lonvick-2019-09-12
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. Overall, the document is well written and, as I disregard yet another call from a number that's suspiciously very like my own number, will probably be very useful. Nit 1 - The next to last paragraph of the Security Considerations section says that "a UAS SHOULD NOT trust the information in the "Call-Info" header field unless the SIP session between the entity inserting the header field and the UAS is protected by TLS [RFC8446]." Perhaps it would be more appropriate to include a qualification that a certificate offered by the entity must be authenticated. This would prevent rogue entities with self-signed certificates from attempting to insert a header field. Or perhaps there are more appropriate measures in SIP to prevent that. (I'm just not altogether that familiar with SIP to say.) Nit 2 - (Very minor typo nits): In the last paragraph in the Security Considerations section "mislead" should be "misled"; "only be added calls" should be "only be added to calls". Best regards, Chris