Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp-assurance [was: Re: IETF 117 - do you have something for DISPATCH?]

Roman Shpount <roman@telurix.com> Tue, 15 August 2023 15:18 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83518C151987 for <mmusic@ietfa.amsl.com>; Tue, 15 Aug 2023 08:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN2Ww-5s6Zoa for <mmusic@ietfa.amsl.com>; Tue, 15 Aug 2023 08:18:20 -0700 (PDT)
Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D32C151553 for <mmusic@ietf.org>; Tue, 15 Aug 2023 08:18:20 -0700 (PDT)
Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-56e0bd33797so2059943eaf.0 for <mmusic@ietf.org>; Tue, 15 Aug 2023 08:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; t=1692112699; x=1692717499; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P2H1gq77Uh8X1RGJuEgPD91hOCaFSBWXEHugLhUtzKg=; b=YtbrZm2SWvtooZAJK0RVx9tJ0sjsK7PqegO+nvyzOlP33BwJIiXRG49PHjb1JcDA5w D11O9NFSXO/Sn5KccDW1vsJgph673Pn3R420K4U2WwOhnXtyjB3fOuiGC87HJ/v9Rl+1 sYZsSPOA5zZIV68tV5EteAFsCZzD1vzDzegTs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692112699; x=1692717499; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P2H1gq77Uh8X1RGJuEgPD91hOCaFSBWXEHugLhUtzKg=; b=dWv8r21zGprIm1i7Fg/vKkBYXU33N8DNr1WOUuuLrmBEm9ysglexJ+0tdxsWsU9H4x RaWwv7cU9ZCy4pkkBOiq8br0esyI0pJx9+EGiv4ZNSEFLMr4xhHIDHIgLndxhnhDtzlv mdZvbNfKxQE7tOX9n+ohJc2weUvJ0BjLFqmrMxQYVTkjXO++ymAX8Ap/rox5brrubNrv D8yMjWf+Ej7NjfctXmdn4hBCmviHF5rC1wQUtC+u3kAQy9lfFTOyS0YDPIJ3rsH9Bhe6 XKPxrktFWZZ52xaqm7x7ToHmWXtJgH1BtpDa8LigkSxkdGM3Da3CeEnea1Jx1bNqYUwG VpKg==
X-Gm-Message-State: AOJu0YwTgWH2puBSSL05y/vCSh5jOxlaSy5zsbrl1H4vNELlx9cVeCP0 vUHyE1USvNVzdq6taZdOL/OUJw==
X-Google-Smtp-Source: AGHT+IH+VKrqMFWg884mbuVxI9o4LEKb/fCu+liZvociZZfkHaAzzdDQFLFCInCPXNlsOSM9su9aOw==
X-Received: by 2002:a4a:7648:0:b0:56c:7120:8361 with SMTP id w8-20020a4a7648000000b0056c71208361mr11503038ooe.4.1692112699183; Tue, 15 Aug 2023 08:18:19 -0700 (PDT)
Received: from mail-oo1-f51.google.com (mail-oo1-f51.google.com. [209.85.161.51]) by smtp.gmail.com with ESMTPSA id r128-20020a4a4e86000000b005678320f1f2sm5775925ooa.13.2023.08.15.08.18.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Aug 2023 08:18:18 -0700 (PDT)
Received: by mail-oo1-f51.google.com with SMTP id 006d021491bc7-56d6879dcaaso4019035eaf.3; Tue, 15 Aug 2023 08:18:18 -0700 (PDT)
X-Received: by 2002:a4a:9d57:0:b0:56e:14b7:b053 with SMTP id f23-20020a4a9d57000000b0056e14b7b053mr7271330ook.7.1692112698481; Tue, 15 Aug 2023 08:18:18 -0700 (PDT)
MIME-Version: 1.0
References: <0490249B-C51B-4E18-8155-144CE044E994@gmail.com> <PH0PR11MB50293AD3FEDA894B9B2D3041BB3BA@PH0PR11MB5029.namprd11.prod.outlook.com> <2DEC9659-A76A-4D33-ADDE-CDB7D5E5EBED@brianrosen.net>
In-Reply-To: <2DEC9659-A76A-4D33-ADDE-CDB7D5E5EBED@brianrosen.net>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 15 Aug 2023 11:18:05 -0400
X-Gmail-Original-Message-ID: <CAD5OKxuoowrzZ79gUm8t7mOgPybF__VUaF4we_MN=XWmZS9uHg@mail.gmail.com>
Message-ID: <CAD5OKxuoowrzZ79gUm8t7mOgPybF__VUaF4we_MN=XWmZS9uHg@mail.gmail.com>
To: Brian Rosen <br=40brianrosen.net@dmarc.ietf.org>
Cc: "Kyzer Davis (kydavis)" <kydavis=40cisco.com@dmarc.ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005024030602f7b020"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/VsH0Giu28BAj_ZfoBfEKlUGzQWY>
Subject: Re: [MMUSIC] [dispatch] draft-davis-valverde-srtp-assurance [was: Re: IETF 117 - do you have something for DISPATCH?]
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Aug 2023 15:18:25 -0000

Hi Brian,

Many people promote DTLS-SRTP, but DTLS-SRTP is not a fully featured
replacement for SDES-SRTP. The problem with DTLS-SRTP is it cannot reuse
the same pair of 5-tuples for two different sessions. To deprecate
SDES-SRTP, DTLS-SRTP should be enhanced to handle two DTLS handshakes over
the same transport address and a mechanism to associate these handshakes
with SSRC. DTLS-SRTP negotiation was patched up to work with WebRTC, but it
will not work for all the scenarios where SDES-SRTP is used. Without the
standard update, the most likely result of the DTLS-SRTP regulatory
requirements for Next Gen 9-1-1 would be that emergency calls will be
dropped. Also, considering the external dependency on TLS, I don't think
MMUSIC can add the required functionality on its own.

Best Regards,
_____________
Roman Shpount


On Tue, Aug 15, 2023 at 11:02 AM Brian Rosen <br=
40brianrosen.net@dmarc.ietf.org> wrote:

> A piece of info that might affect the discussion of prolonging SDES vs
> DTLS-SRTP.
>
> In the US, the regulator announced an intention to require all carriers,
> including VoIP carriers to support “Next Generation 9-1-1” signaling.  That
> requires SIP with DTLS-SRTP.  The emergency call service side does not
> support SDES.  Of course, security is hop by hop, and nearly every carrier
> anchors media, so the DTLS-SRTP connection is likely from the carrier’s SBC
> to the emergency services SBC, and the phone could still support SDES, but
> it’s another nail in the SDES coffin.
>
> I would be opposed to enhancing SDES.  Implementing this draft would
> require code changes in the device that needed it.  I would prefer those
> changes implement DTLS-SRTP.  While I do recognize that the magnitude of a
> change to implement DTLS-SRTP, with EKT-SRTP would be much greater than
> implementing this draft on a device that implemented SDES, a change is a
> change, and I think the security of DTLS-SRTP is so much better than SDES,
> that I believe we should not encourage continuing deployment of SDES.
>
> Brian
>
>
>
> On Jul 17, 2023, at 5:09 PM, Kyzer Davis (kydavis) <kydavis=
> 40cisco.com@dmarc.ietf.org> wrote:
>
> Hello Dan,
>
> I reached out to the MMUSIC chairs (along with AVTCORE Chairs and Dispatch
> chairs CC’d)
> MMUSIC felt like it belonged but still wanted the dispatch time since
> there is no MMUSIC meeting at 117.
>
> To address a few other statements:
>
> > I would like to understand where EKT-SRTP (RFC8870) fails to meet needs.
>
> I think EKT-SRTP does a great job. That is, if we are using DTLS-SRTP. I
> am only aiming to do the same for SDP Security (SDES).
>
> > I would rather see RFC8870 extended to work with SDP Security
> Descriptions because it moves us on a path towards DTLS-SRTP:
>  DTLS-SRTP-signaled endpoints could interop with SDP Security
> Descriptions-signaled endpoints because they're both using EKT to handle
> SSRC/ROC and key changes when group membership changes.
> I believe you are referencing the act of an SBC/B2BUA interoperating SDP
> Security and DTLS-SRTP w/EKT?
> I found some older EKT-SRTP drafts that I think are the topic:
> https://www.ietf.org/archive/id/draft-mcgrew-srtp-ekt-06.html#anchor6
> https://www.ietf.org/archive/id/draft-mcgrew-srtp-ekt-06.html#anchor21
>
> One point discussed in there was “SDP Security Descriptions however does
> not negotiate SSRCs and their associated Rollover Counter (ROC). Instead,
> SDES relies on a so-called "late binding", where a newly observed SSRC will
> have its crypto context initialized to a ROC value of zero. Clearly, this
> does not work for participants joining an SRTP session that has been
> established for a while and hence has a non-zero ROC.”
>
> If that is the point then I agree; having the SSRC, ROC, SEQ in SDES/SDP
> security could allow for an intermediary to easily interwork
> SDES<>DTLS-EKT-SRTP.
> Note: I would need to audit EKT-SRTP to see if there is anything else SDES
> is missing that could help that Key Management Interworking.
>
> > We really should be deprecating SDP Security Descriptions because it has
> far worse security properties compared with DTLS-SRTP.
> I also know SDP as a means for conveying keying material for SRTP isn't
> exactly the best method in the grand scheme when compared to the other
> available options.
> That being said, there are many millions of devices across different
> vendors still using SDP Security as the SRTP key management protocol.
> Further, I continue to see more modern internet telephony service
> providers providing TLS SIP w/SRTP via SDES and the acceleration of cloud
> registered SIP endpoints utilizing SDP Security.
> Ignoring the problem that could positively affect so many does not seem
> like the right thing to do.
>
> Other:
> I started an audit of various enterprise, cloud and service provider
> offerings to compare MIKEY, DTLS-SRTP, EKT-SRTP, and SDP Security but I
> will not be able to finish this by the time for dispatch so I have dropped
> the slide. I can create a wiki page on the drafts GitHub if the group wants
> to help crowdsource a “Current State of SRTP Key Management Protocol
> offerings in 2023”. Similarly, if a similar study already exists I would
> love to give it a read.
>
> Lastly, I have a WIP draft-01 which provides an alternative solution to
> draft-00’s a=srtpctx SDP attribute.
> The alternative solution reuses the sdp security session parameter postfix
> options to convey SSRC, ROC, SEQ.
>
> https://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xhtml#sdp-security-descriptions-4
> I plan to have a slide on both solutions for the dispatch discussion.
>
> Thanks,
>
> *From:* Dan Wing <danwing@gmail.com>
> *Sent:* Monday, July 17, 2023 3:41 PM
> *To:* dispatch@ietf.org
> *Cc:* Kyzer Davis (kydavis) <kydavis@cisco.com>; Robert Sparks <
> rjsparks@nostrum.com>; mmusic@ietf.org
> *Subject:* draft-davis-valverde-srtp-assurance [was: Re: [dispatch] IETF
> 117 - do you have something for DISPATCH?]
>
> Yeah, it feels like draft-davis-valverde-srtp-assurance could go straight
> to MMUSIC.
>
> The I-D needs to discuss what happens when SSRC collision occurs, which I
> think is "send new SDP indicating the new SSRC and ROC=0".
>
> I would like to understand where EKT-SRTP (RFC8870) fails to meet needs.
> The design of EKT-SRTP avoids signaling SSRC or ROC in the signaling
> channel and, instead, allow them both to be indicated in the SRTP channel
> itself.  This design allows SSRC collisions to be handled very much like
> how they are handled with RTP (that is, without the "S").  I would rather
> see RFC8870 extended to work with SDP Security Descriptions because it
> moves us on a path towards DTLS-SRTP:  DTLS-SRTP-signaled endpoints could
> interop with SDP Security Descriptions-signaled endpoints because they're
> both using EKT to handle SSRC/ROC and key changes when group membership
> changes.  We really should be deprecating SDP Security Descriptions because
> it has far worse security properties compared with DTLS-SRTP.
>
> -d
>
>
>
> Hi Kyzer (et. al.) -
>
>
>
> Why aren't you taking this straight to mmusic? Am I missing something
>
> that says that's not the obvious place for the work?
>
>
>
> RjS
>
>
>
>
>
> On 6/27/23 7:31 AM, Kyzer Davis (kydavis) wrote:
>
> >
>
> > Hello,
>
> >
>
> > I would like to request a bit of dispatch time for the draft just posted:
>
> >
>
> > https://datatracker.ietf.org/doc/draft-davis-valverde-srtp-assurance/
>
> >
>
> > I also plan to attend IETF 117 in person to represent.
>
> >
>
> > Thanks,
>
> >
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>