Re: [Sframe] [dispatch] Request session at IETF 108 dispatch

Richard Barnes <> Mon, 15 June 2020 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BAA23A0914 for <>; Mon, 15 Jun 2020 12:29:30 -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 yIPTloND6fTL for <>; Mon, 15 Jun 2020 12:29:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 301F33A08FC for <>; Mon, 15 Jun 2020 12:29:28 -0700 (PDT)
Received: by with SMTP id er17so8319627qvb.8 for <>; Mon, 15 Jun 2020 12:29:28 -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=usmSYOdrwAP4QhCy2FKKUHSQsgQ641y04x27a6Q08zo=; b=FFX3QlBoe+FWt0QSE0jzpySi/ZKZ3+aqf/97hZ3tQXCtEUZq7ZpWrr1fs351f/Cb4C xAtfosWoiiHePD/vtsVV90AM5iIATSiOkgVkhrD+KToUL0anQRQGOC17aa310OU2Accf NZGT46TtH3dvXY1jqyzsekU0uHpSPRjozxnuo8ztrfloAnm7OlGk2niqMZxCDVPP5PmY ovWNeyx8elKtRLryKBV6pE150xZqjgBuLLO/Ut14fDVbbbJ0QsqZOM+PbH2nQlnDUwe9 NafhcxtMqtHko6H5Xb+QZ5WX/ASF66r46ELqq7DhN79y3YveEG+WlXBNMgrm9UzWObUO 0X7A==
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=usmSYOdrwAP4QhCy2FKKUHSQsgQ641y04x27a6Q08zo=; b=QDbMRPmrrieFHQmvU4L7YEjeBHLy4G6PjbXGdY37bcRCbSTHuWc9x67UNYo3setdYJ 1jNm9io7QM8p1y3nL231BBaVeHbtLQ1rq4S75hubfwmJc5aP1Fb4LdfpPozu7BNFRzgn z46TsA073ohE2y9DetLNYfLOlfTPWoIdrdLgYIr59ykQIfsNUs1imfzGMqXj2hmkkDiN ijKUdjY+vRFv00hwdnH9T4RaUpiUVCFQmbfnuABtvz8i0iH9/pPI9PPLIGSX5XEr1vYX Hddo7H51/kVgHtcvEorfOQkzrLesSOC/NjN5lO495UrY7ExFlQwbJDgHMk27k7Pxxb3x 1/6A==
X-Gm-Message-State: AOAM533/bShBbrmbDK0A8Apjr2FTeirm4kIuvNJan3ftRgEWOxBg4MQ2 1nlwJnkpQ96XpNsqYxmVCTcdi9ld+ZjbxgjbLFfQlQ==
X-Google-Smtp-Source: ABdhPJwy+/0jfk1j7N6SP8sUJhNki1R2HXtSxzj8xjoDknZHdVT6upW09VreXttTSUQgfk/No30uNNCN0H0dtccyTLQ=
X-Received: by 2002:a0c:8482:: with SMTP id m2mr27024380qva.65.1592249366986; Mon, 15 Jun 2020 12:29:26 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Mon, 15 Jun 2020 15:29:11 -0400
Message-ID: <>
To: Patrick McManus <>
Cc: Emad Omara <>, Ben Campbell <>, Dispatch WG <>,
Content-Type: multipart/alternative; boundary="000000000000e9d2bc05a8247197"
Archived-At: <>
Subject: Re: [Sframe] [dispatch] Request session at IETF 108 dispatch
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jun 2020 19:29:30 -0000

To address the related work point:

You're correct that PERC is the main touch point, MLS less so; also RTCWeb
if that were still going on.  Very directly, this work is doing basically
the same thing as PERC double encryption (RFC 8723).  The key difference is
decoupling between the hop-by-hop and end-to-end security contexts.  In
PERC, the E2E context uses some information from the HBH SRTP packet.  So
the fields used by the E2E context have to be unmodified, well, end to end,
so that a clean media path is a prerequisite for E2E.  (Where "clean" means
"don't modify" or "modify in accordance with PERC")  This dependency makes
it much harder to deploy E2E in practices.  In addition, once the E2E layer
is decoupled from the HBH layer, it is much easier to transmit it over
alternative HBH-secure transports, such as QUIC datagrams, WebTransport, or

FWIW, if I were to suggest a DISPATCH outcome, a focused WG seems like the
right level of attention to me.  The topic is worth working on and would
benefit from an IETF-consensus specification, but the document isn't yet
mature enough for AD sponsorship.


On Mon, Jun 15, 2020 at 2:43 PM Patrick McManus <>

> Sounds really interesting Emad and there's obviously related work going on
> (at least perc, maybe even mls..).
> Sending that email Ben mentions to the dispatch list to raise awareness
> with a link to the draft would be helpful in getting the process started...
> On Mon, Jun 15, 2020 at 2:33 PM Emad Omara <> wrote:
>> Hi Ben,
>> This draft proposes a solution for end-to-end encrypted conference calls.
>> We implemented this in Google a couple of years ago in Duo, but the draft
>> was only published last month given the current interest in the topic.
>> The goal of the session is to go through the proposal and see if there is
>> interest to continue working on this, and if so what will be the best WG to
>> host this work.
>> Thanks
>> Emad
>> On Mon, Jun 15, 2020 at 11:02 AM Ben Campbell <> wrote:
>>> Hi Emad,
>>> We prioritize DISPATCH meeting time to focus on topics that have had
>>> DISPATCH list discussion and need high-bandwidth time to resolve. Unless
>>> I’ve missed something, this topic has not previously come up in DISPATCH. I
>>> suggest sending a note to this list with some background about the draft
>>> and how you would like to see it progress.
>>> Thanks!
>>> Ben.
>>> On Jun 15, 2020, at 12:32 PM, Emad Omara <
>>>> wrote:
>>> Hi,
>>> We would like to have a session in the next IETF to discuss the SFrame
>>> draft <> Can you
>>> please help scheduling this?
>>> Thanks
>>> Emad
>>> _______________________________________________
>>> dispatch mailing list
>>> --
> Sframe mailing list