Re: [Sipbrandy] Tsvart last call review of draft-ietf-sipbrandy-osrtp-09

Andy Hutton <andyhutton.ietf@gmail.com> Mon, 17 June 2019 15:37 UTC

Return-Path: <andyhutton.ietf@gmail.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 D3C391201C3; Mon, 17 Jun 2019 08:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 k7K3i0q6Peh2; Mon, 17 Jun 2019 08:37:31 -0700 (PDT)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 6061512015E; Mon, 17 Jun 2019 08:37:29 -0700 (PDT)
Received: by mail-vs1-xe36.google.com with SMTP id u124so6410804vsu.2; Mon, 17 Jun 2019 08:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=epR6LaxeamJCTJC5UtI3jINJ5KZB8kzzUr4HGG+AzqQ=; b=Mszmzp1oR0tjf3jgKKYioIQNvx8hvZ5NwL4KIdnhRfjdx0OPfOPq0wuLyv6vhKGsYc d6oRG6uOZMfN9FrR+hHtm1SDMhVqQjUZ+bVqalwS19EtTzEezmoO8d4/60bg8AA+C6Kv PX19xCd8Y40amkQ9IT1qu4o5IWxniafj/36Y18W93sy5+6PVqxzrwkoRtHIt40+irego ye9XiDGlp0G/Pu6cteMOv4W3TLoliUS1hxM16vPp+IJRD+KNqA2hAyuXX2tjE9LT0uAh ONmCp4Q7r9152fzjvTl7hbEEJu9XqRBzkwUY6O5Uz6dfwcMCzw02sQQoyX5bzlmSap+k hw2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=epR6LaxeamJCTJC5UtI3jINJ5KZB8kzzUr4HGG+AzqQ=; b=TleSQqJgBkO5wdxqempO7OzRMTdc3sarErtSAQzpC793Gpx7szhdklJ2MVgDVjCnq5 yBTuIBJ2SEdMWJVNalkfkNwL3tJ/St50xoICSLGmYJlPIcd94/Z+jfJDnb62U6UL0D/j JvtkrJUn42uXFh+BiIVWx4pJx4Q2a6QIOXXZNql2AG2R13ElRD5xkJalT+PN6qn5fYWQ htseViuw7T/3ws/t7aIgVB113NIvsEFhpjIsMSEXkoFrFUGakc2MwTs9oNYwefo3pCKe LtZA8IiwxuRIktdUsdMEpK52of1Wx+lnV1BqmHIfn2dvMnjK1+voLSkPMEbuMd3tDlwM 14uQ==
X-Gm-Message-State: APjAAAVQlZLxR8HhXmuH8x09xWDRHh8E/N0FMDmLO0d+XBdoiPqkbUZK jarZ/fWAgRbef9KYGwR3x46uIv3iL4QtXFBwkoc=
X-Google-Smtp-Source: APXvYqwKszDrpK4KhzyUmvqiOHF32bByTnufrBeYKmt2RC7jd/+DsLgs6MkV2FISXaNEntbuWR7OTPv+nT5XL4OIMPs=
X-Received: by 2002:a67:e3da:: with SMTP id k26mr20269708vsm.131.1560785848429; Mon, 17 Jun 2019 08:37:28 -0700 (PDT)
MIME-Version: 1.0
References: <155806486830.19511.11021785086259621978@ietfa.amsl.com>
In-Reply-To: <155806486830.19511.11021785086259621978@ietfa.amsl.com>
From: Andy Hutton <andyhutton.ietf@gmail.com>
Date: Mon, 17 Jun 2019 16:37:21 +0100
Message-ID: <CAB7PXwRSt0fDXV4qebSjcXqxHywrK8O+DzCJRE+crC7VZPz8bQ@mail.gmail.com>
To: Allison Mankin <allison.mankin@gmail.com>
Cc: tsv-art@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/iES2kReW92J2IybNVcDv1JGsru4>
Subject: Re: [Sipbrandy] Tsvart last call review of draft-ietf-sipbrandy-osrtp-09
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: Mon, 17 Jun 2019 15:37:34 -0000

On Fri, 17 May 2019 at 04:48, Allison Mankin via Datatracker
<noreply@ietf.org> wrote:
>
> Reviewer: Allison Mankin
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> This document doesn't raise any specifically transport-focused questions
> for me.  I appreciated the clear discussion of the types of security
> arrangements that can be made by Offer-Answer SIP and I found the draft
> a valuable read.  The implementation section is quite interesting.
>
> I have a couple of issues with Section 4, though they are not about transport.
> So I'm going to mention them, but defer to the Security Area beyond just
> flagging them. Hence, I've marked the draft Ready with Nits rather than
> Ready with Issues.
>
> 1. I find the two sentences below inconsistent with each other, with a small-m
> "must" and a cited "SHOULD" for the same issue:
>
>       For SDP Security Descriptions key agreement [RFC4568], an
>       authenticated signaling channel does not need to be used with
>       OSRTP if it is not available, although an encrypted signaling
>       channel must still be used.
>
>       Section 8.3 of [RFC7435] requires that any messages that contain SRTP keys be
>       encrypted, and further says that encryption "SHOULD" provide end-to-
>       end confidentiality protection if intermediaries that could inspect
>       the SDP message are present.
>

The "must" will be changed to "MUST".

> Also, there isn't a section 8.3 of RFC7435.  Is this an incorrect reference or a reference
> to a pre-publication version of RFC7435?
>

The reference is incorrect it should be RFC 4568, good catch.


> 2. I feel the sentence below misrepresents RFC7435 with its wording "requirement
> for end-to-end confidentiality."  RFC7435 has a preference for confidentiality of
> authentication if there is authentication, but TOFU means there isn't a requirement.
> The sentence is too general.
>
>    At the time of this writing, it is
>    understood that the [RFC7435] requirement for end-to-end
>    confidentiality protection is commonly ignored.
>

Again it is the reference that is incorrect it should be RFC 4568.

> Editorial/Nits
> The section 4 reference to section 8.3 of RFC7435 needs to be fixed.
>
okay, thanks.

>