Re: [Sframe] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-00: (with COMMENT)

Richard Barnes <> Thu, 10 September 2020 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5D263A0A79 for <>; Thu, 10 Sep 2020 06:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wt0oJP_FiVmC for <>; Thu, 10 Sep 2020 06:57:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 417E33A0A3E for <>; Thu, 10 Sep 2020 06:57:01 -0700 (PDT)
Received: by with SMTP id p4so6129848qkf.0 for <>; Thu, 10 Sep 2020 06:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d0PA05n2CZu95Ov7m2OhlIYUW1DbqbouFhzs0Trd1vg=; b=BWAaPiHjtc3/DxtbAx3GKZHY3o/2cbqDxhzOPqgzPG4FeJyR/zDM5k4x/uzONf8no+ rQ07CRPAZ2LT2GAyj8Auf6DDq9oQe42GBhzbkMbmRP+BTUnseT4u79Q41DplSXVOXRM0 ZD6ewJGX94zrbXGF8JHpJdB2jhk07LGiJXT7+MJCtqdgWTXuGOW00Tx5j8/3JDZuiyRR nldD04v8G8VoTl/EIsjaDdcjXigJoKnZEabd2yX25xl9AsuHn78b2V1e51BHDJTQay+c dBmi2cZ65qr/fvDIK46yDfjqgtVvJpCWg+uirXAHsl3GAAKb1I8wfquBGU0Q2xnZev5h fEiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d0PA05n2CZu95Ov7m2OhlIYUW1DbqbouFhzs0Trd1vg=; b=outtcscZ7/q1Iklk0TA3JF83J/whZZ/mUSTXHo/JhqW1NwIpyJOzBYmSqAXkHo0rkS lH5om3bS/6UEK9KTFgqMDsIBJtYThrpDi/n1yYhXxyVID08b1mKNS66ZC63iluMJYoQV oJjoL3+JO3O8cdnkmU9RzrqFC/ZZNpzthr8xP9mDfBy7I33edrQMQ/boVwrOEQKQmYCY 1nup2HlphGTuGdq9Hy9Lhp1EmrI7shutwg0UVEWGmTx9rIFGRmc7a9rBhKTVq4bgwIDO m/PUaUkN58phbhzpnQpj298ljPEC2OVR9hqhRMkVkfFNSDbvOvhLYIHh3yBgKRKbOTPf gHWw==
X-Gm-Message-State: AOAM531TBxnyx3mu1lOBA4OJlUWDNTBmib6h//1FoEa1OmdzXrgDZ6Cg BHzmSmWIm1EkrtiaOHmLBBFURAsS3amg1ia6TIzn0w==
X-Google-Smtp-Source: ABdhPJzJAYlLinhGJKmrIyZxmZ+U0ZvYARpH5+kSQKn7UAH7zdJ38+FZjObDaGLcRVByGDhdfjkmpsJcMzanW+GynhU=
X-Received: by 2002:a37:d09:: with SMTP id 9mr8003521qkn.159.1599746220244; Thu, 10 Sep 2020 06:57:00 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Thu, 10 Sep 2020 09:56:42 -0400
Message-ID: <>
To: Benjamin Kaduk <>
Cc: The IESG <>,, DISPATCH <>,
Content-Type: multipart/alternative; boundary="00000000000030674705aef5f13a"
Archived-At: <>
Subject: Re: [Sframe] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-00: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 13:57:03 -0000

Hi Ben,

See inline.

On Wed, Sep 9, 2020 at 7:31 PM Benjamin Kaduk via Datatracker <> wrote:

>     Real-time conferencing sessions increasingly require end-to-end
>     protections that prevent intermediary servers from decrypting
> real-time media.
>     The PERC WG developed a “double encryption” scheme for end-to-end
> encryption
>     that was deeply tied to SRTP as its underlying transport.  This
> entanglement
>     has prevented widespread deployment.
> I thought we were going to tweak this text (noting that RFC RFC 8723 is
> only a
> handful of months old).

Given the speed of the RFC process vs. the speed of deployment these days,
successful things succeed before RFC.

> It might also be worth a note about the general expected shape of the key
> hierarchy (e.g., one key per sender vs. full mesh).

I don't think we have an expected shape.  In practice, it will always be
per-sender keys.  But that's not an assumption we should bake in.

If you want an IETF precedent, the right analogy would be something like
CMS AuthEnvelopedData [].  Except that
SFrame (a) wouldn't do the asymmetric-encrypt-the-key part, and (b) would
optimize down the encoding to be suitable for real-time.

>     * Selection among multiple encryption keys in use during a real-time
> session
>     * Information to form a unique nonce within the scope of the key
>     * Authenticated encryption using the selected key and nonce
> I assume that this means "assembling preexisting crypto building blocks",
> not
> "define new crypto".

Correct.  It means "send the ciphertext".  I think we can probably delete
this bullet.

>     The transport-independence of this encapsulation means that it can be
> applied
>     at a higher level than individual RTP payloads.  For example, it may be
>     desirable to encrypt whole frames that span multiple packets in order
> to
>     amortize the overhead from framing and authentication tags.  It may
> also be
>     desirable to encrypt units of intermediate size (e.g., H.264 NALUs or
> AV1 OBUs)
>     to allow partial frames to be usable.  The working group will choose
> what
>     levels of granularity are available and to what degree this can be
> configured.
> (Available as input to the WG of available from its output?)

Available in the output of the WG.  That is, there's a granularity
configuration parameter that we might want in the protocol, and it's up to
the WG to decide whether the parameter exists, and if so, what settings it

    It is anticipated that several use cases of SFrame will involve its use
> with
>     keys derived from the MLS group key exchange protocol.  The working
> group will
>     define a mechanism for doing SFrame encryption using keys from MLS,
> including,
>     for example, the derivation of SFrame keys per MLS epoch and per
> sender.
> Will other sources of key material be considered?

Absolutely!  The default case is manual / unspecified keying (again, just
like with the CMS case above).  This paragraph just says that *in addition
to that*, the WG will specify how it works with MLS.


> --
> Sframe mailing list