Re: Tsvart last call review of draft-ietf-sipbrandy-osrtp-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 17 May 2019 at 04:48, Allison Mankin via Datatracker
<noreply@xxxxxxxx> wrote:
>
> Reviewer: Allison Mankin
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@xxxxxxxx if you reply to or forward this review.
>
> This document doesn't raise any specifically transport-focused questions
> for me.  I appreciated the clear discussion of the types of security
> arrangements that can be made by Offer-Answer SIP and I found the draft
> a valuable read.  The implementation section is quite interesting.
>
> I have a couple of issues with Section 4, though they are not about transport.
> So I'm going to mention them, but defer to the Security Area beyond just
> flagging them. Hence, I've marked the draft Ready with Nits rather than
> Ready with Issues.
>
> 1. I find the two sentences below inconsistent with each other, with a small-m
> "must" and a cited "SHOULD" for the same issue:
>
>       For SDP Security Descriptions key agreement [RFC4568], an
>       authenticated signaling channel does not need to be used with
>       OSRTP if it is not available, although an encrypted signaling
>       channel must still be used.
>
>       Section 8.3 of [RFC7435] requires that any messages that contain SRTP keys be
>       encrypted, and further says that encryption "SHOULD" provide end-to-
>       end confidentiality protection if intermediaries that could inspect
>       the SDP message are present.
>

The "must" will be changed to "MUST".

> Also, there isn't a section 8.3 of RFC7435.  Is this an incorrect reference or a reference
> to a pre-publication version of RFC7435?
>

The reference is incorrect it should be RFC 4568, good catch.


> 2. I feel the sentence below misrepresents RFC7435 with its wording "requirement
> for end-to-end confidentiality."  RFC7435 has a preference for confidentiality of
> authentication if there is authentication, but TOFU means there isn't a requirement.
> The sentence is too general.
>
>    At the time of this writing, it is
>    understood that the [RFC7435] requirement for end-to-end
>    confidentiality protection is commonly ignored.
>

Again it is the reference that is incorrect it should be RFC 4568.

> Editorial/Nits
> The section 4 reference to section 8.3 of RFC7435 needs to be fixed.
>
okay, thanks.

>




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux