[Sipbrandy] Adam Roach's Yes on draft-ietf-sipbrandy-rtpsec-07: (with COMMENT)

[Datatracker on behalf of Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-sipbrandy-rtpsec-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to the work that the authors and other contributors have put into
describing these practices. I have a handful of relatively minor comments.

---------------------------------------------------------------------------

During the development of this document, was there any discussion of the
issues raised by draft-ietf-mmusic-sdp-uks?  Minimally, it seems that the
problem described there should be summarized and an informative link to that
document provided, probably somewhere in §3.1.

---------------------------------------------------------------------------

§4:

>  needs to be repeated at the endpoint obtain the end-to-end assurance.

Nit: "...at the endpoint to obtain end-to-end assurance."
                         ^^       ^

>  Intermediaries supporting this specification MUST NOT block or
>  otherwise redirects calls

Nit: "...redirect..."


---------------------------------------------------------------------------

§4:

>  STIR
>  authentication services MUST signal their compliance with this
>  specification by adding the "msec" header element defined in this
>  specification to the PASSporT header.

The use of the term "header element" threw me off for a few moments. It almost
sounds like the document is proposing a new  PASSporT parameter, rather than
defining a new value for the "ppt" parameter. I think this means to say
something like "...by adding a PASSporT with a type of "msec"..."

This phrasing also appears in section 8.

---------------------------------------------------------------------------

§4.1:

>  service on behalf of an entire domain, just as in SIP an proxy server

Nit: "...a proxy server..."

---------------------------------------------------------------------------

§4.3:

>  Identity header for the recipient of an INVITE.  The procedures in

Nit: "...Identity header field..."

---------------------------------------------------------------------------

§4.3:

>  STIR [RFC8224] provides integrity protection for the SDP bodies of
>  SIP requests...

I thought that generalized body protection was one of the things we removed
between 4474 and 8224. On a quick check, it looks like the only body-level
integrity protection 8224 affords is "a=fingerprint" attributes. I propose:

  "...provides integrity protection for the fingerprint attributes in SIP
  request bodies..."

(and similar changes for the other two mentions of "body" in this paragraph)

---------------------------------------------------------------------------

§4.4:

>  Identity header in a SIP request with an unrecognized PASSporT type

Nit: "...Identity header field..."

---------------------------------------------------------------------------

§6:

>  Another class of entities that might relay SIP media are back-to-back
>  user agents (B2BUAs).  If a B2BUA follows the guidance in [RFC7879],
>  it may be possible for those devices to act as media relays while
>  still permitting end-to-end confidentiality between user agents.

I'm a little surprised to see no mention of the interaction between B2BUAs and
the "trust on first use" technique described in Section 4.1. In particular, an
endpoint that is persistently behind a B2BUA, where that B2BUA implements the
Identity handling described in this document (acting as an endpoint) could
persistently receive the same identity for a remote user -- where that remote
identity is actually one created by the B2BUA.

I don't think mitigation is something this document needs to figure out; but I
think the situation should be called out explicitly.

---------------------------------------------------------------------------

§7:

>  In order to best enable end-to-end connectivity between user agents,
>  and to avoid media relays as much as possible, implementations of
>  this specification must support ICE [RFC8445].

It seems this is intended to be a normative "MUST."

---------------------------------------------------------------------------

§7:

>  ...will come in an UPDATE
>  sent in the backwards direction a provisional response and
>  acknowledgment (PRACK)...

I can't parse this clause. I think it means to say:

   ...will come in an UPDATE
   sent in the backwards direction, a provisional response, and
   a provisional acknowledgment (PRACK)...