Re: [AVTCORE] Review of draft-engelbart-rtp-over-quic (David Schinazi)

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 25 May 2022 19:33 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2C8C07B7AC for <avt@ietfa.amsl.com>; Wed, 25 May 2022 12:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXHDC9HIjT5o for <avt@ietfa.amsl.com>; Wed, 25 May 2022 12:33:07 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 1892DC07B7A7 for <avt@ietf.org>; Wed, 25 May 2022 12:33:07 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id f11so1808551qvs.9 for <avt@ietf.org>; Wed, 25 May 2022 12:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ymK1RSNo2FzyW+c8687j477EOiUsvM+sQ2tap8Gqbco=; b=NETLyS/t2DU6NNHJIs+hdU3VSQ9niVnbVhqreo8GHpMbM9pwlgTrDv9uBXh/kGsXjU klsuAd1m83igsDKudzBtqhiTSK7ztKhDxvCFqoKL2b6puBEEqGnsMhtZrVHYdvgEvHDC Xnhjz8W6wG5ZCSAtYE28lZihzXmpbTV0FHYLUcqKaQyRl7XAnai1xEVCMqIYAtwk6O0Q AqSd65fJKhf90WvT1piok69JvZfGVAO1P6C69z8Eo3roU2KhCci64r5N8hmv+qEzLMuV aaWjfkTSWOUIo8DN4k/PX0d8IPNz0p4EqZgu6hd8tRUtbh46mJvzM+m2TTZt51FiRdQF fV6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ymK1RSNo2FzyW+c8687j477EOiUsvM+sQ2tap8Gqbco=; b=qvek/Z/HRCC31mGiD1NGskZFKjZ+9ayJ2M8XamCeANmKa+zJD4IVhh9gjVTUIQEKqc uLxaN3UVhl21h12iLq6sigIkwCx1s9JJK86AR1jabcQjj+1rbQqTNhA09dZw2aXAF7QO i6WOdAZxBCkGcgSqX72rMv9qLVh/AC1X11/d0L33XeHpa8+dbnmmw9TSHK5OrMgU2loR FdLoEI/sFLgqAhxqoxnNNWoPrn8tqgRvqeMOsZKXslTbTYGw1EtlRoBT6Vo74T5oVV/1 VRfJZoSD/SVlq+NYOguwCM3/2MHRdv616FnsMceJpVluarb9KpeGbP1E8veRH8e79c07 sO8g==
X-Gm-Message-State: AOAM533zzhkwukykOnBy3w3VILqEllNpv9C3V0wOtqwpuyXnVnGGOedA sWBJtgGyj8DlQShQBCYAPTclLcRrjDb3c8xkID4=
X-Google-Smtp-Source: ABdhPJwHrF4cYyV2E3R+qlupPQWFbPdmPL5L7KYFD4vd+2cHpzJLZXrg8AlRN0STw6QsiDcLJ+UMut8JzJn1e20X6ds=
X-Received: by 2002:ad4:5d66:0:b0:462:eaa:67f with SMTP id fn6-20020ad45d66000000b004620eaa067fmr23155889qvb.72.1653507185914; Wed, 25 May 2022 12:33:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW+2duZuSb_w2jAARmPYq0O0b4fYGtMtbPWAYxZDf8r-q=Cng@mail.gmail.com> <a75e4d70-b11e-d5a0-ce19-ce90bf8f2a84@in.tum.de>
In-Reply-To: <a75e4d70-b11e-d5a0-ce19-ce90bf8f2a84@in.tum.de>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 25 May 2022 20:32:54 +0100
Message-ID: <CALGR9oY2jQuKvE_ES=_kb7XoQ6KCoxJtoyc0VdAZ4P-L4QT3Gg@mail.gmail.com>
To: Joerg Ott <ott@in.tum.de>
Cc: Bernard Aboba <bernard.aboba@gmail.com>, IETF AVTCore WG <avt@ietf.org>, Mathis Engelbart <mathis.engelbart@tum.de>, David Schinazi <dschinazi@apple.com>
Content-Type: multipart/alternative; boundary="00000000000073387d05dfdb24cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/NhGfpSl6yPmje5la46mnNfKqfqk>
Subject: Re: [AVTCORE] Review of draft-engelbart-rtp-over-quic (David Schinazi)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2022 19:33:10 -0000

Hi Joerg, David,

I don't have a strong stake in the upper L7 matters but FWIW

RFC 9000 section 7 says: "The cryptographic handshake MUST provide ..
authenticated negotiation of an application protocol (TLS uses
Application-Layer Protocol Negotiation (ALPN) [ALPN
<https://www.rfc-editor.org/rfc/rfc9000.html#ALPN>] for this purpose)"
RFC 9001 section 8.1 says: "QUIC requires that the cryptographic handshake
provide authenticated protocol negotiation. TLS uses Application-Layer
Protocol Negotiation [ALPN] to select an application protocol. Unless
another mechanism is used for agreeing on an application protocol,
endpoints MUST use ALPN for this purpose."

The QUIC implementations I'm familiar with will enforce these requirements.
So for anyone writing an application mapping that expects interop, that
really do need to explicitly define _an_ ALPN identifier OR state what
exactly the alternative mechanism is.

Cheers,
Lucas