[Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-rtpsec-06

Ben Campbell <ben@nostrum.com> Sat, 29 December 2018 00:04 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sipbrandy@ietfa.amsl.com
Delivered-To: sipbrandy@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AB0AC12008A; Fri, 28 Dec 2018 16:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NnIUpSlLf0rq; Fri, 28 Dec 2018 16:04:41 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A586130E19; Fri, 28 Dec 2018 16:04:37 -0800 (PST)
Received: from [] (cpe-70-122-203-106.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wBT04ZJG095100 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Dec 2018 18:04:36 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1546041876; bh=8g4RxsQwD58tZ2N/ewQE84HXgkOEFrgTJY+7hUQGTr0=; h=From:Subject:Date:Cc:To; b=edzsOm21c+6w21zTuhfZ8YvLh3Ga2l/Ji83S3GiEM4BH394j3nqOFsUl41qJQgfzS PvPqfrSzXglqC0dAAETb4HJesKcm1BcLXLpP4NYkUD2802uZrzOiixESUgXVnjnSmE /lyq5ahoCr90GfzEbBsojdHqfWOI+htQ2Dg3vxeE=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [] claimed to be []
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_480412C2-30FA-4E89-AED8-F0FCE1FE1C9E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <E86F65B7-7901-4EFB-B70C-541349E73DB2@nostrum.com>
Date: Fri, 28 Dec 2018 18:04:34 -0600
Cc: sipbrandy@ietf.org
To: draft-ietf-sipbrandy-rtpsec.all@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/UAxj5O8Gwag_JannjdRTH3UcnNY>
Subject: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-rtpsec-06
X-BeenThere: sipbrandy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIPBRANDY working group discussion list <sipbrandy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipbrandy/>
List-Post: <mailto:sipbrandy@ietf.org>
List-Help: <mailto:sipbrandy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Dec 2018 00:04:45 -0000


This is my AD Evaluation of draft-ietf-sipbrandy-rtpsec-06. I have a few substantive comments, and some editorial and nit comments. I’d like to resolve the substantive comments prior to IETF Last Call.




*** Substantive Comments ***

- general: The section explains the requirement that the AS and VS to be colocated with the caller and recipient UAs as because putting them in an intermediary could allow that intermediary to act as a MitM. Isn’t this more a question of trust than physical location? Users already need to trust the AS and VS for STIR to work at all. In particular, I don’t think it’s safe to imply that a local AS _can’t_ act as a MiTM unless the code is inspected (and perhaps signed) by a trusted entity.

For the record, I do not necessarily object to the colocation requirement; I’m just not entirely buying the explanation for it.

- 2nd paragraph: "While intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions,”: That seems to contradict the statement in the following paragraph that the user agent implementations MUST implement both the AS and VS.

- General: This section talks about self-signed certs and TOFU. Would you characterize those as comprehensive security? I suspect not, since they offer more exposure to active attacks. But I’m not sure they qualify as “opportunistic”, since they don’t (necessarily) allow a fallback to cleartext. In any case, some text discussing this question might be helpful. (This also includes §4.2)

- third paragraph: "This profile of STIR therefore relaxes the authority requirements of [RFC8224]”
Does that require this draft to formally update 8224?

§4.3: Does this draft need to formally update 4916? It’s not clear to me if this draft intends to update these, or is stating that these are some updates we should do in the future. The last paragraph suggests the latter, but the rest of the section seems to be more the former.

§4.4, last paragraph: Is there an expectation that the UA will alert the user if it allows the dialog to continue without media security?

*** Editorial Comments ***

- Abstract: Is it really still true that this draft provides solutions for opportunistic security? The draft mentions OS, but it seems to delegate the solutions to the osrtp draft.

§3.1, last paragraph:

- s/“To establishing”/“To establish”
- " STIR generates a signature over certain features of SIP requests,”: Is “features” the right word? Maybe “parameters”?
- "As currently defined, STIR only provides a signature over the "a=fingerprint" attribute”: That’s not really true. I think you mean to say that this is the only key exchange mechanism that STIR will sign as currently specced?

- first paragraph (and elsewhere in the doc): Please update the reference for the osrtp draft to "draft-ietf-sipbrandy-osrtp”
- last paragraph: “ opportunistic confidentiality for media will prevent passive attacks”: Should “will” be “may”, given that osrtp allows fallback to no confidentiality protection?

- Please expand UAS on first mention.
- is there something that could be cited for STIR’s “core threat model”?
- 2nd to last paragraph: "Implementations MUST provide key fingerprints in SDP ...” seems redundant to the last paragraph.

- first paragraph (and elsewhere): I found the use of the term “greenfield” to describe SIP URIs a bit confusing. I assume that is meant to contrast with “legacy” phone numbers, but there is no explanation to that effect. Is it insufficient to just say “SIP URIs” and “telephone numbers” without the additional qualification?

-2nd paragraph: This will hopefully eventually be over taken by events. Would it make sense to add an “At the time of this writing...” disclaimer?

§6: s/mux/multiplex, s/muxed/multiplexed

§7: “implementations of this specification must support ICE”: Should the “must” be “MUST”?