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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Tue, 28 May 2019 02:53:32 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-sipbrandy-osrtp-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 28 May 2019 10:03:48 -0500

> On May 28, 2019, at 4:53 AM, Barry Leiba via Datatracker <[email-masked]> wrote:
> 
> 

[…]

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.

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

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 28 May 2019 19:15:22 +0000

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Tuesday, May 28, 2019 11:04 AM
> To: Barry Leiba <[email-masked]>
> Cc: [email-masked]; [email-masked]; sipbrandy-
> [email-masked]; The IESG <[email-masked]>; Gonzalo Camarillo
> <[email-masked]>
> Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09:
> (with 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!
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 May 2019 14:22:24 -0500

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 <[email-masked]> wrote:
> 
> 
>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 29 May 2019 19:11:07 +0000

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2019 3:22 PM
> To: Roman Danyliw <[email-masked]>
> Cc: Ben Campbell <[email-masked]>; Barry Leiba
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; The IESG <[email-masked]>;
> Gonzalo Camarillo <[email-masked]>
> The esteem in which ZRTP is currently held is approximately the same
> esteem in which it was held when it was initially published.

On my reading list are the following academic pubs who's abstract suggest new insight into ZRTP's security properties ...

Bhargavan, K., et al.  Downgrade Resilience in Key Exchange Protocols.  2016 IEEE Symposium on Security and Privacy.
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7546520&tag=1

Shurmann, D.  et al.  Wiretapping End-to-End Encrypted VoIP Calls: Real-World Attacks on ZRTP.  Proceedings on Privacy Enhancing Technologies, 2017 (3):1-17.
https://petsymposium.org/2017/papers/issue3/paper01-2017-3-source.pdf

Roman

> >> Cc: [email-masked]; [email-masked];
> >> sipbrandy- [email-masked]; The IESG <[email-masked]>; Gonzalo
> >> Camarillo <[email-masked]>
> >>> 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").
> >>>
> >>
> >> 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"
> >>
> >> 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!
> >>