From nobody Mon Jun 17 07:47:49 2019 Return-Path: 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 A17F1120048; Mon, 17 Jun 2019 07:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 G4sMR9y5CtdF; Mon, 17 Jun 2019 07:47:30 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 628C2120135; Mon, 17 Jun 2019 07:47:30 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id v18so3528630uad.12; Mon, 17 Jun 2019 07:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x/QXzAPKYoVlptpyzYDWk7jGDs1lp9OjFVGg4FszNmk=; b=pzULsYNiebiVG/pY4rTOhDoPA8gf5hWnK854yOR9RG+CfPQeB7KsyX772tmBlk9KNK 7ONnN9BEUTK2Zs7oiwf+R4RxZr9ThDAwXeV0DPZx9mH4z9dS8fVYpc3qxgfvV9nIm3Zx 0snw45aXDKHWsMvsf2PdWYbpvPCx1s6a+nfAeI9bewZItB+S42kWKv7jEylQbuddRi/t PyQNXQqlhqpry/fs2fJfN30OnH5eY0VzeTGnpBZZFHXCQ4LQmZan5rRhePoj+BdoILrj pf7BsBljLKvLFrIr6ehC5VX0RnOz5WRe0bT4UosPKxVbsM0wrWCzbRH7iIGDqMhKhbFI OmsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x/QXzAPKYoVlptpyzYDWk7jGDs1lp9OjFVGg4FszNmk=; b=ul06VjIywvaPmjar5MvHRHaj3chCWU3iKrUCg5XqPK9i+vNCiCLZuv2hzCWOBKH98M hrSii5YBluodT0NE9t13fOCu1Ppi8A1Yry5YoA0/dWGApPhNEyQ4lj0ewazvKALcBYzT 840xHZ8Gh++qxPPlOOHaulwUamW4xn8Jn3siBch9Au25WuKxP7YtXsDA8YP/pVN2lehk JK5lRW0Arxx/KBsa8LdUyJcSfm1sJfyK8uJ45QNoA4+DwlJuuGUlB7rsde/6MWrfjfU+ DZyJBahuR+xjcTqP8uGWso8GLSQMqDpHk0Rk61OmrX+kM5BDYd9fLoRJI0HJMnSvMTtS L18Q== X-Gm-Message-State: APjAAAXd+OmVZqMG4ro+XVRZL0WYl4qwgEbLmEdd1KbCPkYjW01vB5MV xq8bwZ2miu0IHHuJkPpji/ALGbKIRRtP8+9QwxU= X-Google-Smtp-Source: APXvYqyv9yojZGLrPKO5Ie5PKYvCIOyUnZvVazO4ZP9EbCngXhtK6wDmojHB8zHoxqKE6jbZEZZKdkj2FrxDlCtCiUI= X-Received: by 2002:ab0:73d9:: with SMTP id m25mr11000055uaq.115.1560782849399; Mon, 17 Jun 2019 07:47:29 -0700 (PDT) MIME-Version: 1.0 References: <155804481707.19586.13843111552522558644@ietfa.amsl.com> In-Reply-To: <155804481707.19586.13843111552522558644@ietfa.amsl.com> From: Andy Hutton Date: Mon, 17 Jun 2019 15:47:22 +0100 Message-ID: To: Elwyn Davies Cc: gen-art@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sipbrandy] Genart last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 14:47:33 -0000 Thanks for these comments and see me comments below. I assume that I will need to submit an update. Andy On Thu, 16 May 2019 at 23:13, Elwyn Davies via Datatracker wrote: > > Reviewer: Elwyn Davies > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-sipbrandy-osrtp-09 > Reviewer: Elwyn Davies > Review Date: 2019-05-16 > IETF LC End Date: 2019-05-16 > IESG Telechat date: Not scheduled for a telechat > > Summary: Ready with nits. Thanks for an easy to read document. I am not sure > about whether it is acceptable to point to an expired (and effectively totally > dead) draft (draft-kaplan...) for signuficant motivation (see minor issues). > Please consult with higher authorities. > As indicated by Alissa I think the reference is okay since the kaplan draft is well known in the SIP industry and stable. > Major issues: > None > > Minor issues: > > S1, para 2: The discussion and motivation for the introduction of OSRTP is at > least partially derived from the motivation explained in Section 1 of > draft-kaplan-mmusic-best-effort-srtp. This is a long expired draft (2007) > which is not going to become an RFC. Given this, I wonder if the text ought to > be reproduced here, perhaps as an appendix? > I would prefer to leave it as it as was said previously the kaplan draft is well known and stable. > Nits/Editorial comments: > > Abstract: s./applied to Real-time/applied to the Real-time/ > OK, thanks. > Abstract: expand SDP on first use. > OK, thanks. > Abstract: expand SRTP on first use (Secure RTP). > OK, thanks > S1: The sentences expanding the meaning of cleartext and secure media could do > with a little expansion to make it clear that we are talking about media > streams even if that is what RTP is supposed to be about. Suggest: > > OLD: > In terms of secure media, cleartext is RTP [RFC3550] media which is negotiated > with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile > [RFC4585]. Comprehensive protection is Secure RTP [RFC3711], negotiated with a > secure profile, such as SAVP or SAVPF [RFC5124]. NEW: In the context of > transport of secure media streams using RTP and its secured derivatives, > cleartext is represented by an RTP [RFC3550] media stream which is negotiated > with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile > [RFC4585], whereas comprehensive protection is represented by a Secure RTP > [RFC3711] stream, negotiated with a secure profile, such as SAVP or SAVPF > [RFC5124]. ENDS > Done. > (I note that SAVP and SAVPF aren't acronyms and don't need expansion. OTOH > AVPF probably does.) > > S3: The terminology used in RFC 4566 and elsewhere seems to be m= sections > rather than m- sections. Suggest s/m-/m=/g (4 places) > OK. > S3.4, last sentence: the backward reference to Section 3.1 is not in RFC > format. s/section [3.1]/Section 3.1/ OK > > S4, para 3: I think the 'must' here is normative. s/ an encrypted signaling > channel must still be used./ an encrypted signaling channel MUST still be used./ > I think you are correct. > S6: The note to the RFC Editor should also note that the referenceventries > SIPCONNECT, RFC6982 and IMTC-SIP in s8 should also be removed. > I think I can just remove the section and references and save the RFC Editor some work > > _______________________________________________ > Sipbrandy mailing list > Sipbrandy@ietf.org > https://www.ietf.org/mailman/listinfo/sipbrandy From nobody Mon Jun 17 08:37:42 2019 Return-Path: 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 D3C391201C3; Mon, 17 Jun 2019 08:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 k7K3i0q6Peh2; Mon, 17 Jun 2019 08:37:31 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 6061512015E; Mon, 17 Jun 2019 08:37:29 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id u124so6410804vsu.2; Mon, 17 Jun 2019 08:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=epR6LaxeamJCTJC5UtI3jINJ5KZB8kzzUr4HGG+AzqQ=; b=Mszmzp1oR0tjf3jgKKYioIQNvx8hvZ5NwL4KIdnhRfjdx0OPfOPq0wuLyv6vhKGsYc d6oRG6uOZMfN9FrR+hHtm1SDMhVqQjUZ+bVqalwS19EtTzEezmoO8d4/60bg8AA+C6Kv PX19xCd8Y40amkQ9IT1qu4o5IWxniafj/36Y18W93sy5+6PVqxzrwkoRtHIt40+irego ye9XiDGlp0G/Pu6cteMOv4W3TLoliUS1hxM16vPp+IJRD+KNqA2hAyuXX2tjE9LT0uAh ONmCp4Q7r9152fzjvTl7hbEEJu9XqRBzkwUY6O5Uz6dfwcMCzw02sQQoyX5bzlmSap+k hw2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=epR6LaxeamJCTJC5UtI3jINJ5KZB8kzzUr4HGG+AzqQ=; b=TleSQqJgBkO5wdxqempO7OzRMTdc3sarErtSAQzpC793Gpx7szhdklJ2MVgDVjCnq5 yBTuIBJ2SEdMWJVNalkfkNwL3tJ/St50xoICSLGmYJlPIcd94/Z+jfJDnb62U6UL0D/j JvtkrJUn42uXFh+BiIVWx4pJx4Q2a6QIOXXZNql2AG2R13ElRD5xkJalT+PN6qn5fYWQ htseViuw7T/3ws/t7aIgVB113NIvsEFhpjIsMSEXkoFrFUGakc2MwTs9oNYwefo3pCKe LtZA8IiwxuRIktdUsdMEpK52of1Wx+lnV1BqmHIfn2dvMnjK1+voLSkPMEbuMd3tDlwM 14uQ== X-Gm-Message-State: APjAAAVQlZLxR8HhXmuH8x09xWDRHh8E/N0FMDmLO0d+XBdoiPqkbUZK jarZ/fWAgRbef9KYGwR3x46uIv3iL4QtXFBwkoc= X-Google-Smtp-Source: APXvYqwKszDrpK4KhzyUmvqiOHF32bByTnufrBeYKmt2RC7jd/+DsLgs6MkV2FISXaNEntbuWR7OTPv+nT5XL4OIMPs= X-Received: by 2002:a67:e3da:: with SMTP id k26mr20269708vsm.131.1560785848429; Mon, 17 Jun 2019 08:37:28 -0700 (PDT) MIME-Version: 1.0 References: <155806486830.19511.11021785086259621978@ietfa.amsl.com> In-Reply-To: <155806486830.19511.11021785086259621978@ietfa.amsl.com> From: Andy Hutton Date: Mon, 17 Jun 2019 16:37:21 +0100 Message-ID: To: Allison Mankin Cc: tsv-art@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sipbrandy] Tsvart last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 15:37:34 -0000 On Fri, 17 May 2019 at 04:48, Allison Mankin via Datatracker 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@ietf.org 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. > From nobody Mon Jun 17 09:04:45 2019 Return-Path: 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 9A5831202C6; Mon, 17 Jun 2019 09:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nRPDqsfbpvU4; Mon, 17 Jun 2019 09:04:28 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 524911202DF; Mon, 17 Jun 2019 09:04:23 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id 190so6450986vsf.9; Mon, 17 Jun 2019 09:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2CNVjeEokIn1F/ibRD6MNIkwo35+rXUvXxaB2U7R5x4=; b=px6vSa36qveaLC7cVURcQILjfVH1J3HwquIXSy9HDLnuq85wyFPX60W1GFwBzD92o0 hyaasIUCkfa3mmorFYKCebFrBvdS3Nd9neYbffxotrOFm7q1zVbS0wpbfslcSr6EnCGx LkmY3u1badSta2I1QrzGU8DGAG1+kwBW+VnyYavlXnHX1hDJ5FyhDYxiCVCNPCkDNMUr hKBkNrTVAcxdbB/wzn5u8iMQlib1r1rcb69QBvFxnzCT1yMqr4b+gFm3b9OpQ8rnSf7m hSKxqn2S0m/UQlZh8ZVCKe4hxHOuopz8qgkc1NxxIbyZw/7YIrqFBcpNZVzD8yL1+1YY CFQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2CNVjeEokIn1F/ibRD6MNIkwo35+rXUvXxaB2U7R5x4=; b=hLt/3Va1/cBLuxG+fbPg6i5bi0qVMAy8OPOS+hCvGmdDbdNgIQkR7tDUUcHX3s6GrV XPwWPMiA87Kki+CqD2beeOEHe61aZY0cP00PocfjBI/7yljbJbIYjd+QsP2B1X07o+Y3 P9CNvoL8fIYXdh6CfuJz80BmppMKvi4ZZTRNFwhdwf1Mnxrz+TRgawQjF48JRJTaXJq3 9OyJy9yHzLch3sb/RjHGwP9b7aRCpEkWtVSaKYftCxSCii1VGvTIfo30kC+V1+5PSAsf cVay/KZv9znuLK53VB310JFZb4KePR8SdwuZnQPUxM+deqMVdh0aui++TgobTQkagoWv /Wdw== X-Gm-Message-State: APjAAAWpmyaCcoIyi9dL59wGG9kc/BSEj2vjYcmO80SAw7M65IBBEo/m wnYDdvE/TZv2V6uur/c3yWcMlO4lwnMpT17xl4o= X-Google-Smtp-Source: APXvYqxsJ5k9wgrWuBSi0M1XQg23BgXTuhY1ynZIT+IYM2+URTzyQU0pDvx6t+Qrx4Tw+e6xZ5dun6cA+g3/37+9/UA= X-Received: by 2002:a67:7d83:: with SMTP id y125mr25936498vsc.126.1560787462296; Mon, 17 Jun 2019 09:04:22 -0700 (PDT) MIME-Version: 1.0 References: <155900970362.650.8194184838834826261@ietfa.amsl.com> In-Reply-To: <155900970362.650.8194184838834826261@ietfa.amsl.com> From: Andy Hutton Date: Mon, 17 Jun 2019 17:04:15 +0100 Message-ID: To: Sean Turner Cc: secdir@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sipbrandy] Secdir last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:04:30 -0000 Thanks for the comments, see below. Andy On Tue, 28 May 2019 at 03:15, Sean Turner via Datatracker wrote: > > Reviewer: Sean Turner > Review result: Has Issues > > I had a read of the draft as well as the GENART and TSVART reviews (to avoid > duplicating comments). > > Summary: Ready with (minor) issues > > Issues: > > 0) I assume that the mismatch the TSVART refers to in the security > considerations has to do with 1) changing 4568 to require encryption but not > fail if authentication is not available, 2) pointing out that 4568's > requirement is routinely ignore for end-to-end encryption because using TLS > with intermediaries won't protect the SDP key, and 3) and reference errors (see > the next issue). On 1, that's kind the point of OSRTP - take the encryption > you can get. On 2, because it's the security considerations this document is > just saying don't expect to get end-to-end. Assuming, I've interpreted this I > think this draft is okay. > > 1) I think these are just reference errors, but it would be good to double > check these (and I hadn't seen a response yet - might have missed it): > > S4: Not sure about these references too RFC7435. Maybe they should be to RFC > 4568 instead? > > s/The security considerations of [RFC7435] apply to OSRTP, > /The security considerations of [RFC4568] apply to OSRTP, > > s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568] > > s/understood that the [RFC7435]/understood that the [RFC4568] > Yes these are reference errors and I will fix as you describe. > Bikesheds: > > 0) The fact that it's Informational struck me as odd. > > 1) The fact there are no updates listed also strikes me as odd. > Ben Campbell gave the answer to this in his mail on 28th May it is a very long story and we were made to jump through many hoops and and in the end this is what had to be done. > Nits: > > 0) s2: Nits reports an error with the para. I think it's: > > s/RFC 2119 [RFC2119] RFC 8174 [RFC8174] > /RFC 2119 [RFC2119] [RFC8174] > > 1) s1, 2nd para: s/[RFC5939] ./[RFC5939]. Thanks. > > _______________________________________________ > Sipbrandy mailing list > Sipbrandy@ietf.org > https://www.ietf.org/mailman/listinfo/sipbrandy From nobody Mon Jun 17 09:16:37 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A225B120092; Mon, 17 Jun 2019 09:16:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipbrandy@ietf.org Message-ID: <156078819561.6429.379299948867874986@ietfa.amsl.com> Date: Mon, 17 Jun 2019 09:16:35 -0700 Archived-At: Subject: [Sipbrandy] I-D Action: draft-ietf-sipbrandy-osrtp-10.txt X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:16:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Best-practice Recommendations Against Network Dangers to privacY WG of the IETF. Title : An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) Authors : Alan Johnston Bernard Aboba Andrew Hutton Roland Jesske Thomas Stach Filename : draft-ietf-sipbrandy-osrtp-10.txt Pages : 8 Date : 2019-06-17 Abstract: Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for Secure RTP (SRTP). OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-10 https://datatracker.ietf.org/doc/html/draft-ietf-sipbrandy-osrtp-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipbrandy-osrtp-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 17 11:39:14 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7891312069F; Mon, 17 Jun 2019 11:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , sipbrandy@ietf.org, sipbrandy-chairs@ietf.org, draft-ietf-sipbrandy-osrtp@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo , alexey.melnikov@isode.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156079673941.4801.17041069847785949499.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2019 11:38:59 -0700 Archived-At: Subject: [Sipbrandy] Document Action: 'An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)' to Informational RFC (draft-ietf-sipbrandy-osrtp-10.txt) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 18:39:00 -0000 The IESG has approved the following document: - 'An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)' (draft-ietf-sipbrandy-osrtp-10.txt) as Informational RFC This document is the product of the SIP Best-practice Recommendations Against Network Dangers to privacY Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ Technical Summary: Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP does not require SDP extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for SRTP. OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state. Working Group Summary: There is consensus in the WG around this document. Document Quality: Section 6 of the document (to be removed before its publication as an RFC) discusses the implementation status of the techniques described in the document. Personnel: Gonzalo Camarillo is the Document Shepherd. Alexey Melnikov Campbell is the responsible AD. From nobody Mon Jun 17 11:44:42 2019 Return-Path: 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 A469E12003E; Mon, 17 Jun 2019 11:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cpZPrlNTLaUM; Mon, 17 Jun 2019 11:44:24 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 A26C71206B4; Mon, 17 Jun 2019 11:44:02 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id b7so4460770pls.6; Mon, 17 Jun 2019 11:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TR6J3Ou7UFP5+lhg1E/78WbML9x8YVqmMl+v//Fl42k=; b=Br3HMjSyT+9gzipWS96yzlhSwL2eGES6DOgW4sKPsHaj8LGobOnIDhP8AxAl3qB1vU ZetGlgDNn6007qC0+sEF3x+gQONt79f4onvgKCRoEsItyrbX7mGPxS7fOlihq3KRGJX2 SWFxTcaQtmv4i9vMewutvqSGIfnEgGUQsKr/X58UMAhDuSYpwe9Q5asQO+YGh9/z9CoF /gTUOmr2Wb7V316PIG2G0wZV+sOugDfvvZJe8jYuMQoE4bx9RocZrOh0Z39iBQxuUM+W 5cde9T/y5X7YC9q8bFEQoabbAljUlf3JYYSo3ApS4/K8ycgF+mhTOBi6hoUuB3yDHIhN YkyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TR6J3Ou7UFP5+lhg1E/78WbML9x8YVqmMl+v//Fl42k=; b=W7oOPZLdff6n1M+kkwq4Z3HJZXBHGxxwjDs0iMxEgQwmm449xr9Qi6KDnxk14Ktq+N 8bwAduzvgiW9/bwOKXL/VOUsyDIo94/E97jf8Q1RVBjIEZNDLj9c/v1+wiCMo6hgYtDS t8QmmOrP8iz0i02xykCq7VIBntDkqL6rYH0GajAcqlHrWH5uPY63Bo4JkBxC0HJLoViG gCch5oqfXxx+u5fhwwlCIbB+eopowEOIwiLt6PiBisLWMJKRF/JUzFrXvZARSRc85t9k yzBARQSHXPrsHK+nzLKMjc35WoK3vyvJ+FKL96vB6Y2QkKm7AwK5PfXCY8mAIh8wrhf6 pHng== X-Gm-Message-State: APjAAAXsysrYSn+9Fi/vjnGTwnhe1kIAJa/eRQIcogtiH1b9X5d63xT9 33A2ZPcX12YUKEsvosCZO0AfP8J8fpqP9gKnfAQ= X-Google-Smtp-Source: APXvYqwP7uDammFnMXmmxxNJyp5iKLglMsg9ouFbw2U4xEu24xeSbN9O8YrZAn5/o9oyNJbSHgDnIu+O9iVQp1cGXN8= X-Received: by 2002:a17:902:e512:: with SMTP id ck18mr3418680plb.53.1560797041927; Mon, 17 Jun 2019 11:44:01 -0700 (PDT) MIME-Version: 1.0 References: <155806486830.19511.11021785086259621978@ietfa.amsl.com> In-Reply-To: From: Allison Mankin Date: Mon, 17 Jun 2019 14:43:51 -0400 Message-ID: To: Andy Hutton Cc: draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org, sipbrandy@ietf.org, tsv-art@ietf.org Content-Type: multipart/alternative; boundary="000000000000402c7c058b8961b9" Archived-At: Subject: Re: [Sipbrandy] Tsvart last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 18:44:27 -0000 --000000000000402c7c058b8961b9 Content-Type: text/plain; charset="UTF-8" Thank you for taking these comments. All good. The Sec Dir reviewer (Sean) also spoke to my comment, and your response is consistent with what he wrote. On Mon, Jun 17, 2019 at 11:37 Andy Hutton wrote: > On Fri, 17 May 2019 at 04:48, Allison Mankin via Datatracker > 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@ietf.org 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. > > > > --000000000000402c7c058b8961b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for taking these comments. All good. The S= ec Dir reviewer (Sean) also spoke to my comment, and your response is consi= stent with what he wrote.=C2=A0

On Mon, Jun 17, 2019 at 11:37 And= y Hutton <andyhutton.ietf@g= mail.com> wrote:
On Fri, 17 = May 2019 at 04:48, Allison Mankin via Datatracker
<noreply@ietf.org<= /a>> wrote:
>
> Reviewer: Allison Mankin
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review t= eam's
> ongoing effort to review key IETF documents. These comments were writt= en
> primarily for the transport area directors, but are copied to the docu= ment'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 t= his
> review as part of the last-call comments they receive. Please always C= C
> tsv-art@ietf.org= if you reply to or forward this review.
>
> This document doesn't raise any specifically transport-focused que= stions
> for me.=C2=A0 I appreciated the clear discussion of the types of secur= ity
> arrangements that can be made by Offer-Answer SIP and I found the draf= t
> a valuable read.=C2=A0 The implementation section is quite interesting= .
>
> I have a couple of issues with Section 4, though they are not about tr= ansport.
> So I'm going to mention them, but defer to the Security Area beyon= d 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: >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For SDP Security Descriptions key agreement = [RFC4568], an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authenticated signaling channel does not nee= d to be used with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0OSRTP if it is not available, although an en= crypted signaling
>=C2=A0 =C2=A0 =C2=A0 =C2=A0channel must still be used.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 8.3 of [RFC7435] requires that any m= essages that contain SRTP keys be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0encrypted, and further says that encryption = "SHOULD" provide end-to-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0end confidentiality protection if intermedia= ries that could inspect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the SDP message are present.
>

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

> Also, there isn't a section 8.3 of RFC7435.=C2=A0 Is this an incor= rect 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 &q= uot;requirement
> for end-to-end confidentiality."=C2=A0 RFC7435 has a preference f= or confidentiality of
> authentication if there is authentication, but TOFU means there isn= 9;t a requirement.
> The sentence is too general.
>
>=C2=A0 =C2=A0 At the time of this writing, it is
>=C2=A0 =C2=A0 understood that the [RFC7435] requirement for end-to-end<= br> >=C2=A0 =C2=A0 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.

>
--000000000000402c7c058b8961b9--