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

Adam Roach <adam@nostrum.com> Tue, 28 May 2019 19:22 UTC

Return-Path: <adam@nostrum.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 079C2120090 for <sipbrandy@ietfa.amsl.com>; Tue, 28 May 2019 12:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level:
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 U1edT_rUr4xF for <sipbrandy@ietfa.amsl.com>; Tue, 28 May 2019 12:22:33 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B6F1E120004 for <sipbrandy@ietf.org>; Tue, 28 May 2019 12:22:33 -0700 (PDT)
Received: from [IPv6:2607:fb90:44e8:816b:b53e:2a97:874b:3c9] ([172.58.105.25]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x4SJMUus085664 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 28 May 2019 14:22:32 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1559071353; bh=ANHw/RTzjyiipl9qLU3zfY2Uv1obhMzExbS2LqedBDk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Q3utyI3uIQ1+Rqu4zCFRgystofjnQ8/kU0jF3mGX6vRkFYHZxUoykcN7oGs8/8p+v S1vvcCLtoSJV1zNs2FDav5qGDAlOHS6qxWBHlShvGZaVFpsYdbuBY+mZUATvjR6Hmu wI9xd++t9q5wThNDBidZSFaeZXYaNDmu+LPPGsGc=
X-Authentication-Warning: raven.nostrum.com: Host [172.58.105.25] claimed to be [IPv6:2607:fb90:44e8:816b:b53e:2a97:874b:3c9]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Adam Roach <adam@nostrum.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3379F4D@marathon>
Date: Tue, 28 May 2019 14:22:24 -0500
Cc: Ben Campbell <ben@nostrum.com>, Barry Leiba <barryleiba@computer.org>, "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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87605986-BBD8-46B6-9E4D-E24CB823DBEF@nostrum.com>
References: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> <C79C4B59-2DC2-4DF8-B68A-7DCCB87EBFA1@nostrum.com> <359EC4B99E040048A7131E0F4E113AFC01B3379F4D@marathon>
To: Roman Danyliw <rdd@cert.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/0HbVP4YzHsyMLaxKQpfQ1ZL5g2g>
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:22:35 -0000

The esteem in which ZRTP is currently held is approximately the same esteem in which it was held when it was initially published.

/a

> On May 28, 2019, at 14:15, Roman Danyliw <rdd@cert.org> wrote:
> 
> 
> 
>> -----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>rg>; 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).