Re: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)

Philipp Hancke <philipp.hancke@googlemail.com> Mon, 18 March 2024 13:42 UTC

Return-Path: <philipp.hancke@googlemail.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 795F2C151539 for <mmusic@ietfa.amsl.com>; Mon, 18 Mar 2024 06:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, RCVD_IN_DNSWL_HI=-5, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 gDlSXe3OdoO4 for <mmusic@ietfa.amsl.com>; Mon, 18 Mar 2024 06:42:53 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 35BFDC15109D for <mmusic@ietf.org>; Mon, 18 Mar 2024 06:42:53 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a466f796fc1so553656266b.3 for <mmusic@ietf.org>; Mon, 18 Mar 2024 06:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1710769371; x=1711374171; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CjrmP+mdGB6ujzizb36ln9KLb8qb/+zD5xY0j4vFdUo=; b=hyPtwxYfJfuiTRTsc0oH07uhiJgAOCxVPavMBOL4VolbTzXzr4SmCx/6bMfdL6Q9Ji 59FxcxIqbHjcivZgUhGPWM2Sxp3Bhvp+EUVT9SYVuVekg0N9Fi0aMQ1zoN4CDMM0R7zZ w+5Fv965AEqefi8oWbLheWPRwfXBEHV+nl0aB4s0bhpWjHLuFwamfE7z2l6fTkzwWUkz GlK4CyLsO9mbjKuCgbl77FpoVOXY2hlqmVcjdjUmFlEjU6JNI9qUtOS5OvvT68c3VJT7 +Fe4fRW4lsWIRFClIDolTWDkObfHwR04T2XdJRc4a2Uo+0FnkT/C5RaejdBx5OsFoJCU b6DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710769371; x=1711374171; 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=CjrmP+mdGB6ujzizb36ln9KLb8qb/+zD5xY0j4vFdUo=; b=jV/It7PBw6Tr7o39nj+fN83MwtgUIZEYM1DrMQi3dsBlm+F1AXugKMZE8tAFdLpImM nHK16r/17CChQPYbt41pl2C5gE079PB4VaFLUxHLx49/UU0IM41A8D30j1Tpocy4SaUJ 3m7rLgFAKhJX1hl38nhqaxF8s24j7uKL4khMYE7JzntnUMQa23Sm4pMyrqi6umBJ6MJX 6d65XFZrZQ/Fniz2TYNfyBvaKSLGBXJMX8IqpPuVWWEctXZPFC5X7YJQ8pc07/ZK/sc3 pzuerhs5obnsIdmg7Q0t+MwI/6Gy2vJ3dXvXdQrlhFq3lqeIjQ9yXaeeCXA5MpkGXy1m I+pA==
X-Gm-Message-State: AOJu0YwuLw7Ya83CKfneerrg1qiPLls/zxEX6WtrdoBwxSOYw1Po/ThL kknVThU8r1N5vWmfLMArVArKIzz/opedeTE8Tg02/yD1RUDvV+Ck6lZX9gScWJU2CA0vR5tHxIu GKrCzQXygRxXgv7uK7tpxi+kDLNs=
X-Google-Smtp-Source: AGHT+IFJUabPP19IgiiKHMPtAE1lbI1AI+xkEHa4WekJZmqCVFmvKsV3Cgqh0n0CxJvyUEahvJlz/nxqefxDmYgRtcI=
X-Received: by 2002:a17:906:1c4e:b0:a46:7e07:e66f with SMTP id l14-20020a1709061c4e00b00a467e07e66fmr6124808ejg.0.1710769371187; Mon, 18 Mar 2024 06:42:51 -0700 (PDT)
MIME-Version: 1.0
References: <6d597607-fb07-a637-d6c3-a6084186e4e0@alvestrand.no> <2015efd9-78f5-4fc7-f889-fa44f95fdfa9@alvestrand.no> <CADxkKiLZG2ipczF+vzv_DXfjLf6pYdFqM76HfoBefQt2ewQPXA@mail.gmail.com> <HE1PR07MB4441AAD8236705F4DD85BB1E9326A@HE1PR07MB4441.eurprd07.prod.outlook.com> <CAL0qLwa2og3SXvzYbeUZP_KofyQxtCuXF9_wZvEK3WDkjpz2PQ@mail.gmail.com>
In-Reply-To: <CAL0qLwa2og3SXvzYbeUZP_KofyQxtCuXF9_wZvEK3WDkjpz2PQ@mail.gmail.com>
From: Philipp Hancke <philipp.hancke@googlemail.com>
Date: Mon, 18 Mar 2024 06:42:39 -0700
Message-ID: <CADxkKiLZcaov0TYXwstPtuR4sqhep8TJPC=+MzFtEMhwFJLQ8g@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a991330613ef8849"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/iXDLEsrm5HA0lrZMX3QfZlwhQqI>
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5576 (7544)
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: Mon, 18 Mar 2024 13:42:57 -0000

not rejecting duplicate SSRCs lead to a series of security issues for
libWebRTC (CVE-2023-4076 is the only one which got a proper number) which
were embargo'd at that time but have since been opened up:
https://issues.chromium.org/issues/40065816 (the original issue with RTX
ssrc being the same as the primary one)
https://issues.chromium.org/issues/40066610 (duplicates across m-lines make
this so much more fun)
https://issues.chromium.org/issues/40070891 (using a google-proprietary
ssrc-group so a problem for Harald ;-)

Given those issues existed for a decade without being found (even by a
fuzzer) it would be good to raise awareness at least.


Am So., 17. März 2024 um 23:07 Uhr schrieb Murray S. Kucherawy <
superuser@gmail.com>:

> (going through some old errata reports that weren't finalized)
>
> On Mon, Jun 26, 2023 at 6:02 PM Christer Holmberg <christer.holmberg=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
>> >I do not think it is being used in production, in particular since for
>> FID
>>
>> >https://www.rfc-editor.org/rfc/rfc4588#section-4
>>
>> >already says two different SSRC values MUST be used for the original
>> stream and the retransmission stream
>>
>> >I don't see the same explicit text in RFC 5956 (for FEC-FR) sadly.
>>
>>
>>
>> RFC 5956 does, however, say that all SSRC values within an RTP session
>> must be unique. So, that implicitly means you cannot use identical SSRC
>> values for different flows, which means you would not have multiple
>> instance of the same SSRC value within an ssrc-group.
>>
>
> I take it this one should be rejected?
>
> -MSK
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>