Re: [V3] New mailer and IETF107 BoF on RIPT - voice over httpbis/quic

Eric Rescorla <> Sat, 22 February 2020 22:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63BA33A0906 for <>; Sat, 22 Feb 2020 14:00:55 -0800 (PST)
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gBktkeuCFiDZ for <>; Sat, 22 Feb 2020 14:00:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EC5E3A090E for <>; Sat, 22 Feb 2020 14:00:53 -0800 (PST)
Received: by with SMTP id y6so5982807lji.0 for <>; Sat, 22 Feb 2020 14:00:53 -0800 (PST)
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=xh/gXyJoY2TLHOqF+HpX6XizhydzI8NYc0AKZ4mWGms=; b=0VAWUxh9GB0M2KBqol3MR7EKhW6P9f24dF7bNvMdVv8hpDtH4ZcnJTyGwGAyQ7yICQ zuDJMg5zVwQ0KSlJZc0a2xsGNYT9vI6uvTXkCGx7iAr4WVd/TCYMZAbTqvztEo790WKr xuyKY3e/ebVAkW7fhgNyFiXsLoWq12YGcf0hLqMu2s7TWB30jlnr5NTnew3PCvBl6ZV8 NqpCAHRGCanMSwF1p4ly41zEvw2hJjdroC+flxb48BOmhyzDreI3N0pT8o8BOa4oifwI AOpJV8o/olC7S6nzKYnv0rvUrHPfEODSjkXTCe1pdT2owqwswIfYj6Hm/x/VhrvSKR1j DQ6Q==
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=xh/gXyJoY2TLHOqF+HpX6XizhydzI8NYc0AKZ4mWGms=; b=Me9vM3jDchvZy4rgqo5sGqflAFab4zafFoMOcc8Xwy43B2E4sxvcnI+kNlwNPRr+pj ij19sCXJ+1t8MaK2itXWbOTbwKhu1sD0C23RxmK/lH45M5wa9uo4+ln8atDdkExonkTQ Rr8uIZKZ1r+TgYSPYpzDSZoO29zqZfWoyQh81cNxDfBTmYhUbB7lIWAOka7SqWNb6udc XBSUDi/1mRKtToH0nOxY8G54F9XiyJx0AceeeOkiwL6uZUE70HRLfiXKIMDeex9nbXNk 2J1KLZkAltYe6o33w3qtKz64SnWfzIJNSniIjL+4vClY5IVxJYy+qO2mkATFJI5Vyy1K RCfw==
X-Gm-Message-State: APjAAAV24SdchQgW9VbIyijLC+yRkhewE1wI1WoqKmfe9Q4+8ZV6kqIz h3M/mMmD6Rqevr8PqFMgoj/gWqI0XibI8aEK9AGVxQ==
X-Google-Smtp-Source: APXvYqyfx1ioXcyx92cjZNqVet/pqj96DBg77gFju7AgJ/GrO1+Wshv4G/tLMUpRAQFySzAODOvtl4QRHL/pAzEO2CU=
X-Received: by 2002:a05:651c:448:: with SMTP id g8mr26557591ljg.35.1582408844690; Sat, 22 Feb 2020 14:00:44 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Sat, 22 Feb 2020 14:00:08 -0800
Message-ID: <>
To: Jonathan Rosenberg <>,
Content-Type: multipart/alternative; boundary="00000000000013dd67059f3145e2"
Archived-At: <>
Subject: Re: [V3] New mailer and IETF107 BoF on RIPT - voice over httpbis/quic
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 Feb 2020 22:00:58 -0000


Thanks for sending this.

While I think it's interesting to explore the question of how
to reinvent the real-time comms infrastructure using modern
Web-style technologies. I have a number of concerns with
the design and assumptions embodied in this draft.

This document talks multiple times about how it's designed to work
with existing HTTP infrastructure and there are a number of features
of this design that seem to be dictated by that. However, it seems to
me that you are making a number of surprising (and perhaps incorrect)
assumptions about architecture and in general this seems misguided.

- Transport Connections and HTTP Requests Need Not Fate Share There
seems to be an implicit assumption in this design that HTTP LBs have
semi-persistent routing, such that if request 1 and request 2 go to
different servers this is a "migration" event (S 8.9). This may be the
case in some architectures but it's not by any means guaranteed. The
LB is free to send every request to a different server, and Web
applications need to be designed to accommodate this.
(see, for instance:
section The Runtime Environment).

While this might in principle be compatible with RIPT as designed, it seems
unlikely to work well if each byway goes to a different server.

- Use Datagrams, not Raw H3
Relatedly, trying to simulate an unreliable channel by round-robining
a reliable set of streams is clumsy at best. For instance, in cases
where you are transmitting too quickly, you now build up a backlog
of HTTP requests which must still be (re)transmitted even though they
out of date -- and they may even be transmitted before the timely

We already have a technology designed to provide unreliable messaging
for QUIC (
As far as I can tell, the only reason not to use it is that you
are trying to avoid making any new requirements on the server,
but I think that is a mistake because (1) as noted above, you
already are making non-standard assumptions and (2) the future
is bigger than the past, especially given the state of QUIC deployment.

- H3 Is Not Guaranteed
Conversely, you can't assume that H3 will be available. A significant
fraction of networks already do not pass QUIC, so if you want a
viable system it has to gracefully fall back to H2. I would deal with
this and the previous point by just pointing at WebTransport, which
already is expected to provide both unreliable service and fallback.

Assuming I am understanding this draft correctly, it does not
meaingfully support incoming calls to end-user devices because you
have to run a server (which end-user devices will not and generally
cannot). I see you have some notion of having an extension for this,
but that should be provided from the first. This seems like an odd
omission to say the least.

Your charter specifies e2e security, but AFAICT, this is not
provided by this specification, nor is it obvious how to enhance
it to provide it. Indeed, it seems like there's not any support
for a disjoint media path. You may recall that I made similar
comments at the DISPATCH session in SIN, and I had understood
that it was your intention to accommodate these cases, but
I don't see anything here, which is somewhat disappointing.

I see that the charter says

"The protocol uses HTTP techniques for authentication and authorization
(notably OAuth), and requires hop by hop encryption (i.e., https). The
protocol will also allow for e2e media encryption, although keying is
out of scope, and is expected to be handled by other protocols such as

I can't agree with this. If you're going to have STIR, then
you have what you need to provide for E2E media encryption,
and it's a regression from WebRTC not to provide it.

I also noted some more detailed issues, as noted below.

S 3.
   REQ4: The solution should hide the number of servers behind the load
   balancer, allow the addition or removal of servers from the cluster
   at will, and not expose any of this information to the peer

This seems like an odd requirement. I'm not sure how one would even
analyze this. What about timing side channels, host-ids in cookies, etc.?

S 6.
   To ensure authenticated caller ID everywhere, the TG specifies the
   set of allowed caller IDs through an [RFC8226] certificate.  This not
   only informs the client about what numbers it can originate with, it
   also proves to the client that it is capable of vouching for those

In what way does it prove to the client that it is capable of vouching?
Certificates are public information. Is this tied to the TLS connection
in some way?

S 8.4.
   The customer TG URI has to be reachable by the server in order for
   the it to receive calls, and for security purposes it must also
   support TLS and present a valid domain certificate using the same
   trust chains configured into browsers.

1. There is no real IETF normative definition for the trust anchors
for browsers. This is a local (And browser-specific matter)

2. It's worth noting that in this design it's not clear that you
would need to have a WebPKI valid ceritifcae.

S 8.5.
I'm really not a fan of the handler syntax, which seems not
very finished and kind of unspecified. For instance:

   "clientDirectives": "1 to 1: opus;
                                 2 to 2:

Why are you using JSON and then requiring me to parse a string?

S 9.7.
Why are you inventing your own cert enrollment protocol as opposed
to using ACME? Now we have to analyze this protocol too.

On Tue, Feb 18, 2020 at 7:46 AM Jonathan Rosenberg <>

> There is a new work effort underway to standardize an application protocol
> on top of httpbis for real-time voice and video, basically replacing SIP,
> RTP and SDP. This takes advantage of the usage of QUIC and UDP-based
> transport, that makes httpbis more amenable to real-time. The current draft
> also makes use of webtransport.
> We've got a mailer set up:
> And you can read the core draft here:
> We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering
> a working group.
> It would be great to get participation and support from the experts in the
> quic community.
> Thx,
> Jonathan R.
> --
> Jonathan Rosenberg, Ph.D.