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

[Ben Campbell <[e-mail]>]

Hi Benjamin,

One comment inline:

Thanks!

Ben.

> On Mar 7, 2019, at 7:59 AM, Datatracker on behalf of Benjamin Kaduk <[e-mail]> wrote:
> 
> 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.

I m willing to believe the draft needs more detail on what changes in 4916. But if you are asking that it be in the form of patches, that is, “old text” to be removed and “new text” that replaces it, then I don’t think that’s ever been a hard requirement. I think it’s perfectly okay to discuss the update conceptually.

I personally prefer the latter in a lot of cases, but I think both approaches are okay. The patch approach would make sense if we actually rendered patched RFCs, but we don’t.


> 
> 
> ----------------------------------------------------------------------
> 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).
> 
> 
> _______________________________________________
> Sipbrandy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipbrandy