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

Ben Campbell <ben@nostrum.com> Thu, 21 February 2019 21:06 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 133A0130E6E; Thu, 21 Feb 2019 13:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 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, URIBL_BLOCKED=0.001] 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 BLp-2w3S1-8X; Thu, 21 Feb 2019 13:06:52 -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 62BD81311D1; Thu, 21 Feb 2019 13:06:52 -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 x1LL6oJ7054453 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Feb 2019 15:06:51 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550783211; bh=3dgKG83M2lr11fPpLkD/umLUPAFIepBJ3kA660CQ9kc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ozQHfrRMyt0RSOEdbkhB1fXWetc5yK78bszTeu5emgNvKSPEVTqjiAkYsqwjmRXkD Ea+qRS7/t+7SswcBcycArcxOP1YT9eiYCT/rWL5paYSWyI3Z68Gh0XNX7sTtFQJkz0 LB4t00LBsOqeu/M5lZPwG02PvZJS5FkUZKt9wa6U=
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>
Message-Id: <020969B6-E6B4-4525-954B-A45F5C77B5FF@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A7F634D6-6619-4D45-A05A-5B161D17FD43"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 21 Feb 2019 15:06:49 -0600
In-Reply-To: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com>
Cc: sipbrandy@ietf.org
To: draft-ietf-sipbrandy-osrtp.all@ietf.org
References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/XF5Nn1UvTqzDqqCAyHKL9ifWr0A>
Subject: Re: [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, 21 Feb 2019 21:06:54 -0000

Hi,

To be clear, progress of this draft is currently blocked on a response to my “Please resolve…” comment below. Please respond as soon as possible,

Thanks!

Ben.

> On Feb 14, 2019, at 2:46 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> Signed PGP part
> 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?
> 
> 
>