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

[Adam Roach <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: iesg [mailto:[e-mail]] On Behalf Of Ben Campbell
>> Sent: Tuesday, May 28, 2019 11:04 AM
>> To: Barry Leiba <[e-mail]>
>> Cc: [e-mail]; [e-mail]; sipbrandy-
>> [e-mail]; The IESG <[e-mail]>; Gonzalo Camarillo
>> <[e-mail]>
>> 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
>> <[e-mail]> 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).