IETF Logo Mail Archive

Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT)

Roman Danyliw <rdd@cert.org> Tue, 28 May 2019 19:15 UTC

Return-Path: <rdd@cert.org>
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 31D971200B4; Tue, 28 May 2019 12:15:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 TJAXQR7M7kCi; Tue, 28 May 2019 12:15:29 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52521120041; Tue, 28 May 2019 12:15:29 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4SJFOMm021832; Tue, 28 May 2019 15:15:25 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x4SJFOMm021832
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559070925; bh=xbkT7EmHnkPys1QlKjik+NMUyxrLr6LOMW64oK7u3lQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MV7LqWuLFSNgcjyD5+EQ+21yMr0JV5atjFWgupvBSmh8PLd3QinxWjMaqEZD1Hj2e Zxp9sS8h8xuJod2OObEcVXGNpbEVZas8j/0bkEdBhBpAW87iR4VtVDd52WtfiMzUW2 WcfSnnGtI7HpvnT+p6OCsC1Zz2T0LkRXlgcYYXQ0=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4SJFNk8048384; Tue, 28 May 2019 15:15:23 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Tue, 28 May 2019 15:15:23 -0400
From: Roman Danyliw <rdd@cert.org>
To: Ben Campbell <ben@nostrum.com>, Barry Leiba <barryleiba@computer.org>
CC: "draft-ietf-sipbrandy-osrtp@ietf.org" <draft-ietf-sipbrandy-osrtp@ietf.org>, "sipbrandy@ietf.org" <sipbrandy@ietf.org>, "sipbrandy-chairs@ietf.org" <sipbrandy-chairs@ietf.org>, The IESG <iesg@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Thread-Topic: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT)
Thread-Index: AQHVFTs5gBVapXo2mUObzGrF9bezW6aA5bIA///Uo+A=
Date: Tue, 28 May 2019 19:15:22 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3379F4D@marathon>
References: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> <C79C4B59-2DC2-4DF8-B68A-7DCCB87EBFA1@nostrum.com>
In-Reply-To: <C79C4B59-2DC2-4DF8-B68A-7DCCB87EBFA1@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/bdztPdzi1FloFaoa96S_p-nMJvQ>
Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT)
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: Tue, 28 May 2019 19:15:31 -0000


> -----Original Message-----
> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: Tuesday, May 28, 2019 11:04 AM
> To: Barry Leiba <barryleiba@computer.org>
> Cc: draft-ietf-sipbrandy-osrtp@ietf.org; sipbrandy@ietf.org; sipbrandy-
> chairs@ietf.org; The IESG <iesg@ietf.org>; Gonzalo Camarillo
> <gonzalo.camarillo@ericsson.com>
> Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09:
> (with COMMENT)
> 
> 
> 
> > On May 28, 2019, at 4:53 AM, Barry Leiba via Datatracker
> <noreply@ietf.org> wrote:
> >
> >
> 
> 
> […]
> 
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I share the question of why this is Informational and why the shepherd
> > writeup doesn't explain (the writeup says little more than "yes" and "no").
> >
> 
> This was discussed quite a bit in the WG and prior to chartering. The
> reasoning for “informational” was two-fold:
> 
> 1) The draft does not (or was not supposed to) define new or modify existing
> protocols. It talks about how one can assemble existing building blocks to
> make the right things happen, not how to build new blocks. So it seemed like
> the most appropriate status was either “informational” or “BCP"
> 
> 2) Two of those “existing protocols”, namely ZRTP [RFC6189] and SDP
> Security Descriptions [RFC4568] are not particularly well regarded among
> some of our security experts, who indicated objections to using them in a
> new standards track document or BCP.

Was there a reason the WG didn't include these references/caveats to the ZRTP and SSDP SD given an improved understanding of their security properties since they were published?

Roman

> From a strictly historical perspective, the WG originally thought it needed to
> make a normative update to RFC5124. This was to be done is a separate
> tightly-scoped draft to progress in MMUSIC, since SIPBRANDY was not
> chartered to make normative changes to anything. However, later discussion
> suggested such a change was not necessary, and the separate draft was
> abandoned.
> 
> I agree that the shepherd report or (my preference) the draft itself should
> make this more clear. Perhaps some words could be added to section 1.1?
> 
> Thanks!
> 
> Ben (who has no unexpired hats relevant to this conversation).

v2.23.0 | Report a Bug | By Email