[Sipbrandy] Benjamin Kaduk's Discuss on draft-ietf-sipbrandy-rtpsec-07: (with DISCUSS and COMMENT)

[Datatracker on behalf of Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipbrandy-rtpsec-07: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think we need to have a bit more clarity on exactly how/what parts of
4916 are updated (per Section 4.3).  Thta is, we have some text that's
indented as if it's supposed to be logically inserted into a "revised
4916", but no indication of where or whether anything else is removed.
Furthermore, that text includes section references to portions of 4916
that are incorrect; normally an Update: would point to such text and say
"this is removed" or "this is replaced by <x>", and the current
formulation looks like it's constructing a virtual document that is
internally inconsistent.


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

Thanks to the authors for putting together this comprehensive treatment
of what we need for full-stack media protection via SIP/SDP/etc.; it's a
pleasure to read.

That said, I'm a little confused at whether I signal in-band that I'm using the
Section 3.1 Comprehensive Protection vs. Section 3.2 Opportunistic Security.
Does the "msec" type get used in both cases?

Section 3.1

               Broadly, it is the responsibility of SIP to provide
   integrity protection for the media keying attributes conveyed by SDP,
   and those attributes will in turn identify the keys used by endpoints
   in the RTP media session(s) that SDP negotiates.  Note that this
   framework does not apply to keys that also require confidentiality
   protection in the signaling layer, such as the SDP "k=" line, which
   MUST NOT be used in conjunction with this profile.  In that way, once

Maybe s/keys/key exchange mechanisms/?  I misread this the first time around.

   SIP and SDP have exchanged the necessary information to initiate a
   session, media endpoints will have a strong assurance that the keys
   they exchange have not been tampered with by third parties, and that
   end-to-end confidentiality is available.

I think I'm missing a step in the reasoning here.  Just because the keys
themselves don't go in cleartext we're confident there's no tampering?

   To establishing the identity of the endpoints of a SIP session, this
   specification uses STIR [RFC8224].  The STIR Identity header has been

nit: 8224 doesn't really call itself "STIR" anywhere.

   STIR generates a signature over certain features of SIP requests,
   including header field values that contain an identity for the
   originator of the request, such as the From header field or P-
   Asserted-Identity field, and also over the media keys in SDP if they
   are present.  As currently defined, STIR only provides a signature
   over the "a=fingerprint" attribute, which is a key fingerprint
   utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers
   comprehensive protection for SIP sessions, in concert with SDP and
   SRTP, when DTLS-SRTP is the media security service.  [...]

I think that "over the media keys" is potentially confusing.  What seems
to be signed here is the [fingerprint of the] asymmetric keys used as
intput to a key-exchange mechanism that is used to generate the
(symmetric) media keys.

Section 3.2

   Opportunistic encryption approaches typically have no integrity
   protection for the keying material in SDP.  Sending SIP over TLS hop-
   by-hop between user agents and any intermediaries will reduce the
   prospect that active attackers can alter keys for session requests on
   the wire.  However, opportunistic confidentiality for media will
   prevent passive attacks of the form most common in the threat of
   pervasive monitoring.

I'm a little confused by this statement.  How is the capability of
active attackers reduced?

Section 4

"SIP UAS" (or even "UAS") are not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt, so UAS should
be expanded on first use (or the terminology section expanded to note
documents with which the reader is assumed to be familiar).

   The SIPBRANDY deployment profile of STIR for media confidentiality
   thus shifts these responsibilities to the endpoints rather than the
   intermediaries.  [...]

Which responsibilities?

   When generating either an offer or an answer [RFC3264], compliant
   implementations MUST include an "a=fingerprint" attribute containing
   the fingerprint of an appropriate key (see Section 4.1).

nit: since this stuff crosses many different layers, is it friendly to
the reader to be explicit about "SDP offer or answer"?

Section 4.2

   Even for anonymous sessions, providing media confidentiality and
   partial SDP integrity is still desirable.  This specification
   RECOMMENDS using one-time self-signed certificates for anonymous
   communications, with a subjectAltName of
   "sip:[e-mail]".  [...]

Should we recommend that the commonName be absent?

                This signature only provides protection against non-
   Identity aware entities that might modify SDP without altering the
   PASSporT conveyed in the Identity header.

It also protects against passive observers, right?

Section 4.4

   For this profile, however, a compliant verification service that
   receives a dialog-forming SIP request containing an Identity header
   with a PASSporT type of "msec", after validating the request per the
   steps described in Section 6.2 of [RFC8224], MUST reject the request
   if there is any failure in that validation process with the
   appropriate status code per Section 6.2.2.  [...]

nit: that's 6.2.2 of RFC8224 still, but the tooling (and arguably some
readers as well) will pick it up as section 6.2.2 of the current
document (which does not exist).

                    As any verification service that receives an
   Identity header in a SIP request with an unrecognized PASSporT type
   will simply ignore that Identity header, an authentication service
   will know whether or not the terminating side supports "msec" based
   on whether or not its user agent receives a signed request in the
   backwards direction per Section 4.3.  [...]

Is this actually the case?  My understanding was that an active MITM
could drop the authentication bits and obscure whether the actual
peer supports "msec".

Section 6

                  In many such implementations, only hop-by-hop media
   confidentiality is possible.  Work is ongoing to specify a means to
   encrypt both the hop-by-hop media between a user agent and a
   centralized server as well as the end-to-end media between user
   agents, but is not sufficiently mature at this time to make a
   recommendation for a best practice here.  [...]

Tantalizing, but you're not going to give an informative reference?

Section 7

   Note that in the comprehensive protection case, the use of Connected
   Identity [RFC4916] with ICE entails that the answer containing the
   key fingerprints, and thus the STIR signature, will come in an UPDATE
   sent in the backwards direction a provisional response and
   acknowledgment (PRACK), rather than in any earlier SDP body.  [...]

nit: there seems to be a missing word here.

Section 12.2

It looks like trickle ICE should be normative (as we RECOMMEND its
implementation).