From nobody Sun Jun 6 17:54:14 2021 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5A3A2F33; Sun, 6 Jun 2021 17:54:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shawn Emery via Datatracker To: Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org, last-call@ietf.org, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162302724403.5524.7530871359171917876@ietfa.amsl.com> Reply-To: Shawn Emery Date: Sun, 06 Jun 2021 17:54:04 -0700 Archived-At: Subject: [Perc] Secdir last call review of draft-ietf-perc-dtls-tunnel-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 00:54:04 -0000 Reviewer: Shawn Emery Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a DTLS tunneling protocol for Privacy-Enhanced RTP Conferencing (PERC). This entails a key exchange between the conference end-points and the key distributor through a delegate, media distributor. The security considerations section does exist and describes that the media distributor does not introduce any additional security issues given that it is just on-path with the key exchange between the endpoint and the key distributor. Secondly, the key material between the media distributor and key distributor is protected through the mutually authenticated connection between the two entities. Thirdly, the meta data exchanged between the media distributor and key distributor is not sensitive information, but is still protected through the TLS connection. I agree with the above assertions. Besides the concerns described in the genart review about the impact of key material disclosure, the authors should consider the various other forms of security issues against the protocol, such as downgrade/DoS attacks from profile negotiation, etc. The section could list and simply refer to the base RFCs, 5764, 8871, etc., to provide remediation against these attacks. General comments: The example message flow and binary coding was helpful, thank you. Editorial comments: s/might might/might/ s/!@RFC4566/RFC4566/g s/An value/A value/ s/!@RFC8126/RFC8126/ s/material This/material. This/ From nobody Mon Jun 7 19:49:59 2021 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A1A3A1D57; Mon, 7 Jun 2021 19:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 lZSXtSLXDWLe; Mon, 7 Jun 2021 19:49:45 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1383A1D53; Mon, 7 Jun 2021 19:49:41 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1623120574; bh=tFmEwqpuy9i6mvK0pScZFUB6tmDlzt7HkNlh7oSOi8Y=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=F1h3dmQJwVIpNcy0wDUS59BNA4pDwfnlPnPPcgpAscebsEoAlQ7HJSg42O3BCGTbe WrM18r4EB0PVAVPhtx/yCGQHkA0FfgwZ+7xcCGcKJ+44gik+o70Mj9z3Dv8JYhG3BL PDE19MrOos6FSWl/qvFSMEh7YtEbeKKVUKd0vDJw= From: "Paul E. Jones" To: "Russ Housley" , gen-art@ietf.org Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org, last-call@ietf.org, perc@ietf.org Date: Tue, 08 Jun 2021 02:49:28 +0000 Message-Id: In-Reply-To: <162221496687.14173.2319711463541729432@ietfa.amsl.com> References: <162221496687.14173.2319711463541729432@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB2B5A6E2A-E3C6-49A4-B822-ED1E31EF742E" Archived-At: Subject: Re: [Perc] Genart last call review of draft-ietf-perc-dtls-tunnel-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 02:49:50 -0000 --------=_MB2B5A6E2A-E3C6-49A4-B822-ED1E31EF742E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Russ, Thanks for the review. I have made changes as you (and Shawn)=20 suggested. Please see this diff which contains a rewritten security=20 considerations section. Please feel free to comment further since it's=20 quite possible that I created more confusion. I also tried to address your question about the mutual authentication in=20 the security considerations section. https://github.com/percwg/perc-wg/compare/paulej_ietf_lc Paul ------ Original Message ------ From: "Russ Housley via Datatracker" To: gen-art@ietf.org Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org; last-call@ietf.org;=20 perc@ietf.org Sent: 5/28/2021 11:16:06 AM Subject: Genart last call review of draft-ietf-perc-dtls-tunnel-08 >Reviewer: Russ Housley >Review result: Almost Ready > >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 wait for direction from your >document shepherd or AD before posting a new version of the draft. > >For more information, please see the FAQ at >. > >Document: draft-ietf-perc-dtls-tunnel-08 >Reviewer: Russ Housley >Review Date: 2021-05-28 >IETF LC End Date: unknown >IESG Telechat date: unknown > >Summary: Almost Ready > > >Major Concerns: > >Section 9: The document has two different types of keying material: > (1) keys for hop-by-hop encryption and authentication; and > (2) keys for end-to-end encryption and authentication. >The first two paragraphs of Section 9 talks about these two types of >keying material. I think that the discussion should be expanded by a >sentence or two to explain the security consequences of disclosure of >each of theses keying material types. > >In addition, a pointer to the very extensive Security Consideration in >RFC 8871 would he helpful. > > >Minor Concerns: > >Section 5.4 says: "Each TLS tunnel established between the media >distributor and the key distributor MUST be mutually authenticated." >Is this a requirement to use DTLS client authentication? If so, >please be explicit. If not, what other mechanisms for authentication >are expected? > > >Nits: > >Section 5.1, paragraph 2: s/[!@RFC4566]/[RFC4566]/ > >Section 5.5, paragraph 1: > s/MUST utilize the same version/MUST contain the same version/ > >Section 8, last paragraph: > s/section 4.8 if [!@RFC8126]/Section 4.8 of [RFC8126]/ > >Section 9, paragraph 1: > s/keying material This does/keying material. This does/ > > > --------=_MB2B5A6E2A-E3C6-49A4-B822-ED1E31EF742E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Russ,=

Thanks for the review.=C2=A0 I have made change= s as you (and Shawn) suggested.=C2=A0 Please see this diff which contains a = rewritten security considerations section.=C2=A0 Please feel free to comme= nt further since it's quite possible that I created more confusion.

I also tried to address your question about the mutual= authentication in the security considerations section.


Paul

------ Original Message ------
From: "Russ Housley via Datatracker" <noreply@ietf.org>
Sent: 5/28/2021 11:16:06 AM
Subject: Genart last call review of draft-ietf-perc-dtls-tunnel-08

Reviewer: Russ Housley
Review result: Almost Ready
=C2=A0
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 wait for d= irection from your
document shepherd or AD before posting a new vers= ion of the draft.
=C2=A0
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArt= faq>.
=C2=A0
Document: draft-ietf-perc-dtls-tunnel-08
Reviewer: Russ Housley
Review Date: 2021-05-28
IETF LC End Date: unknown
IESG Telechat date: unknown
=C2=A0
Summary: Almost Ready
=C2=A0
=C2=A0
Major Concerns:
=C2=A0
Section 9: The document has two different types= of keying material:
(1) keys for hop-by-hop encryption and authent= ication; and
(2) keys for end-to-end encryption and authent= ication.
The first two paragraphs of Section 9 talks about = these two types of
keying material. I think that the discussion sho= uld be expanded by a
sentence or two to explain the security consequen= ces of disclosure of
each of theses keying material types.
=C2=A0
In addition, a pointer to the very extensive Secu= rity Consideration in
RFC 8871 would he helpful.
=C2=A0
=C2=A0
Minor Concerns:
=C2=A0
Section 5.4 says: "Each TLS tunnel established be= tween the media
distributor and the key distributor MUST be mutua= lly authenticated."
Is this a requirement to use DTLS client authenti= cation? If so,
please be explicit. If not, what other mechanism= s for authentication
are expected?
=C2=A0
=C2=A0
Nits:
=C2=A0
Section 5.1, paragraph 2: s/[!@RFC4566]/[RFC456= 6]/
=C2=A0
Section 5.5, paragraph 1:
s/MUST utilize the same version/MUST contain th= e same version/
=C2=A0
Section 8, last paragraph:
s/section 4.8 if [!@RFC8126]/Section 4.8 of [R= FC8126]/
=C2=A0
Section 9, paragraph 1:
s/keying material This does/keying material. Th= is does/
=C2=A0
=C2=A0
=C2=A0
--------=_MB2B5A6E2A-E3C6-49A4-B822-ED1E31EF742E-- From nobody Mon Jun 7 19:50:50 2021 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081853A1DAC; Mon, 7 Jun 2021 19:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 3xdMiVe1ondq; Mon, 7 Jun 2021 19:50:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39213A1D9A; Mon, 7 Jun 2021 19:50:35 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1623120628; bh=Ffz5fyXLf27OQwkA6fOeiMVYHCy3kPxMoXKkO8dzBGU=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=VndkYpWYL1EhEhTbmAc5kewxRw87FjV4RZP0tJ5QXIVHwCHqOPpJv5dIYGpIahEp9 VoE5CXoT//ZljGIsrYPWJyV2yOLOOj+hwBAGMPPvVpThLz6daLMbUnp0hmq1j15Is7 fDTiYwXUmB55sghiUDpLBQUruRhRSr/XotbJRy+g= From: "Paul E. Jones" To: "Shawn Emery" , secdir@ietf.org Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org, last-call@ietf.org, perc@ietf.org Date: Tue, 08 Jun 2021 02:50:25 +0000 Message-Id: In-Reply-To: <162302724403.5524.7530871359171917876@ietfa.amsl.com> References: <162302724403.5524.7530871359171917876@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1237.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Secdir last call review of draft-ietf-perc-dtls-tunnel-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 02:50:49 -0000 Shawn, Thanks for the review. Russ also had comments on the security=20 considerations section. I have changed that substantially and welcome=20 any additional input. See these changes: https://github.com/percwg/perc-wg/compare/paulej_ietf_lc Paul ------ Original Message ------ From: "Shawn Emery via Datatracker" To: secdir@ietf.org Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org; last-call@ietf.org;=20 perc@ietf.org Sent: 6/6/2021 8:54:04 PM Subject: Secdir last call review of draft-ietf-perc-dtls-tunnel-08 >Reviewer: Shawn Emery >Review result: Not Ready > >I have reviewed this document as part of the security directorate's ongoin= g >effort to review all IETF documents being processed by the IESG. These >comments were written primarily for the benefit of the security area direc= tors. >Document editors and WG chairs should treat these comments just like any o= ther >last call comments. > >This draft specifies a DTLS tunneling protocol for Privacy-Enhanced RTP >Conferencing (PERC). This entails a key exchange between the conference >end-points and the key distributor through a delegate, media distributor. > >The security considerations section does exist and describes that the medi= a >distributor does not introduce any additional security issues given that i= t is >just on-path with the key exchange between the endpoint and the key >distributor. Secondly, the key material between the media distributor and = key >distributor is protected through the mutually authenticated connection bet= ween >the two entities. Thirdly, the meta data exchanged between the media >distributor and key distributor is not sensitive information, but is still >protected through the TLS connection. I agree with the above assertions. >Besides the concerns described in the genart review about the impact of ke= y >material disclosure, the authors should consider the various other forms o= f >security issues against the protocol, such as downgrade/DoS attacks from >profile negotiation, etc. The section could list and simply refer to the= base >RFCs, 5764, 8871, etc., to provide remediation against these attacks. > >General comments: > >The example message flow and binary coding was helpful, thank you. > >Editorial comments: > >s/might might/might/ >s/!@RFC4566/RFC4566/g >s/An value/A value/ >s/!@RFC8126/RFC8126/ >s/material This/material. This/ > > > From nobody Thu Jun 10 21:20:56 2021 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9E83A2760; Thu, 10 Jun 2021 21:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZF-zj0hbOsHF; Thu, 10 Jun 2021 21:20:50 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 D7D933A275F; Thu, 10 Jun 2021 21:20:49 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id he7so2442036ejc.13; Thu, 10 Jun 2021 21:20:49 -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=8wojJE3RIZ/qthvUvqw35TzJqTjCUUUyrs+CDOfLC3U=; b=rqmjXlPLvo5TV0V1WchWIvIAZ6UE/DLV1ZycBjmWVVkv6fJXCrIpZVA+BJSl2+deCR HVY/0N0J5l+cmkyKghKduNtksuxU9TRFFIpTJ0bO5yINtXSPX2p6fowBX6LkJHNqn1/d g5vQggtzEy4pfMq5WrevqxTiuApMqsTNvaTqMRVBwssv/0M5SSsPOYLaYRZmYLHHOA5K 8z3J0kG66jzXjF+pn3O6397f/ScJCWGvpqHDMZDciR4nfthKvoX8OOjf7ioKWt6jdTRI tCVW6Pr4Z+sHbhNx0g2Z2/2lsWNjcXNLmpPED8IJXqa0lVHjiUG9b1WMq2RWBm6PWp3a uQGQ== 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=8wojJE3RIZ/qthvUvqw35TzJqTjCUUUyrs+CDOfLC3U=; b=tsWg+hmTw0mQxqrnzT1TTTlSP6Wjdc1aB9ANRyt9BbKccTbyyH9WqgY6sUblSQ/e62 9hhecGLR5pdrzA/23w/Yw34VFBrnX2rE08fq5qv2TUPOv43oCZUkm+x1wv4K4WrCQ+uc MVQhgZdo0G4JuQ8JwyK22GMuuMuCDmuJ8scgB0DVxM9OLh9P0+gq2GCDWsr+jgcy522k Ka5jQy1jiwV0WAFu3je3e0aGPcmwVsLDqJ4t3gcQvlHbhtcUur0jao6rscpIpM2UtkOu ta3PY6Re6Wb7O+r1Qfks2EGrvD1yFHJHf6n9jgcjsxA/SGEb2qCSfMuqDRKcC3msVUNO sFUQ== X-Gm-Message-State: AOAM530qTlneRS7Y/77/j9ptsduHFBRp/WrfCNIRQqHnQPTpSBD8oiNn y6biJInJhUs1hBzi13syznb9SkQJUJMdeDA9CMS9soCeWTJnrw== X-Google-Smtp-Source: ABdhPJxcKp7cpKtYndvHjMz1394D5kKf+My67Y8jZMxKHIrEHnYYsjzAE54LctPH90nqfUKiE47/hLkH0MhlXsQDFyo= X-Received: by 2002:a17:906:5299:: with SMTP id c25mr1724158ejm.85.1623385242823; Thu, 10 Jun 2021 21:20:42 -0700 (PDT) MIME-Version: 1.0 References: <162302724403.5524.7530871359171917876@ietfa.amsl.com> In-Reply-To: From: Shawn Emery Date: Thu, 10 Jun 2021 18:20:25 -1000 Message-ID: To: "Paul E. Jones" Cc: secdir , draft-ietf-perc-dtls-tunnel.all@ietf.org, last-call@ietf.org, perc@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb6ecb05c475d4a0" Archived-At: Subject: Re: [Perc] Secdir last call review of draft-ietf-perc-dtls-tunnel-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 04:20:55 -0000 --000000000000bb6ecb05c475d4a0 Content-Type: text/plain; charset="UTF-8" Thank you for incorporating the requested changes into the Security Considerations section. Looks better. A few more nits with the latest update: s/the the/the/g s/"EndpointDisconect"/"EndpointDisconnect"/ s/document rely/document relies/ Shawn. -- On Mon, Jun 7, 2021 at 4:50 PM Paul E. Jones wrote: > Shawn, > > Thanks for the review. Russ also had comments on the security > considerations section. I have changed that substantially and welcome > any additional input. See these changes: > > https://github.com/percwg/perc-wg/compare/paulej_ietf_lc > > Paul > > ------ Original Message ------ > From: "Shawn Emery via Datatracker" > To: secdir@ietf.org > Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org; last-call@ietf.org; > perc@ietf.org > Sent: 6/6/2021 8:54:04 PM > Subject: Secdir last call review of draft-ietf-perc-dtls-tunnel-08 > > >Reviewer: Shawn Emery > >Review result: Not Ready > > > >I have reviewed this document as part of the security directorate's > ongoing > >effort to review all IETF documents being processed by the IESG. These > >comments were written primarily for the benefit of the security area > directors. > >Document editors and WG chairs should treat these comments just like any > other > >last call comments. > > > >This draft specifies a DTLS tunneling protocol for Privacy-Enhanced RTP > >Conferencing (PERC). This entails a key exchange between the conference > >end-points and the key distributor through a delegate, media distributor. > > > >The security considerations section does exist and describes that the > media > >distributor does not introduce any additional security issues given that > it is > >just on-path with the key exchange between the endpoint and the key > >distributor. Secondly, the key material between the media distributor > and key > >distributor is protected through the mutually authenticated connection > between > >the two entities. Thirdly, the meta data exchanged between the media > >distributor and key distributor is not sensitive information, but is still > >protected through the TLS connection. I agree with the above assertions. > >Besides the concerns described in the genart review about the impact of > key > >material disclosure, the authors should consider the various other forms > of > >security issues against the protocol, such as downgrade/DoS attacks from > >profile negotiation, etc. The section could list and simply refer to the > base > >RFCs, 5764, 8871, etc., to provide remediation against these attacks. > > > >General comments: > > > >The example message flow and binary coding was helpful, thank you. > > > >Editorial comments: > > > >s/might might/might/ > >s/!@RFC4566/RFC4566/g > >s/An value/A value/ > >s/!@RFC8126/RFC8126/ > >s/material This/material. This/ > > > > > > > > --000000000000bb6ecb05c475d4a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thank you for incorporating the reques= ted changes into the Security Considerations section.=C2=A0 Looks better.= =C2=A0 A few more nits with the latest update:

s/t= he the/the/g
s/"EndpointDisconect"/"EndpointDiscon= nect"/
s/document rely/document relies/

Shawn.
--

On Mon, Jun 7, 2021 at 4:50 PM Paul E. Jones <paulej@packetizer.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Shawn,

Thanks for the review.=C2=A0 Russ also had comments on the security
considerations section.=C2=A0 I have changed that substantially and welcome=
any additional input.=C2=A0 See these changes:

https://github.com/percwg/perc-wg/compare/pa= ulej_ietf_lc

Paul

------ Original Message ------
From: "Shawn Emery via Datatracker" <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org; last-call@ietf.org;
perc@ietf.org
Sent: 6/6/2021 8:54:04 PM
Subject: Secdir last call review of draft-ietf-perc-dtls-tunnel-08

>Reviewer: Shawn Emery
>Review result: Not Ready
>
>I have reviewed this document as part of the security directorate's= ongoing
>effort to review all IETF documents being processed by the IESG.=C2=A0 = These
>comments were written primarily for the benefit of the security area di= rectors.
>Document editors and WG chairs should treat these comments just like an= y other
>last call comments.
>
>This draft specifies a DTLS tunneling protocol for Privacy-Enhanced RTP=
>Conferencing (PERC).=C2=A0 This entails a key exchange between the conf= erence
>end-points and the key distributor through a delegate, media distributo= r.
>
>The security considerations section does exist and describes that the m= edia
>distributor does not introduce any additional security issues given tha= t it is
>just on-path with the key exchange between the endpoint and the key
>distributor.=C2=A0 Secondly, the key material between the media distrib= utor and key
>distributor is protected through the mutually authenticated connection = between
>the two entities.=C2=A0 Thirdly, the meta data exchanged between the me= dia
>distributor and key distributor is not sensitive information, but is st= ill
>protected through the TLS connection.=C2=A0 I agree with the above asse= rtions.
>Besides the concerns described in the genart review about the impact of= key
>material disclosure, the authors should consider the various other form= s of
>security issues against the protocol, such as downgrade/DoS attacks fro= m
>profile negotiation, etc.=C2=A0 The section could list and simply refer= to the base
>RFCs, 5764, 8871, etc., to provide remediation against these attacks. >
>General comments:
>
>The example message flow and binary coding was helpful, thank you.
>
>Editorial comments:
>
>s/might might/might/
>s/!@RFC4566/RFC4566/g
>s/An value/A value/
>s/!@RFC8126/RFC8126/
>s/material This/material.=C2=A0 This/
>
>
>

--000000000000bb6ecb05c475d4a0-- From nobody Fri Jun 11 10:55:13 2021 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDA33A0C49; Fri, 11 Jun 2021 10:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 TxHJi8kaZeWw; Fri, 11 Jun 2021 10:54:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94CD3A0C3C; Fri, 11 Jun 2021 10:54:57 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1623434094; bh=W8S+2aAc8tGPox24RkAR4oooIKJG04G5Kyp/W4ZWG8Q=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=fbGxtqLm5L7gNnJzq9HKMdhNy4KwX4v3zp+5GL4TraE3z22cEeIJuBPVTOVw2f5D3 GVEBtT2W9FvP8zwECx4NQ6g3QDG2+cDEhI+p3aNP2Y+rl67yJV51FuBdp3TROR78WY +ThKr6f8bIRowVaB1bx7+FM7oB+pPmtxKmMgqHLk= From: "Paul E. Jones" To: "Shawn Emery" Cc: secdir , draft-ietf-perc-dtls-tunnel.all@ietf.org, last-call@ietf.org, perc@ietf.org Date: Fri, 11 Jun 2021 17:54:51 +0000 Message-Id: In-Reply-To: References: <162302724403.5524.7530871359171917876@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1473.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB152C625B-E598-4159-8696-D44D7A117755" Archived-At: Subject: Re: [Perc] Secdir last call review of draft-ietf-perc-dtls-tunnel-08 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 17:55:04 -0000 --------=_MB152C625B-E598-4159-8696-D44D7A117755 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks! I fixed those. Paul ------ Original Message ------ From: "Shawn Emery" To: "Paul E. Jones" Cc: "secdir" ;=20 draft-ietf-perc-dtls-tunnel.all@ietf.org; last-call@ietf.org;=20 perc@ietf.org Sent: 6/11/2021 12:20:25 AM Subject: Re: Secdir last call review of draft-ietf-perc-dtls-tunnel-08 > >Thank you for incorporating the requested changes into the Security=20 >Considerations section. Looks better. A few more nits with the latest=20 >update: > >s/the the/the/g >s/"EndpointDisconect"/"EndpointDisconnect"/ >s/document rely/document relies/ > >Shawn. >-- > >On Mon, Jun 7, 2021 at 4:50 PM Paul E. Jones =20 >wrote: >>Shawn, >> >>Thanks for the review. Russ also had comments on the security >>considerations section. I have changed that substantially and welcome >>any additional input. See these changes: >> >>https://github.com/percwg/perc-wg/compare/paulej_ietf_lc >> >>Paul >> >>------ Original Message ------ >>From: "Shawn Emery via Datatracker" >>To: secdir@ietf.org >>Cc: draft-ietf-perc-dtls-tunnel.all@ietf.org; last-call@ietf.org; >>perc@ietf.org >>Sent: 6/6/2021 8:54:04 PM >>Subject: Secdir last call review of draft-ietf-perc-dtls-tunnel-08 >> >> >Reviewer: Shawn Emery >> >Review result: Not Ready >> > >> >I have reviewed this document as part of the security directorate's=20 >>ongoing >> >effort to review all IETF documents being processed by the IESG. =20 >>These >> >comments were written primarily for the benefit of the security area=20 >>directors. >> >Document editors and WG chairs should treat these comments just like=20 >>any other >> >last call comments. >> > >> >This draft specifies a DTLS tunneling protocol for Privacy-Enhanced=20 >>RTP >> >Conferencing (PERC). This entails a key exchange between the=20 >>conference >> >end-points and the key distributor through a delegate, media=20 >>distributor. >> > >> >The security considerations section does exist and describes that the= =20 >>media >> >distributor does not introduce any additional security issues given=20 >>that it is >> >just on-path with the key exchange between the endpoint and the key >> >distributor. Secondly, the key material between the media=20 >>distributor and key >> >distributor is protected through the mutually authenticated=20 >>connection between >> >the two entities. Thirdly, the meta data exchanged between the media >> >distributor and key distributor is not sensitive information, but is=20 >>still >> >protected through the TLS connection. I agree with the above=20 >>assertions. >> >Besides the concerns described in the genart review about the impact=20 >>of key >> >material disclosure, the authors should consider the various other=20 >>forms of >> >security issues against the protocol, such as downgrade/DoS attacks=20 >>from >> >profile negotiation, etc. The section could list and simply refer to= =20 >>the base >> >RFCs, 5764, 8871, etc., to provide remediation against these attacks. >> > >> >General comments: >> > >> >The example message flow and binary coding was helpful, thank you. >> > >> >Editorial comments: >> > >> >s/might might/might/ >> >s/!@RFC4566/RFC4566/g >> >s/An value/A value/ >> >s/!@RFC8126/RFC8126/ >> >s/material This/material. This/ >> > >> > >> > >> --------=_MB152C625B-E598-4159-8696-D44D7A117755 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks!=C2=A0 I fixed = those.

Paul

------ Original Message ------
From: "Shawn Emery" <shawn= .emery@gmail.com>
To: "Paul E. Jones" <paule= j@packetizer.com>
Sent: 6/11/2021 12:20:25 AM
Subject: Re: Secdir last call review of draft-ietf-perc-dtls-tunnel-08=


Thank you for incorporating the requ= ested changes into the Security Considerations section.=C2=A0 Looks better.= =C2=A0 A few more nits with the latest update:

s= /the the/the/g
s/"EndpointDisconect"/"EndpointDisconnect"/
<= div>s/document = rely/document = relies/

Shawn.
--
<= /div>
On Mon, Jun 7, 2021 at 4:50 PM Paul E. Jones <paulej@packetizer.com> wrote:
Shawn,

Thanks for the review.=C2=A0 Russ also had comments on the security
considerations section.=C2=A0 I have changed that substantially and welcome =
any additional input.=C2=A0 See these changes:

https://github.com/percwg/perc-wg/compare/paulej_ietf_lc
Paul

------ Original Message ------
From: "Shawn Emery via Datatracker" <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-= perc-dtls-tunnel.all@ietf.org; la= st-call@ietf.org;
perc@ietf.org
Sent: 6/6/2021 8:54:04 PM
Subject: Secdir last call review of draft-ietf-perc-dtls-tunnel-08

>Reviewer: Shawn Emery
>Review result: Not Ready
>
>I have reviewed this document as part of the security directorate's ong= oing
>effort to review all IETF documents being processed by the IESG.=C2=A0= These
>comments were written primarily for the benefit of the security area di= rectors.
>Document editors and WG chairs should treat these comments just like an= y other
>last call comments.
>
>This draft specifies a DTLS tunneling protocol for Privacy-Enhanced RTP=
>Conferencing (PERC).=C2=A0 This entails a key exchange between the conf= erence
>end-points and the key distributor through a delegate, media distributo= r.
>
>The security considerations section does exist and describes that the m= edia
>distributor does not introduce any additional security issues given tha= t it is
>just on-path with the key exchange between the endpoint and the key >distributor.=C2=A0 Secondly, the key material between the media distrib= utor and key
>distributor is protected through the mutually authenticated connection= between
>the two entities.=C2=A0 Thirdly, the meta data exchanged between the me= dia
>distributor and key distributor is not sensitive information, but is st= ill
>protected through the TLS connection.=C2=A0 I agree with the above asse= rtions.
>Besides the concerns described in the genart review about the impact of = key
>material disclosure, the authors should consider the various other form= s of
>security issues against the protocol, such as downgrade/DoS attacks fro= m
>profile negotiation, etc.=C2=A0 The section could list and simply refer = to the base
>RFCs, 5764, 8871, etc., to provide remediation against these attacks. >
>General comments:
>
>The example message flow and binary coding was helpful, thank you.
>
>Editorial comments:
>
>s/might might/might/
>s/!@RFC4566/RFC4566/g
>s/An value/A value/
>s/!@RFC8126/RFC8126/
>s/material This/material.=C2=A0 This/
>
>
>

--------=_MB152C625B-E598-4159-8696-D44D7A117755-- From nobody Sat Jun 12 17:15:59 2021 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4BF3A26F5; Sat, 12 Jun 2021 17:15:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <162354335430.11910.6365239717334040038@ietfa.amsl.com> Date: Sat, 12 Jun 2021 17:15:54 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-dtls-tunnel-09.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 00:15:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange Authors : Paul E. Jones Paul M. Ellenbogen Nils H. Ohlmeier Filename : draft-ietf-perc-dtls-tunnel-09.txt Pages : 18 Date : 2021-06-12 Abstract: This document defines a DTLS tunneling protocol for use in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the Media Distributor. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-perc-dtls-tunnel-09.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-dtls-tunnel-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 30 09:19:14 2021 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7A03A21B4; Wed, 30 Jun 2021 09:19:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162506995115.9936.13343964913929243021@ietfa.amsl.com> Date: Wed, 30 Jun 2021 09:19:11 -0700 Archived-At: Subject: [Perc] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-perc-dtls-tunnel-09=3A_=28with_COMMENT=29?= X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 16:19:12 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-perc-dtls-tunnel-09: No Objection 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. It is indeed a very valuable set-up. Special thanks for Suhas Nandakumar's shepherd write-up about the WG process / consensus. Please find below one blocking DISCUSS point, some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Sections 3.3, 3.4, and 4.3 -- == COMMENTS == I was about to raise a DISCUSS on this but I am trusting the security AD on this topic. But, I really wonder why TLS 1.2 is used rather than TLS 1.3. There is no operational consideration around the resiliency of the Key Distributor (load balancing, fail-over, etc.). Should there be some operational considerations ? -- Abstract -- While I agree that this document could be informational, why does the abstract use words like "defines" "the protocol is designed" as those words are more normative than descriptive. Strongly suggest to rephrase the abstract. -- Section 1 -- Knowledgeable people will understand the E2E and HBH concepts but a figure would be welcome for beginners (really just a suggestion). Later and in the same vein "simply forwarding packets" for me (INT AD) packets are layer-3 and it is really unclear in the introduction what is actually forwarded. I.e., 'packets' should be qualified, perhaps in "DTLS messages" or using the same vocabulary of section 5.3 ? -- Section 2 -- As usual, I am not comfortable when an informational document relies on BCP 14, which should (IMHO) be reserved for BCP/standards track documents. Just a comment, feel free to ignore. -- Section 5.2 -- "which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document." is really a lot of hand waving as I wonder how the document could be used without knowing which tunnels is to be used. == NITS == There are several occurrences of "an message"... probably a replace all, which went wrong ;-) -- Section 1 -- s/on behalf of the endpoint/on behalf of the endpointS/ ? From nobody Wed Jun 30 13:11:27 2021 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BE93A2931; Wed, 30 Jun 2021 13:11:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <162508387766.24113.5015964775533185016@ietfa.amsl.com> Date: Wed, 30 Jun 2021 13:11:17 -0700 Archived-At: Subject: [Perc] Roman Danyliw's No Objection on draft-ietf-perc-dtls-tunnel-09: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 20:11:22 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-perc-dtls-tunnel-09: No Objection 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Shawn Emery for the SECDIR review, and to Russ Housley for the security related feedback in the GENART review. ** Section 5.4. The Key Distributor MUST match the certificate fingerprint and "external_session_id" received from endpoint's "ClientHello" message with the values received from the SDP transmitted by the endpoint. Consider adding a reference to RFC8122 to point to the guidance on the SDP fingerprint attribute. ** On the topic of relying on the RFC8122 defined hashes, Section 5 allows for the possibility of SHA-1 which is now past its prime. The text there already says “Implementations compliant with this specification MUST NOT use the MD2 and MD5 hash functions to calculate fingerprints or to verify received fingerprints that have been calculated using them.” Likewise, Section 5.1 also notes the requirement of at least one of the hashes being SHA-256. Consider saying sometime along the lines of “Implementations using this tunneling approach SHOULD NOT use SHA-1 hash functions to calculate or verify fingerprints …” From nobody Wed Jun 30 18:33:40 2021 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F093A1277; Wed, 30 Jun 2021 18:33:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162510321507.13724.12968550804927630403@ietfa.amsl.com> Date: Wed, 30 Jun 2021 18:33:35 -0700 Archived-At: Subject: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-dtls-tunnel-09: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 01:33:37 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-perc-dtls-tunnel-09: Discuss 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I want to check on the DTLS version compatibility of this protocol. If there is a DTLS version dependency, as I suspect, then we need to document it more clearly or remove it. In particular, the current specification has the Key Distributor sending the MediaKeys message before it sends the DTLS (server) Finished message (§5.4), which requires that the HBH keys are available at that point. While the TLS exporter interface used by RFC 5764 to output keys is an interface that DTLS 1.3 also supports, that may not be the whole story. In particular, in (D)TLS 1.3 the order of client and server Finished messages is reversed, so that the server Finished is sent before the client has authenticated. When combined with the fact that the TLS 1.3 exporter interface does not incorporate the transcript hash of the client's authentication messages, this seems to imply that the key distributor would be releasing HBH keys prior to the client's authentication and prior to the completion of the DTLS 1.3 handshake. The behavior of the TLS 1.3 exporter was considered safe for regular TLS+TCP since the server will abort the connection and not pass any application data if the client's Finished or authentication is invalid, but it poses problems for applications that use only the TLS handshake and do not use the TLS record protection to cover application data. (EAP-TLS is a notable recent example where the protocol had to be modified in order to be secure when used with TLS 1.3.) DTLS-SRTP is also an application that uses only the (D)TLS handshake, and I am worried that releasing HBH keys prior to authenticating the client will also prove problematic in this situation. (2) I'll also mention here so that the IESG can talk about it during our telechat (but with no intent to insist on a change): this document specifies a versioned protocol and creates a registry. Are we happy with the current Informational status, as opposed to Proposed Standard? I do see that the topic was touched on in the shepherd writeup, but the treatment there did not feel especially compelling to me. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few general remarks before diving into the section-by-section commentary (with nits split off into a final section). It seems like one of the key security-relevant aspects of this setup is how the information in (unauthenticated) incoming DTLS messages at the key distributor are mapped up to the existing (or in the process of establishment?) SDP sessions that describe the expected DTLS session construction (and the media to be carried over DTLS-SRTP). It seems that in the general case, a given Key Distributor will be engaged in many active and pending sessions, and thus will need to be able to look up across many clients and sessions which SDP state might be a match for a given DTLS ClientHello, while avoiding DoS attacks and not committing any given SDP session to a DTLS association prior to the completion of the DTLS handshake. My preference would be to see a lot more discussion in the document about this type of considerations, though for an Informational protocol I won't insist on it (this is a non-blocking comment). With the media distributor acting as an intermediary that is partially trusted, the situation is more complicated than usual, and the key distributor cannot use transport coordinates to identify DTLS associations, and instead the only index available is the UUID assigned by the media distributor. To some extent we rely on the media distributor to properly map DTLS packets to the UUID identifier, but AFAICT if the media distributor fails to do so, the DTLS cryptographic mechanisms will detect such errors and either abort the handshake or (post-handshake) reject invalid messages. It might be worth reiterating that DTLS does provide this form of protection. Since the UUID is the only index that the key distributor has for DTLS associations, there does not seem to be any risk of having the media distributor trick the key distributor into releasing HBH keys from the "wrong" association -- keys should only be released if the DTLS handshake will complete successfully (but see the Discuss point #1!), and the completion of the handshake authenticates the overall exchange so that it's safe to release keys via the channel that identifies the handshake (i.e., the UUID). There does seem to only be very coarsed-grained "trusted or not" authorization for media servers to receive keys at all, though -- a malicious-but-trusted media distributor that had on-path access for some other DTLS flows could relay them to the key distributor and have the DTLS handshake succeed along that path, even if it was not the intended path, and would get the HBH keys as a result. Does it only make sense to use this tunneling protocol with a "DOUBLE" DTLS-SRTP profile? If so, that might be worth mentioning somewhere more explicitly. Section 3 The Key Distributor is a logical function that might be co-resident with a key management server operated by an enterprise, reside in one of the endpoints participating in the conference, or elsewhere that is trusted with E2E keying material. Do we want to say something about the Key Distributor acting at a higher level of trust than the Media Distributor? (Is that even always true?) Section 4 Figure 2 seems to show the MediaKeys being delivered to the Media Distributor after only a single message from the Endpoint (i.e., prior to the completion of the DTLS handshake). I don't think that is accurate, and it seems like that arrow should be moved later in the time sequence. Section 5.4 When processing an incoming endpoint association, the Key Distributor MUST extract the "external_session_id" value transmitted in the "ClientHello" message and match that against "tls-id" value the endpoint transmitted via SDP. If the values in SDP and the "ClientHello" do not match, the DTLS association MUST be rejected. The Key Distributor might have multiple pending associations, and potentially only weak bindings to endpoint identities prior to DTLS establishment, so it's not clear that "match [external_session_id] against 'tls-id' value the endpoint transmitted via SDP" is entirely accurate. I'm implicitly inserting a "the" before "tls-id" to make it parse, but the implicit "the" is not a good fit since the definite article implies there is a single one identified but there may be multiple pending associations. AFAICT at this point in processing the only real identifier that the key distributor has for the pending DTLS association is the UUID from the media distributor and there is no tight association betwen that identifier and the "tld-id" value that (per the following paragraph) is conveyed to the key distributor in some unspecified manner. The Key Distributor MUST match the certificate fingerprint and "external_session_id" received from endpoint's "ClientHello" message with the values received from the SDP transmitted by the endpoint. This sentence is rather confusing to me, since I don't know of a certificate fingerprint conveyed in the ClientHello itself (as opposed to the fingerprint of the certificate contained in the Certificate message presented during the handshake). It is through this process that the Key Distributor can be sure to deliver the correct conference key to the endpoint. Do we need to say anything about how the Key Distributor gets the fingerprint and external_session_id values from SDP? (I mean, I assume that it's the same way that it gets the "tls-id", but the previous paragraph just talked about "tls-id" and not the other stuff, so formally it's ambiguous.) When sending the "ServerHello" message, the Key Distributor MUST insert its own unique identifier in the "external_session_id" extension. This value MUST also be conveyed back to the client via SDP as a "tls-id" attribute. It's not really clear that the binding between the endpoint that is supposedly presenting the DTLS data and the SDP data has been established at all here, so the selection of what "tls-id" to use here feels rather speculative. I think we should discuss the security considerations for what is leaked if the key distributor sends the "wrong" values here... I'm also not sure if the sequencing of events is properly described here. Does the SDP need to complete before the DTLS handshake begins, or can they proceed in parallel as described here? Section 6 Tunnel messages are specified using the format described in [RFC5246] section 4. [...] I think that §3 of RFC 8446 is probably a better reference for TLS presentation language at this point. Section 6.5 I'm not sure what purpose sending an empty dtls_message would serve. * "dtls_message": the content of the DTLS message received by the endpoint or to be sent to the endpoint. I recommend saying something about "including record-layer framing" to reiterate where the boundary is. Section 9 I strongly recommend upgrading the TLS version between media distributor and key distributor to be TLS 1.3. Whether or not to use DTLS 1.2 or 1.3 for the tunneled traffic between endpoint and key distributor is an orthogonal topic. I'd also reiterate that the media distributor has access to metadata about the endpoint/key distributor communications, even though the main content and key information is encrypted. I'd also consider calling out that the media distributor could generate false EndpointDisconnect messages, but that this is essentially the same capability afforded by just not forwarding media anymore. A requirement in this document is that a TLS connection between the Media Distributor and the Key Distributor be mutually authenticated. The reason for this requirement is to ensure that only an authorized Media Distributor receives the HBH keying material. [...] Can we say anything about what the Key Distributor's authorization policy might be, using the authenticated identity of the TLS peer as input? "Any authenticated identity is granted all access" is not a great authorization policy :) NITS Abstract This document defines a DTLS tunneling protocol for use in multimedia I think the hyphenated "DTLS-tunneling" would clarify that DTLS is being tunneled (as opposed to the mechanism used to tunnel other things). A slightly more intrusive change would be "protocol for tunneling DTLS traffic" but that might be confusing in the terse setting of the Abstract. Section 1 By establishing this TLS tunnel between the Media Distributor and Key Distributor and implementing the protocol defined in this document, it is possible for the Media Distributor to facilitate the establishment of a secure DTLS association between an endpoint and the Key Distributor in order for the endpoint to receive E2E and HBH keying material. [...] I think "receive" might not be the best word here, since the key material should incorporate contributions from both parties; the "arrive at" language used in the previous paragraph was good. Section 4 As DTLS messages are received from the endpoint by the Media Distributor, they are forwarded to the Key Distributor encapsulated inside a "TunneledDtls" message. Likewise, as "TunneledDtls" messages are received by the Media Distributor from the Mey Distributor, the encapsulated DTLS packet is forwarded to the endpoint. s/Mey/Key/ Section 5.1 The endpoint MUST include a unique identifier in the "tls-id" SDP [RFC4566] attribute sent by the endpoint in both offer and answer [RFC3264] messages as per [RFC8842]. Further, the endpoint MUST include this same unique identifier in the "external_session_id" extension [RFC8844] in the "ClientHello" message when establishing a DTLS association. Since this is the section about the endpoint procedures (the key distributor's behavior is discussed later), I think we might avoid phrasing that implies a linked offer/answer pair, and instead say something like "in all offer and answer messages that it generates". Section 5.4 The Key Distributor MUST encapsulate any DTLS message it sends to an endpoint inside a "TunneledDtls" message (see Section 6). The Key Distributor is not required to transmit all messages a given DTLS association through the same tunnel if more than one tunnel has been established between it and a Media Distributor. I suggest "a given Media Distributor", since the current phrasing seems to allow sending to a different media distributor entirely, which seems unlikely to work since the UUID identifying the DTLS association will not be recognized there. The Key Distributor MUST select a cipher that is supported by both the endpoint and the Media Distributor to ensure proper HBH operations. (It also has to pick a cipher that it itself supports...) Section 5.5 "UnsupportedVersion". The Media Distributor can determine from the first two octets received what the version number is and that the message is "UnsupportedVersion". The rest of the data received, if I think that the "two" should be either "one" or "four", as the actual message structure has two octets of length between the message type and the unsupported_version structure. One octet is needed to determine that it is an unsupported-version message, and four to determine the highest supported version number. Section 6.2 struct { uint8 version; SRTPProtectionProfile protection_profiles<0..2^16-1>; } SupportedProfiles; The presentation language allows an empty list of profiles; is that intended to be allowed? (What happens if an empty list is sent?) * "version": indicates the version of the protocol to use (0x00). I suggest "this document specifies version 0x00" rather than the parenthetical. From nobody Wed Jun 30 22:28:34 2021 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 047533A1157; Wed, 30 Jun 2021 22:28:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <162511730799.13937.4318987620511163024@ietfa.amsl.com> Date: Wed, 30 Jun 2021 22:28:28 -0700 Archived-At: Subject: [Perc] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-perc-dtls-tunnel-09=3A_=28with_COMMENT=29?= X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 05:28:28 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-perc-dtls-tunnel-09: No Objection 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Fixing a cut&paste error] Thank you for the work put into this document. It is indeed a very valuable set-up. Special thanks for Suhas Nandakumar's shepherd write-up about the WG process / consensus. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I was about to raise a DISCUSS on this but I am trusting the security AD on this topic. But, I really wonder why TLS 1.2 is used rather than TLS 1.3. There is no operational consideration around the resiliency of the Key Distributor (load balancing, fail-over, etc.). Should there be some operational considerations ? -- Abstract -- While I agree that this document could be informational, why does the abstract use words like "defines" "the protocol is designed" as those words are more normative than descriptive. Strongly suggest to rephrase the abstract. -- Section 1 -- Knowledgeable people will understand the E2E and HBH concepts but a figure would be welcome for beginners (really just a suggestion). Later and in the same vein "simply forwarding packets" for me (INT AD) packets are layer-3 and it is really unclear in the introduction what is actually forwarded. I.e., 'packets' should be qualified, perhaps in "DTLS messages" or using the same vocabulary of section 5.3 ? -- Section 2 -- As usual, I am not comfortable when an informational document relies on BCP 14, which should (IMHO) be reserved for BCP/standards track documents. Just a comment, feel free to ignore. -- Section 5.2 -- "which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document." is really a lot of hand waving as I wonder how the document could be used without knowing which tunnels is to be used. == NITS == There are several occurrences of "an message"... probably a replace all, which went wrong ;-) -- Section 1 -- s/on behalf of the endpoint/on behalf of the endpointS/ ?