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

Allison Mankin <allison.mankin@gmail.com> Mon, 17 June 2019 18:44 UTC

Return-Path: <allison.mankin@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A469E12003E; Mon, 17 Jun 2019 11:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 cpZPrlNTLaUM; Mon, 17 Jun 2019 11:44:24 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 A26C71206B4; Mon, 17 Jun 2019 11:44:02 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id b7so4460770pls.6; Mon, 17 Jun 2019 11:44:02 -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=TR6J3Ou7UFP5+lhg1E/78WbML9x8YVqmMl+v//Fl42k=; b=Br3HMjSyT+9gzipWS96yzlhSwL2eGES6DOgW4sKPsHaj8LGobOnIDhP8AxAl3qB1vU ZetGlgDNn6007qC0+sEF3x+gQONt79f4onvgKCRoEsItyrbX7mGPxS7fOlihq3KRGJX2 SWFxTcaQtmv4i9vMewutvqSGIfnEgGUQsKr/X58UMAhDuSYpwe9Q5asQO+YGh9/z9CoF /gTUOmr2Wb7V316PIG2G0wZV+sOugDfvvZJe8jYuMQoE4bx9RocZrOh0Z39iBQxuUM+W 5cde9T/y5X7YC9q8bFEQoabbAljUlf3JYYSo3ApS4/K8ycgF+mhTOBi6hoUuB3yDHIhN YkyQ==
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=TR6J3Ou7UFP5+lhg1E/78WbML9x8YVqmMl+v//Fl42k=; b=W7oOPZLdff6n1M+kkwq4Z3HJZXBHGxxwjDs0iMxEgQwmm449xr9Qi6KDnxk14Ktq+N 8bwAduzvgiW9/bwOKXL/VOUsyDIo94/E97jf8Q1RVBjIEZNDLj9c/v1+wiCMo6hgYtDS t8QmmOrP8iz0i02xykCq7VIBntDkqL6rYH0GajAcqlHrWH5uPY63Bo4JkBxC0HJLoViG gCch5oqfXxx+u5fhwwlCIbB+eopowEOIwiLt6PiBisLWMJKRF/JUzFrXvZARSRc85t9k yzBARQSHXPrsHK+nzLKMjc35WoK3vyvJ+FKL96vB6Y2QkKm7AwK5PfXCY8mAIh8wrhf6 pHng==
X-Gm-Message-State: APjAAAXsysrYSn+9Fi/vjnGTwnhe1kIAJa/eRQIcogtiH1b9X5d63xT9 33A2ZPcX12YUKEsvosCZO0AfP8J8fpqP9gKnfAQ=
X-Google-Smtp-Source: APXvYqwP7uDammFnMXmmxxNJyp5iKLglMsg9ouFbw2U4xEu24xeSbN9O8YrZAn5/o9oyNJbSHgDnIu+O9iVQp1cGXN8=
X-Received: by 2002:a17:902:e512:: with SMTP id ck18mr3418680plb.53.1560797041927; Mon, 17 Jun 2019 11:44:01 -0700 (PDT)
MIME-Version: 1.0
References: <155806486830.19511.11021785086259621978@ietfa.amsl.com> <CAB7PXwRSt0fDXV4qebSjcXqxHywrK8O+DzCJRE+crC7VZPz8bQ@mail.gmail.com>
In-Reply-To: <CAB7PXwRSt0fDXV4qebSjcXqxHywrK8O+DzCJRE+crC7VZPz8bQ@mail.gmail.com>
From: Allison Mankin <allison.mankin@gmail.com>
Date: Mon, 17 Jun 2019 14:43:51 -0400
Message-ID: <CAP8yD=swusmZZM1N=RqJn-JbvyDn=gw_9-Ucbf4GpqXg5tSbuQ@mail.gmail.com>
To: Andy Hutton <andyhutton.ietf@gmail.com>
Cc: draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org, sipbrandy@ietf.org, tsv-art@ietf.org
Content-Type: multipart/alternative; boundary="000000000000402c7c058b8961b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/54RsoF1ln7Ivz18D4ljF3iusbe8>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-sipbrandy-osrtp-09
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2019 18:44:27 -0000

Thank you for taking these comments. All good. The Sec Dir reviewer (Sean)
also spoke to my comment, and your response is consistent with what he
wrote.

On Mon, Jun 17, 2019 at 11:37 Andy Hutton <andyhutton.ietf@gmail.com> wrote:

> 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.
>
> >
>