Subject: Re: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 11 Jan 2018 11:11:03 +0200

Authors of draft-ietf-sipbrandy-rtpsec,

this WGLC ends tomorrow. You got a few comments on this list so far.
What is your time plan to address them?

Cheers,

Gonzalo

On 12/12/2017 3:46 PM, Gonzalo Camarillo wrote:
> Folks,
> 
> I would like to start a WGLC on the following draft. This WGLC will
> end on January 12th:
> 
> https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/
> 
> Thanks,
> 
> Gonzalo
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 11 Jan 2018 16:52:48 +0000

Thanks for these notes Gonzalo. A few replies here.

>
>I have a few initial WGLC comments on this draft. The draft mentions a
>few protocols (e.g., SDP) without providing a reference to them. Please,
>expand acronyms and add a reference on first use throughout the document.
>
>In section 3.1, "Real-time Protocol" should be something along the
>following lines: "RTP (Real-time Transport Protocol) [RFC3550]".

No problem, will expand those.

>
>Section 3.1 talks about STIR as the "current target mechanism". I would
>remove "current", or rephrase it and talk about the mechanism we
>recommend to use instead.
>
>I guess at this point changes in STIR may still trigger modifications in
>this draft, right?

No, I think (hope) STIR is a stable reference, at this point.

>
>Section 4 says:
>
>>  The SIPBRANDY deployment profile of STIR
>>  for media confidentiality thus shifts these responsibilities to the
>>  endpoints rather than the intermediaries.
>
>I would rephrase it so that the text is more explicit. If intermediaries
>MUST NOT provide the verification service, the text should say so.

It's not that they MUST NOT provide it... It's that if they do provide it,
it has to be redundant with the endpoint providing it. There are a few
potential pitfalls though: if, for example, the verification service does
not trust the signing credential but the endpoint does, we wouldn't want
an intermediary to drop the call, say. In general, in STIR, we don't
encourage that sort of behavior from intermediaries, but, we could
certainly clarify all this with a bit of text here. Will add something.

>
>Section 5 says:
>
>> In [I-D.johnston-dispatch-osrtp], opportunistic approaches considered
>> include DTLS-SRTP, security descriptions [RFC4568], and ZRTP
>> [RFC6189].
>>
>>    DTLS-SRTP is the only Standards Track Internet protocol for media
>>    security.  For that reason, this specification REQUIRES support for
>>    DTLS-SRTP.
>
>But RFC 4568 is also Standards Track:
>
>https://tools.ietf.org/html/rfc4568

The AD responsible for that at the time clearly dropped the ball. But I'll
fix the text here, thanks.

Jon Peterson
Neustar, Inc.

>_______________________________________________
>Sipbrandy mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipbrandy