[Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07

Ben Campbell <ben@nostrum.com> Thu, 14 February 2019 20:47 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sipbrandy@ietfa.amsl.com
Delivered-To: sipbrandy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435C112EB11; Thu, 14 Feb 2019 12:47:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyxdPJqS4ivJ; Thu, 14 Feb 2019 12:46:57 -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 7DD5612D4F2; Thu, 14 Feb 2019 12:46:54 -0800 (PST)
Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1EKkpOP059021 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Feb 2019 14:46:53 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550177214; bh=tTZ0efs8MhK9FCCMsq+G2GeVucjb9SXtS79F+WcJdkE=; h=From:Subject:Date:Cc:To; b=bLvRACVgBCjCm0YD/jB1/eG24CszBgyVs4FIH+gqIlSbQjLIzKj70iV67rf1CzpXl 6nGIqWikthqVXC8L0n4DpLTeNd908BMp8PIJMw+1apRn8wc/CK6Ff98vh3dXGoN5+e WL/ZcQtMtDqkU76krCBnefl93NhuXSb7VSWmWNbU=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29]
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A41065F9-82BF-4930-B755-78181BA813C0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com>
Date: Thu, 14 Feb 2019 14:46:49 -0600
Cc: sipbrandy@ietf.org
To: draft-ietf-sipbrandy-osrtp.all@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/rEWVKAuFAWUNkoD4BrCcA0jeUvg>
Subject: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07
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: Thu, 14 Feb 2019 20:47:01 -0000

Hi,

This is my AD Evaluation of draft-ietf-sipbrandy-osrtp-07.

Thank you for a readable and easy to understand document.There is one comment I would like to resolve prior to IETF LC. The others can be resolved along with any last call feedback.

*** Please resolve prior to IETF LC ***

§4: The relaxation of authentication requirements for DTLS-SRTP and SDES could use some elaboration on why this acceptable. I _think_ the answer is that, since OSRTP doesn’t guaranty authentication, there’s no need for such a guaranty from the signaling channel. Is that correct?

OTOH, §1 says "third mode for security between "cleartext” and "comprehensive protection" that allows encryption and authentication to be used if supported…”. That suggests that that authentication is sometimes provided. Is there a distinction between the authenticated case and unauthenticated case that should be mentioned somewhere? (For example, is there a need to indicate the distinction to the user?)

*** Other Substantive Comments ***

§2: Please use the new boilerplate from RFC 8174.

§3.1: Please clarify that that the offer can contain more than one key management attribute. This is mentioned in §3.1, but not actually in the section on generating the offer.

*** Editorial Comments ***

§3: "As discussed in [RFC7435], this is
the "comprehensive protection" for media mode.”
s/this/that

§3.4: "meaning that the decision to
create an OSRTP type offer or something else should not be influenced”
That’s referring to the decision to create a _new_ offer, right? Not the original offer?