From nobody Tue Oct 26 19:01:00 2021 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA22A3A0061 for ; Tue, 26 Oct 2021 19:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 LAoTXrVxTeFg for ; Tue, 26 Oct 2021 19:00:53 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 4E9013A0063 for ; Tue, 26 Oct 2021 19:00:53 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id b188so1734768iof.8 for ; Tue, 26 Oct 2021 19:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sMvtFGqvchfc4qbLTz74RUdXPmu4rE3EhfSbuYibqAc=; b=W/wEjAuuOTkT0rIPzCC5OJez0A2b8ZQk/AcNLWpeRXHMrjpKldwejAe/gP4R+IVxY2 05M/jqc/wzp9Eaut7wxaeFW4J1bxrAby6ayNAHTV+ar3mVLV10R/LG+GAzS3A2xqFeEK HJnn8oQj0t6PijPaLQrHwVTSK8QidlAa3mTaFN9WBKAqJcsxVjRYSl+wvlUvdkIU9Ga3 EnAOE17Yt6+gLJEByx5OIQiEUimuYAuxRSedvTRwREB16y2SiruYvFtGY7Kv8hJrpRV8 nukoTRyupVtpVxkqnoGp2vb2PODE0/YbAnO7L2L+YpBhSW/YqMXqn3xg/yYlhxUhB5AI vPZw== 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=sMvtFGqvchfc4qbLTz74RUdXPmu4rE3EhfSbuYibqAc=; b=JjT5RJT9q1g5PMArPN5wOlRnvjDfkSsc4RpSdp6I47YJXY0hwLSThNOXWZD4FhnbVw DmIMd8+peOQt2U+jTEndcGxBjXjzSrHmUxZZKd6MWrsjSj44p+/0BOwYhfLEEnGjuI2Y V9gYR1Y5i7KnUCMy4cOlmTFfyFdo3H00dYnfweRBliTslxFszsb4FrnOnPr3dYjO6E0P noWbs1xsA/38N4jErL7jjEv6woTthfdNPs7eAhiM9AbxXj4iTvFt+alIO/et6CLHc+yy wnPS5dG7HI5l2PFk/E+n5f5zmaCwzNNpdOGVEiDVnADYI2ets+qm9U7ZYnKi5LT0l1A3 15IQ== X-Gm-Message-State: AOAM531ChoSWrddDDh29QG8kdsJN/ZSLHZSvJR3IZYJefsHqZMFr3pY7 1o/vUkj+LbZeIGgQnd+ar5sx3QwBOYEUlDhL45JKZ8bTRkxseA== X-Google-Smtp-Source: ABdhPJz+W5OXEjyPeDxLTxxKWwnWEPSeC6SgGw6Eol/vgaSs32B8FVep+HcGs5o4zOI130x05Ze6vIPvc941AmgdWqQ= X-Received: by 2002:a5e:8f01:: with SMTP id c1mr17339220iok.148.1635300051904; Tue, 26 Oct 2021 19:00:51 -0700 (PDT) MIME-Version: 1.0 References: <898062F9-1B8F-46D7-96AE-1C7769F162A9@akamai.com> In-Reply-To: <898062F9-1B8F-46D7-96AE-1C7769F162A9@akamai.com> From: Eric Rescorla Date: Tue, 26 Oct 2021 19:00:16 -0700 Message-ID: To: "Holland, Jake" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b200c005cf4bf634" Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-krose-multicast-security X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 02:00:59 -0000 --000000000000b200c005cf4bf634 Content-Type: text/plain; charset="UTF-8" I have reviewed this document. While I have some technical comments below, my bigger comment is that this is the wrong place to start. The right place to start is what the application use cases are and whether there is demand. Once that is done, we can discuss the security properties and whether they are feasible. You make the comparison to 8826, but that was written *after* there was agreement that we wanted to do something like WebRTC. IOW, this belongs in DISPATCH. S 3.2. The Web security model requires that content be authenticated cryptographically. In the context of unicast transport security, authentication means that content is known to have originated from the trusted peer, something that is typically enforced via a cryptographic authentication tag: This is true, but I think misses an important property of Web authentication, which is the binding between the request and the response. I.e., the property is not just that the message came from the peer but also that it came in response to a given request. Viewed in this context, this text is misleading: Asymmetric verification of content delivered through multicast is conceptually identical to the unicast case, owing to the asymmetry of access to the signing key; but the symmetric case does not directly apply given that multiple receivers need access to the same key used for both signing and verification, which in a naive implementation opens up the possibility of forgery by a receiver on-path or with the ability to spoof the source. S 3.3. A baseline for multicast transport integrity that makes sense within the Web security model requires that we first define the minimally acceptable integrity requirements for data that may be presented to a user or otherwise input to the browser's trusted computing base. We propose that the proper minimal standard given the variety of potential use cases, including many that have no need for reliable or in-order delivery, is to require protection against replay, injection, and modification and the ability to detect deletion, loss, or reordering. This standard will necessarily constrain conformant application-layer protocol design, just as the Web security model adds constraints to vanilla TCP. This also seems like the wrong layer of abstraction, as it talks about comsec properties, but those aren't the ones that the Web depends on. i would start from the top and ask what it is the Web wants, not what it is TLS provides. S 3.4.1. In contrast to (say) unicast TLS, on-path monitoring can trivially prove that identical content was delivered to multiple receivers, irrespective of payload encryption. Furthermore, since those receivers all require the same keying material to decrypt the received payload, a compromise of any single receiver's device exposes decryption keys, and therefore the plaintext content, to the attacker. This isn't just about compromise by an attacker but also attacks by other legitimate receivers. The Web doesn't currently allow that but you would introduce that. -Ekr On Tue, Oct 26, 2021 at 5:17 PM Holland, Jake wrote: > Hi secdispatch, > > I hope some of you had a chance to take a look at the document > Kyle sent about the security model for multicast for web traffic[0]: > https://datatracker.ietf.org/doc/html/draft-krose-multicast-security > > I'm requesting a slot to talk about it for IETF 112, and hoping we > can get it dispatched to an appropriate venue. > > Some background: > > We've been doing some work on making multicast viable for web > traffic. I'm chairing a W3C community group chartered to incubate > it[1]. We have a straw-man API[2] with a demo implementation[3] > (without the proposed authentication scheme[4] implemented yet) > that can support an app ported to wasm playing video[5]. As the > charter states, we're aiming to get into webtransport first in a > way functionally similar to the demo (server-to-client datagrams), > and into other APIs like fetch/xhr, the h5 download attribute, and > webrtc afterwards. > > We had hoped to do some further experimentation behind a command- > line flag, but my understanding of the key feedback we got when we > suggested this to chromium[6] was that we need a better security > model with wider consensus before we can do anything like this. > In particular, proposals for web traffic that have different > security properties from TLS will need robust review. > > So we're looking for the right venue (and reviewers!) to establish > a well-considered IETF consensus on what it takes to make multicast > safe enough for the modern internet, particularly including web > traffic. > > We're hoping the final version of this doc will serve as the > foundation for guiding any necessary extensions to the appropriate > protocols, in much the same role that RFC 8826 played for WebRTC. > > Thanks and regards, > Jake > > PS: Please note that it may also be appropriate and valuable, > depending on the answer, to move draft-ietf-mboned-ambi to the same > venue, as some of the discussion in mboned made me suspect it may > not be the right home for discussion of its security properties. > > [0] > https://mailarchive.ietf.org/arch/msg/secdispatch/LRMHRKiHfk3vgV43KRbG31x-y4I/ > [1] https://www.w3.org/community/multicast/ > [2] > https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md > [3] https://github.com/GrumpyOldTroll/chromium_fork > [4] https://datatracker.ietf.org/doc/html/draft-ietf-mboned-ambi > [5] https://www.w3.org/2021/10/TPAC/demos/multicast.html > [6] > https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs/m/_Syfhri7AAAJ > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000b200c005cf4bf634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document. While I have some technical= comments
below, my bigger comment is that this is the wrong place to st= art.

The right place to start is what the application use cases are = and
whether there is demand. Once that is done, we can discuss the
se= curity properties and whether they are feasible. You make the
comparison= to 8826, but that was written *after* there was agreement
that we wante= d to do something like WebRTC. IOW, this belongs in
DISPATCH.

S 3.2.

=C2=A0 =C2=A0The Web security model requires that content be= authenticated
=C2=A0 =C2=A0cryptographically.=C2=A0 In the context of u= nicast transport security,
=C2=A0 =C2=A0authentication means that conten= t is known to have originated from
=C2=A0 =C2=A0the trusted peer, someth= ing that is typically enforced via a
=C2=A0 =C2=A0cryptographic authenti= cation tag:

This is true, but I think misses an important property o= f Web
authentication, which is the binding between the request and
th= e response. I.e., the property is not just that the message
came from th= e peer but also that it came in response to a given
request.

View= ed in this context, this text is misleading:

=C2=A0 =C2=A0Asymmetric= verification of content delivered through multicast is
=C2=A0 =C2=A0con= ceptually identical to the unicast case, owing to the asymmetry of
=C2= =A0 =C2=A0access to the signing key; but the symmetric case does not direct= ly
=C2=A0 =C2=A0apply given that multiple receivers need access to the s= ame key used
=C2=A0 =C2=A0for both signing and verification, which in a = naive implementation
=C2=A0 =C2=A0opens up the possibility of forgery by= a receiver on-path or with the
=C2=A0 =C2=A0ability to spoof the source= .


S 3.3.

=C2=A0 =C2=A0A baseline for multicast transport = integrity that makes sense within
=C2=A0 =C2=A0the Web security model re= quires that we first define the minimally
=C2=A0 =C2=A0acceptable integr= ity requirements for data that may be presented to a
=C2=A0 =C2=A0user o= r otherwise input to the browser's trusted computing base.=C2=A0 We
= =C2=A0 =C2=A0propose that the proper minimal standard given the variety of<= br>=C2=A0 =C2=A0potential use cases, including many that have no need for r= eliable or
=C2=A0 =C2=A0in-order delivery, is to require protection agai= nst replay,
=C2=A0 =C2=A0injection, and modification and the ability to = detect deletion, loss,
=C2=A0 =C2=A0or reordering.=C2=A0 This standard w= ill necessarily constrain conformant
=C2=A0 =C2=A0application-layer prot= ocol design, just as the Web security model
=C2=A0 =C2=A0adds constraint= s to vanilla TCP.

This also seems like the wrong layer of abstractio= n, as it talks
about comsec properties, but those aren't the ones th= at the Web
depends on. i would start from the top and ask what it is the=
Web wants, not what it is TLS provides.


S 3.4.1.
=C2=A0 = =C2=A0In contrast to (say) unicast TLS, on-path monitoring can trivially=C2=A0 =C2=A0prove that identical content was delivered to multiple receiv= ers,
=C2=A0 =C2=A0irrespective of payload encryption.=C2=A0 Furthermore,= since those
=C2=A0 =C2=A0receivers all require the same keying material= to decrypt the
=C2=A0 =C2=A0received payload, a compromise of any singl= e receiver's device
=C2=A0 =C2=A0exposes decryption keys, and theref= ore the plaintext content, to the
=C2=A0 =C2=A0attacker.

This isn= 't just about compromise by an attacker but also attacks
by other le= gitimate receivers. The Web doesn't currently allow that
but you wou= ld introduce that.

-Ekr

On Tue, Oct 26, 2021 at 5:17 PM Holland, = Jake <jholland=3D40akamai= .com@dmarc.ietf.org> wrote:
Hi secdispatch,

I hope some of you had a chance to take a look at the document
Kyle sent about the security model for multicast for web traffic[0]:
https://datatracker.ietf.org/doc= /html/draft-krose-multicast-security

I'm requesting a slot to talk about it for IETF 112, and hoping we
can get it dispatched to an appropriate venue.

Some background:

We've been doing some work on making multicast viable for web
traffic.=C2=A0 I'm chairing a W3C community group chartered to incubate=
it[1].=C2=A0 We have a straw-man API[2] with a demo implementation[3]
(without the proposed authentication scheme[4] implemented yet)
that can support an app ported to wasm playing video[5].=C2=A0 As the
charter states, we're aiming to get into webtransport first in a
way functionally similar to the demo (server-to-client datagrams),
and into other APIs like fetch/xhr, the h5 download attribute, and
webrtc afterwards.

We had hoped to do some further experimentation behind a command-
line flag, but my understanding of the key feedback we got when we
suggested this to chromium[6] was that we need a better security
model with wider consensus before we can do anything like this.
In particular, proposals for web traffic that have different
security properties from TLS will need robust review.

So we're looking for the right venue (and reviewers!) to establish
a well-considered IETF consensus on what it takes to make multicast
safe enough for the modern internet, particularly including web
traffic.

We're hoping the final version of this doc will serve as the
foundation for guiding any necessary extensions to the appropriate
protocols, in much the same role that RFC 8826 played for WebRTC.

Thanks and regards,
Jake

PS:=C2=A0 Please note that it may also be appropriate and valuable,
depending on the answer, to move draft-ietf-mboned-ambi to the same
venue, as some of the discussion in mboned made me suspect it may
not be the right home for discussion of its security properties.

[0] https://mailarchiv= e.ietf.org/arch/msg/secdispatch/LRMHRKiHfk3vgV43KRbG31x-y4I/
[1] https://www.w3.org/community/multicast/
[2] https://gi= thub.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.m= d
[3] https://github.com/GrumpyOldTroll/chromium_fork
[4] https://datatracker.ietf.org/doc/htm= l/draft-ietf-mboned-ambi
[5] https://www.w3.org/2021/10/TPAC/demos/multic= ast.html
[6] https://groups.go= ogle.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs/m/_Syfhri7AAAJ


_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000b200c005cf4bf634--