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

Andy Hutton <> Mon, 17 June 2019 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3C391201C3; Mon, 17 Jun 2019 08:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k7K3i0q6Peh2; Mon, 17 Jun 2019 08:37:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6061512015E; Mon, 17 Jun 2019 08:37:29 -0700 (PDT)
Received: by with SMTP id u124so6410804vsu.2; Mon, 17 Jun 2019 08:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
From: Andy Hutton <>
Date: Mon, 17 Jun 2019 16:37:21 +0100
Message-ID: <>
To: Allison Mankin <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Sipbrandy] Tsvart last call review of draft-ietf-sipbrandy-osrtp-09
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIPBRANDY working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
<> 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
> 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.