Re: [Sframe] Negotiating SFrame/RTP in SDP

Bernard Aboba <bernard.aboba@gmail.com> Thu, 02 September 2021 21:11 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9913A112F for <sframe@ietfa.amsl.com>; Thu, 2 Sep 2021 14:11:51 -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 XY5lhGoBJKDY for <sframe@ietfa.amsl.com>; Thu, 2 Sep 2021 14:11:46 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 58AC63A112C for <sframe@ietf.org>; Thu, 2 Sep 2021 14:11:46 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id m28so7266733lfj.6 for <sframe@ietf.org>; Thu, 02 Sep 2021 14:11:46 -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=6jU6qX7jppQcT49j6cCprlTOLlauIDRDQpUzX24bgJI=; b=Aq0xAk0w+evm9QTmBNYJ+8ovLQCK63BOE9+DDaTQ2hckQ4b9gpF/92qdfnSkkULIAL 3phwAON4c53gqhLcLIPOwY1vDNJog9IAZHA15hr0bB65jEhit7yDOs31flfCJDgoLaN2 wF/VczHK+MK5xJWuZngRlzW7216N7EAv0MIoS1E9sOVYBvWF22OSdSx67F6vULspTmtL O1Xqf+wtFZdH4dENI7NUqJH0wLStxI/6w0E55U0HROAqgjwIbvYhLRqInJSV8P//vN4/ jPRKwlfJnt2IR0wLLH5a035Sa6cHW79qX7dwiCbC1WbDbZt7PrAZB6fkcdg7hR+Q6NGP dupw==
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=6jU6qX7jppQcT49j6cCprlTOLlauIDRDQpUzX24bgJI=; b=q6zAk8cCL5zEetNHaGoaVVejZB48Ka03auhaIF5vCmg/InYZcV/nxSrxbGosDFeUIj 4cyLn9xo55m632dmWTOgHcZnEqdOw/5twP9bGtDybqdmxf/uF4HUnXSc5runpgFRUABF byNXwnSjeRQ2dB+t7JvmUtA4qA7AHyVnxFUuA4S493gNTGUcXXOuLHNXM+evV1aMXI5q LZTT+RMRqGch2s5nUzOzcd1uf1FRG8TmNkrlo2zTbVYnCZJ6Vq4fhviVDpwT7kqUuPbV Oos36ez7FVQRKUcXlHPozUHcSj3OQpapZPzOnl+Rkfg+bgr2mNNSEO/yTIQrBw8+EGR2 XLqQ==
X-Gm-Message-State: AOAM533DV3Aa/23j0IZXSmIjrdOFNX4oyLAzBY97L94MT2kZEjTV3X3m aNvQKY5IZEr6mNZRNN3RFS46ojAdw0ulIr91eKre8lKK
X-Google-Smtp-Source: ABdhPJxycep4WUGtAyYoC+bmh6FBQjGcf2RH9TENU4MT5i1cvuP3w/DMcxHMzON0LFPvF6697iZqC148LcTklALswAI=
X-Received: by 2002:a05:6512:31e:: with SMTP id t30mr123503lfp.218.1630617102331; Thu, 02 Sep 2021 14:11:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAL02cgRw3OASDfqcywU1b=S+K9QDA=iJ-Pa+4uTUE--Cui5m6g@mail.gmail.com>
In-Reply-To: <CAL02cgRw3OASDfqcywU1b=S+K9QDA=iJ-Pa+4uTUE--Cui5m6g@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 02 Sep 2021 14:11:31 -0700
Message-ID: <CAOW+2dvKGVnoDdFMc1_So0sQfk64z5AkorPF2qJ57_8_mzKOBA@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: sframe@ietf.org
Content-Type: multipart/alternative; boundary="00000000000026332805cb09a147"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/jLY0bJl441kpdwmLqWntUqte6to>
Subject: Re: [Sframe] Negotiating SFrame/RTP in SDP
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Media Frames <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2021 21:11:52 -0000

On Thu, Sep 2, 2021 at 13:23 Richard Barnes <rlb@ipv.sx> wrote:

>
> Personally, I think the proposal in Sergio's draft is a little wide of the
> mark.  ISTM that specifying a "generic" media format and recovering the
> specificity in an RTP header is more complex than is needed. Worse, it sets
> up implementations to send the same media both encrypted and unencrypted --
> obviously not great for security.
>
> I'd like to propose a simpler approach, drawing inspiration from cryptex
> [3]:
>
> a=sframe:<frame|packet> [<keying>]
>
> Basically, just a new SDP attribute per m-line, that specifies that SFrame
> encryption is being done and how.  The desired semantic is clear for SPacket
>

[BA] My assumption is that an a= line in the Offer means “I desire to send
encrypted media, and can also receive it”. Is that your understanding?  If
a corresponding a=line is provided in the Answer does this mean “I will
send encrypted media and will expect to receive encrypted media” so that
clear text media won’t be sent in either direction?  Is there an
expectation that all BUNDLED m lines have the same settings, or can they be
different?

The desired semantic is clear for SPacket: Just add an SFrame
> protect/unprotect
>

[BA] In the case of BUNDLED media, it may not be quite that simple (e.g.
you may have to figure out which packets are supposed to be protected
first).

The problem is that that constraint is incompatible with Insertable
> Streams.  So we need to decide how much we care about compatibility with IS
> as it is.
>

[BA] If we can get clarity on the architecture and the protocol as well as
the use cases, then the API(s) will follow. But requiring backwards
compatibility with existing Web APIs could be overly constraining (and
might yield a null solution set).

  Personally, it seems like WebRTC stacks and web apps are going to have to
> upgrade *anyway* if they're going to support SDP-based negotiation of
> SFrame, so if they have to make this one extra change, it shouldn't be a
> big deal.
>

[BA] I would like to suggest broadening the mindset beyond WebRTC.  One of
the major advantages of SFRAME is that it is transport agnostic, so that it
can be transported over WebRTC data channel, WebTransport, or even HTTPS.
As a result, WebRTC Encoded Transform is not the only relevant Web API and
W3C WEBRTC WG is not the only relevant W3C WG.