[secdir] Secdir last call review of draft-ietf-sipbrandy-osrtp-09

Sean Turner via Datatracker <noreply@ietf.org> Tue, 28 May 2019 02:15 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC64A120096; Mon, 27 May 2019 19:15:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Sean Turner via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Sean Turner <sean@sn3rd.com>
Message-ID: <155900970362.650.8194184838834826261@ietfa.amsl.com>
Date: Mon, 27 May 2019 19:15:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/e6N-A2-BiCDwAIWbhp2tDU7JKHg>
Subject: [secdir] Secdir last call review of draft-ietf-sipbrandy-osrtp-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2019 02:15:04 -0000

Reviewer: Sean Turner
Review result: Has Issues

I had a read of the draft as well as the GENART and TSVART reviews (to avoid
duplicating comments).

Summary: Ready with (minor) issues

Issues:

0) I assume that the mismatch the TSVART refers to in the security
considerations has to do with 1) changing 4568 to require encryption but not
fail if authentication is not available, 2) pointing out that 4568's
requirement is routinely ignore for end-to-end encryption because using TLS
with intermediaries won't protect the SDP key, and 3) and reference errors (see
the next issue).  On 1, that's kind the point of OSRTP - take the encryption
you can get.  On 2, because it's the security considerations this document is
just saying don't expect to get end-to-end.  Assuming, I've interpreted this I
think this draft is okay.

1) I think these are just reference errors, but it would be good to double
check these (and I hadn't seen a response yet - might have missed it):

S4: Not sure about these references too RFC7435.  Maybe they should be to RFC
4568 instead?

s/The security considerations of [RFC7435] apply to OSRTP,
/The security considerations of [RFC4568] apply to OSRTP,

s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568]

s/understood that the [RFC7435]/understood that the [RFC4568]

Bikesheds:

0) The fact that it's Informational struck me as odd.

1) The fact there are no updates listed also strikes me as odd.

Nits:

0) s2: Nits reports an error with the para.  I think it's:

s/RFC 2119 [RFC2119] RFC 8174 [RFC8174]
/RFC 2119 [RFC2119] [RFC8174]

1) s1, 2nd para: s/[RFC5939] ./[RFC5939].