From nobody Sun Aug 1 05:48:11 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 EA4823A39BF; Sun, 1 Aug 2021 05:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mH0l281gWdd9; Sun, 1 Aug 2021 05:47:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FE63A39BD; Sun, 1 Aug 2021 05:47:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C480E389B0; Sun, 1 Aug 2021 08:51:58 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id l8P5oi-YZO01; Sun, 1 Aug 2021 08:51:56 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CCE3389AD; Sun, 1 Aug 2021 08:51:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E04F29CB; Sun, 1 Aug 2021 08:47:51 -0400 (EDT) From: Michael Richardson To: Dirk-Willem van Gulik , Eric Rescorla , IETF SecDispatch , Henry Story , IETF SAAG In-Reply-To: <66D90DC4-9BCF-4279-868E-61D5731EC2A4@webweaving.org> References: <7F5A47B0-4E26-4C51-AA21-6A6038A80A95@gmail.com> <66D90DC4-9BCF-4279-868E-61D5731EC2A4@webweaving.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] [saag] Interest COVID-19 'passport' standardization? 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: Sun, 01 Aug 2021 12:48:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dirk-Willem van Gulik wrote: > So I think we have some useful lessons learned w.r.t. the importance = of > off-line / totally local validation. A quickly organized (rather open, live, virtual) IAB workshop (maybe combin= ed with W3C people) on lessons learned would be the best result in the short-term (3 months) to me. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEGl/cACgkQgItw+93Q 3WV9pQf9GyWFGfrvZAtJz6AW/o2e+TJMg/VlwEIA8a0i1bPTxdhcS+APYMX8cvGx YGWEhDFpZN0oa/8USoClRTIExHFu8wMxJ25B3fPUsO4NtQXwvVxoXGyiPkGT4/Eu IDW0qgONZx8NH3BM2tK1ITpOna/JnX2S+2Zu1LerNvg0Yo33yGgBeaP1jT5Yvhws XFlnRODuRwcIktaooWWtFwUC5dtzCRZuUl1hbllw0w0MAizyODzzDRbMnJsUIrC7 hK77PWieeZRT3WwloSBLn+cCkUSfniHheIlI6vyqNJItKNOST9SrXUTh3eZQjy2P jO29/MfMDMXfo+HDf9Qi8SgySJP1Kw== =7wji -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 4 10:02:23 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 98A403A0B91 for ; Wed, 4 Aug 2021 10:02:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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.20150623.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 UZq5SjI_ARfb for ; Wed, 4 Aug 2021 10:02:17 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 D78E23A0B8C for ; Wed, 4 Aug 2021 10:02:16 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id h9so4760311ejs.4 for ; Wed, 04 Aug 2021 10:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jaumMmx2JPnGHgO1/uY1I3MtKdkMdQkuQsDX7PPaSPQ=; b=Abn5soifD3WCRLT2HjIyhB/elKlOo3p+I3AkXAyP0PZPMAGHpC4x3ToXvz84Z6Zz5q xU6W56DBNT/NHHoUHzYAcHRew9JUL7QafPevdtIw6OR8yZSJ0HewoGsjtewIh6QaRezi tHbvJUabB65DVV+PkwPE51YSB3dLLamdDZREmrjWa3xGX/6z9xaCGqIyj6hRUAlWO5kn Dgs2DqpA8ud1PYTyD9TV81PONXp4NDNWaPT/Sx4AxpEihDmeyk1MHzpnZb2U/xphVBlr GDXLG1wwUjxh0ll8lC3KimE1j9+lSVdVAQDZYy2n3eMydU8WOHtZypfL0JO9KbEj9CZZ QAfw== 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=jaumMmx2JPnGHgO1/uY1I3MtKdkMdQkuQsDX7PPaSPQ=; b=RBuwu4KorFKNWre+HRryA/XXCaXxl3cWdgFVZhNlaX5xuWDG5EqeMtOdv0PblZKWyk cNaJQKUyOdbErt7hFeiTabqes64YsJc7APKUU+2hA0uCWc5GIm3E5stme5WXGxKGQ0Ea LjfhnyCY8PPBzIZffs/A1QYtpQxRBCYn82v3tiSOSgbc1JoVjJuevsY4nC0Y7VH7IE+3 kxlKVZs+qt6qqQixHzcL1ouJ4mxmNz0VCa+7vgvIIzVsJOt14doCb66MHTGmoUdR40Pi 6OHzQT/Ruws0ho4I71USwGiWQts0zbqkWRX//NZQNMQ4ZFQ7sEU+7Y8HE3HZOBM67dkQ CzAQ== X-Gm-Message-State: AOAM530mSfsrZj3KcM1mOxlibXYtuL42UqpJnVY5uv+Yobp2TRIY4irv 4024F/cD5/ZFLgA3AYFgu/ZBteRwLjgBNVBqvqVcJFNOlroPINOn X-Google-Smtp-Source: ABdhPJxLosFn4TuAPJWK4eSVFS2d61Ywb7BZ73jK4F9rVuFotfrbCIq2uCwiZhNmF7cdC50funuCPiBhCvoVP9MBgvU= X-Received: by 2002:a17:906:c7c2:: with SMTP id dc2mr202306ejb.472.1628096533580; Wed, 04 Aug 2021 10:02:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 4 Aug 2021 10:01:36 -0700 Message-ID: To: Kenneth Vaughn Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000008b67b905c8bec32c" Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-vaughn-tlstm-update 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, 04 Aug 2021 17:02:22 -0000 --0000000000008b67b905c8bec32c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi folks, I'm trying to follow the change in S 2.1 about the TLSTM fingerprint. In TLS 1.2, one represented signature algorithms as: struct { HashAlgorithm hash; SignatureAlgorithm signature; } SignatureAndHashAlgorithm; We found in TLS 1.3 that it was not really possible to mix-and-match them and so changed this to a two-byte SignatureScheme that represented the pair of hash and algorithm as well as any other values but without any other internal structure. E.g., rsa_pss_pss_sha256(0x0809), As I understand it, 6353 used the TLS 1.2 HashAlgorithm identifier to indicate which hash was used to make a fingerprint, and you're changing this because TLS 1.3 deprecated this field? If so, I don't think this is necessary: you're not referring to anything in TLS, you're just reusing the code point. So, I would probably not make any change here. -Ekr On Sun, Jun 27, 2021 at 7:31 PM Kenneth Vaughn wrote= : > I would like to present https://datatracker.ietf.org/doc/draft-vaughn-tls= tm-update-01/, a new version of the proposed update of RFC 6353 (TLSTM). Ba= sed on feedback from this group, and the recent IETF decision to finalize D= TLS, the ITS community decided to keep support for DTLS in the update. The = result of that decision was to reverse a number of changes in the text and = it made more sense to write the proposed new version 01 as an update to RFC= 6353 rather than a replacement of RFC 6353. The result is a shorter docume= nt where the changes are more evident. > > I would like to request 10-15 minutes at IETF meeting of the Security Dis= patch group to discuss the possibility of launching an effort to continue t= he development of this document as an official IETF document. > > Regards, > Ken Vaughn > > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-936-647-1910 > +1-571-331-5670 cell > kvaughn@trevilon.com > www.trevilon.com > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000008b67b905c8bec32c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I'm trying to follow the change in S = 2.1 about the TLSTM fingerprint.

In TLS 1.2, one represented signatu= re algorithms as:

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 HashAlgorithm hash;
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 SignatureAlgorithm signature;
=C2=A0 =C2=A0 =C2=A0 } Sign= atureAndHashAlgorithm;

We found in TLS 1.3 that it was not really po= ssible to mix-and-match
them and so changed this to a two-byte Signature= Scheme that represented
the pair of hash and algorithm as well as any ot= her values but without
any other internal structure. E.g.,

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_pss_sha256(0x0809),

As I unders= tand it, 6353 used the TLS 1.2 HashAlgorithm identifier to
indicate whic= h hash was used to make a fingerprint, and you're changing
this beca= use TLS 1.3 deprecated this field? If so, I don't think this
is nece= ssary: you're not referring to anything in TLS, you're just
reus= ing the code point. So, I would probably not make any change
here.
-Ekr





On Sun, Jun 27, 2021 at 7:31 PM Kenneth Vaughn &l= t;kvaughn@trevilon.com> wrot= e:
I would like to present https://datatracke=
r.ietf.org/doc/draft-vaughn-tlstm-update-01/, a new version of the prop=
osed update of RFC 6353 (TLSTM).=C2=A0Based on feedback from this group, an=
d the recent IETF decision to finalize DTLS, the ITS community decided to k=
eep support for DTLS in the update. The result of that decision was to reve=
rse a number of changes in the text and it made more sense to write the pro=
posed new version 01 as an update to=
 RFC 6353 rather than a replacement of RFC 6353. The result is a shorter do=
cument where the changes are more evident.
I would like to request 10-15 =
minutes at IETF meeting of the Security Dispatch group to discuss the possi=
bility of launching an effort to continue the development of this document =
as an official IETF document.
Regar= ds,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571= -331-5670 cell
<= /div>

_________________________________________= ______
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000008b67b905c8bec32c-- From nobody Wed Aug 4 10:56:53 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 4FDF03A0E30 for ; Wed, 4 Aug 2021 10:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=trevilon.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 hx1W-8BaSs_V for ; Wed, 4 Aug 2021 10:56:46 -0700 (PDT) Received: from tre.trevilon.com (tre.trevilon.com [198.57.226.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABDB33A0E29 for ; Wed, 4 Aug 2021 10:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trevilon.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5TqQmcnXOWtC7IzVpgGQiJ7vQGIUphCfZQvpUnrTWJ8=; b=jU+7nUp+tgcvgUhp47Mx/IvxNx LUQPFmQEplYfNX+CeXdAtAELakGm6iDgixC5Qk6fmgflbZ/Z8mF6PxMihBX+S0Kd9HnMe3XSjBLEn qDow3xreT+xML8GdkT8cSmJwl; Received: from [92.119.18.40] (port=56453 helo=smtpclient.apple) by tre.trevilon.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mBL8H-0004Wt-2K; Wed, 04 Aug 2021 17:56:45 +0000 From: Kenneth Vaughn Message-Id: <6CB9CF84-CF11-4386-A790-8FD9FCC0E0AD@trevilon.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_90F9FE0C-13BC-41D2-B22E-4007CF8C365F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 4 Aug 2021 12:56:43 -0500 In-Reply-To: Cc: IETF SecDispatch To: Eric Rescorla References: X-Mailer: Apple Mail (2.3654.100.0.2.22) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - tre.trevilon.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trevilon.com X-Get-Message-Sender-Via: tre.trevilon.com: authenticated_id: kvaughn@trevilon.com X-Authenticated-Sender: tre.trevilon.com: kvaughn@trevilon.com Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-vaughn-tlstm-update 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, 04 Aug 2021 17:56:52 -0000 --Apple-Mail=_90F9FE0C-13BC-41D2-B22E-4007CF8C365F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Correct, TLS 1.2 provided separate one octet identifiers for the hash = and signature algorithm. TLS 1.3 replaces the two identifiers with a = single, two-octet cipher suite identifier that indicates a unique = combination of hash and signature algorithm. The former method provided = for 255 hash algorithms and 255 signature algorithms - apparently, it = was determined that some combinations did not make sense so the values = were combined - meaning all 65535 values can be assigned to meaningful = combinations but also meaning that we can no longer assume that the = first octet uniquely identifies the hash algorithm by itself. If the IANA continues to maintain the TLS 1.2 hash algorithm registry, I = agree that there could be an easier fix for RFC 6353; but there does not = seem to be any guarantee at present that this will happen as TLS 1.2 = ages. This results in two possible paths forward: Option 1 is that we require the IANA to continue the maintenance of the = 1.2 registry AND we create an update to RFC 6353 that clarifies that the = 1.2 hash algorithm registry should still be used for the fingerprint, = even when using TLS 1.3 (the update is needed as the mapping for 1.3 is = ambiguous otherwise) OR=20 Option 2 is that we update RFC 6353 with a new fingerprint algorithm = that uses the 1.3 registry (and then there is no additional requirement = on IANA) Our proposal was based on the concept that, if we are updating RFC 6353 = anyway, we might as well decrease long-term maintenance issues for IANA = (but recognizing that this is a bigger change on the standard and on = implementations). But I agree that the work load could be shifted to = IANA, which would simplify other issues. What is important is that we = reach consensus on the approach to be followed and document the decision = so that it is unambiguous. It's largely a question of who has to do the = work. Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-936-647-1910 +1-571-331-5670 cell kvaughn@trevilon.com www.trevilon.com > On Aug 4, 2021, at 12:01 PM, Eric Rescorla wrote: >=20 > Hi folks, >=20 > I'm trying to follow the change in S 2.1 about the TLSTM fingerprint. >=20 > In TLS 1.2, one represented signature algorithms as: >=20 > struct { > HashAlgorithm hash; > SignatureAlgorithm signature; > } SignatureAndHashAlgorithm; >=20 > We found in TLS 1.3 that it was not really possible to mix-and-match > them and so changed this to a two-byte SignatureScheme that = represented > the pair of hash and algorithm as well as any other values but without > any other internal structure. E.g., >=20 > rsa_pss_pss_sha256(0x0809), >=20 > As I understand it, 6353 used the TLS 1.2 HashAlgorithm identifier to > indicate which hash was used to make a fingerprint, and you're = changing > this because TLS 1.3 deprecated this field? If so, I don't think this > is necessary: you're not referring to anything in TLS, you're just > reusing the code point. So, I would probably not make any change > here. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 > On Sun, Jun 27, 2021 at 7:31 PM Kenneth Vaughn > wrote: > I would like to present = https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ = , a new = version of the proposed update of RFC 6353 (TLSTM). Based on feedback = from this group, and the recent IETF decision to finalize DTLS, the ITS = community decided to keep support for DTLS in the update. The result of = that decision was to reverse a number of changes in the text and it made = more sense to write the proposed new version 01 as an update to RFC 6353 = rather than a replacement of RFC 6353. The result is a shorter document = where the changes are more evident. > I would like to request 10-15 minutes at IETF meeting of the Security = Dispatch group to discuss the possibility of launching an effort to = continue the development of this document as an official IETF document. > Regards, > Ken Vaughn >=20 > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-936-647-1910 > +1-571-331-5670 cell > kvaughn@trevilon.com > www.trevilon.com > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_90F9FE0C-13BC-41D2-B22E-4007CF8C365F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Correct, TLS 1.2 provided separate one octet identifiers for = the hash and signature algorithm. TLS 1.3 replaces the two identifiers = with a single, two-octet cipher suite identifier that indicates a unique = combination of hash and signature algorithm. The former method provided = for 255 hash algorithms and 255 signature algorithms - apparently, it = was determined that some combinations did not make sense so the values = were combined - meaning all 65535 values can be assigned to meaningful = combinations but also meaning that we can no longer assume that the = first octet uniquely identifies the hash algorithm by itself.

If the IANA continues to maintain the = TLS 1.2 hash algorithm registry, I agree that there could be an easier = fix for RFC 6353; but there does not seem to be any guarantee at present = that this will happen as TLS 1.2 ages. This results in two possible = paths forward:

Option 1 is that we require the IANA to continue the = maintenance of the 1.2 registry AND we create an update to RFC 6353 that = clarifies that the 1.2 hash algorithm registry should still be used for = the fingerprint, even when using TLS 1.3 (the update is needed as the = mapping for 1.3 is ambiguous otherwise) OR 

Option 2 is that we = update RFC 6353 with a new fingerprint algorithm that uses the 1.3 = registry (and then there is no additional requirement on IANA)


Our proposal was based on the concept that, if we are = updating RFC 6353 anyway, we might as well decrease long-term = maintenance issues for IANA (but recognizing that this is a bigger = change on the standard and on implementations). But I agree that the = work load could be shifted to IANA, which would simplify other issues. = What is important is that we reach consensus on the approach to be = followed and document the decision so that it is unambiguous. It's = largely a question of who has to do the work.



On Aug 4, 2021, at 12:01 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

Hi folks,

I'm trying = to follow the change in S 2.1 about the TLSTM fingerprint.

In TLS 1.2, one represented signature = algorithms as:

      struct = {
            HashAlgorithm = hash;
            = SignatureAlgorithm signature;
      } = SignatureAndHashAlgorithm;

We found in TLS = 1.3 that it was not really possible to mix-and-match
them = and so changed this to a two-byte SignatureScheme that represented
the pair of hash and algorithm as well as any other values = but without
any other internal structure. E.g.,

          = rsa_pss_pss_sha256(0x0809),

As I understand = it, 6353 used the TLS 1.2 HashAlgorithm identifier to
indicate which hash was used to make a fingerprint, and = you're changing
this because TLS 1.3 deprecated this = field? If so, I don't think this
is necessary: you're not = referring to anything in TLS, you're just
reusing the code = point. So, I would probably not make any change
here.

-Ekr





On Sun, Jun = 27, 2021 at 7:31 PM Kenneth Vaughn <kvaughn@trevilon.com> wrote:
I would like =
to present https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/<=
/a>, a new version of the proposed update of RFC 6353 =
(TLSTM). Based on feedback from this group, and the recent IETF =
decision to finalize DTLS, the ITS community decided to keep support for =
DTLS in the update. The result of that decision was to reverse a number =
of changes in the text and it made more sense to write the proposed new =
version 01 as an update to RFC 6353 rather than a replacement =
of RFC 6353. The result is a shorter document where the changes are more =
evident.
I would like =
to request 10-15 minutes at IETF meeting of the Security Dispatch group =
to discuss the possibility of launching an effort to continue the =
development of this document as an official IETF =
document.

_________________________________= ______________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

= --Apple-Mail=_90F9FE0C-13BC-41D2-B22E-4007CF8C365F-- From nobody Wed Aug 4 11:04:58 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 E2D5F3A0E96 for ; Wed, 4 Aug 2021 11:04:56 -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.20150623.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 yIvPzSxdPTW8 for ; Wed, 4 Aug 2021 11:04:51 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 4DDCA3A0E90 for ; Wed, 4 Aug 2021 11:04:51 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id f6so3445211ioc.6 for ; Wed, 04 Aug 2021 11:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sMQKqOGx3z1Mi+c6WV8SInTeFD3rB4uqMZWe/h32ydo=; b=W1iFFetdX+tWp0YpxhFLiR11JC6uMotwsL5Dst/RpSDgXVOszVqkfShfedGAQIXopH 2p4+PVqOG59LMZej7M79oyvhhKHXs+Ix2ci5PpUz1rrib3uIfBhsXBzKz9t2Dh6wFEuB jgq2WfCTvQ4HYF+UMqcGtUhiHCasguscdTwdZHlskgnXQ6Dj7wb6/t3seM97xpGH26ky 0j5CXIsjQFVjib4lQ2TFBKW387Nj4UjfU77vhDlVKc5ntuyv3foghagljrMDYmpIewtG N5LKFdoKe6XW5cAsoEIUp/M0h1oj4+64Rk0DzT49fOt6c2PAOWEMMAE7usA0wBD0KgDN zZVQ== 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=sMQKqOGx3z1Mi+c6WV8SInTeFD3rB4uqMZWe/h32ydo=; b=dblUf0N49itupeoo06RfI9ce0RHWI4l3YfVpbPDMzGwGLjAB69rzNHM0Ox/UEN2Hqu CCHqO6EU2/GmQ2MZr3G3cYw4u899puwH3j5sjnPvX7z7mCVc4sfh5Gt0mM3T8DJwvfYM eZA7L+twjc/NErkax7qeUZjrdoWRGcd5nPybs3roJd9OoqhPfwl9KP4mFDEuYdEBiZM7 iYDaVZJXMaTPNMouKq2rCUraTo8wjynaSAZO4hYmpKCfLSAWgET1okcliUDSriAAJIh8 xkWuM/WzK1eR5htq5LiFCQjIj9PYFdGJZdUr4SnFq9PW1X3IR4wMxvC7zT84rytTyWff tVTA== X-Gm-Message-State: AOAM530A1TDABgki7USnZ/LKLle46Lk/nRl/WCFaHhY9tKiiJjaEfr6r yZKCXyrR9Go9VImo5a3ILjJWLZGKz8QjgI5z6X1XYQ== X-Google-Smtp-Source: ABdhPJwvN5gGYayqe/kpNa6NaxL3UjQBFgqW4kcd54KTG7tTYbiMyPKm3NJTU/vfpjdJLMDsioUVjHvLNN1DUbNHVgk= X-Received: by 2002:a05:6638:338f:: with SMTP id h15mr632339jav.135.1628100289228; Wed, 04 Aug 2021 11:04:49 -0700 (PDT) MIME-Version: 1.0 References: <6CB9CF84-CF11-4386-A790-8FD9FCC0E0AD@trevilon.com> In-Reply-To: <6CB9CF84-CF11-4386-A790-8FD9FCC0E0AD@trevilon.com> From: Eric Rescorla Date: Wed, 4 Aug 2021 11:04:13 -0700 Message-ID: To: Kenneth Vaughn Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000660c8f05c8bfa3b6" Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-vaughn-tlstm-update 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, 04 Aug 2021 18:04:57 -0000 --000000000000660c8f05c8bfa3b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 4, 2021 at 10:56 AM Kenneth Vaughn wrote= : > Correct, TLS 1.2 provided separate one octet identifiers for the hash and > signature algorithm. TLS 1.3 replaces the two identifiers with a single, > two-octet cipher suite identifier that indicates a unique combination of > hash and signature algorithm. > Just to clarify, this is not a "cipher suite" but rather a "signature scheme". TLS cipher suites consist of the pair of AEAD and hash algorithms. The former method provided for 255 hash algorithms and 255 signature > algorithms - apparently, it was determined that some combinations did not > make sense so the values were combined - meaning all 65535 values can be > assigned to meaningful combinations but also meaning that we can no longe= r > assume that the first octet uniquely identifies the hash algorithm by > itself. > Yes, that's correct. If the IANA continues to maintain the TLS 1.2 hash algorithm registry, I > agree that there could be an easier fix for RFC 6353; but there does not > seem to be any guarantee at present that this will happen as TLS 1.2 ages= . > This results in two possible paths forward: > > Option 1 is that we require the IANA to continue the maintenance of the > 1.2 registry AND we create an update to RFC 6353 that clarifies that the > 1.2 hash algorithm registry should still be used for the fingerprint, eve= n > when using TLS 1.3 (the update is needed as the mapping for 1.3 is > ambiguous otherwise) OR > I don't understand this point. There's no dependency here on TLS 1.3 at all. You're just using the registry. In fact, nothing stops you from using hash algorithms which TLS 1.3 doesn't support at all. Option 2 is that we update RFC 6353 with a new fingerprint algorithm that > uses the 1.3 registry (and then there is no additional requirement on IAN= A) > I don't see how you can use either of the TLS 1.3 registries that include hashes (signature scheme or cipher suite) as both have multiple entries for the same hash algorithm (e.g., RSA and ECDSA with SHA-256, AES_128_GCM and Chacha20Poly1305 with SHA-256). This is going to create an enormous amount of confusion. > Our proposal was based on the concept that, if we are updating RFC 6353 > anyway, we might as well decrease long-term maintenance issues for IANA > (but recognizing that this is a bigger change on the standard and on > implementations). But I agree that the work load could be shifted to IANA= , > which would simplify other issues. What is important is that we reach > consensus on the approach to be followed and document the decision so tha= t > it is unambiguous. It's largely a question of who has to do the work. > I don't think continuing to maintain this registry will constitute an appreciable amount of work for IANA. However, you could also just clone the registry. -Ekr > > > Regards, > Ken Vaughn > > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-936-647-1910 > +1-571-331-5670 cell > kvaughn@trevilon.com > www.trevilon.com > > On Aug 4, 2021, at 12:01 PM, Eric Rescorla wrote: > > Hi folks, > > I'm trying to follow the change in S 2.1 about the TLSTM fingerprint. > > In TLS 1.2, one represented signature algorithms as: > > struct { > HashAlgorithm hash; > SignatureAlgorithm signature; > } SignatureAndHashAlgorithm; > > We found in TLS 1.3 that it was not really possible to mix-and-match > them and so changed this to a two-byte SignatureScheme that represented > the pair of hash and algorithm as well as any other values but without > any other internal structure. E.g., > > rsa_pss_pss_sha256(0x0809), > > As I understand it, 6353 used the TLS 1.2 HashAlgorithm identifier to > indicate which hash was used to make a fingerprint, and you're changing > this because TLS 1.3 deprecated this field? If so, I don't think this > is necessary: you're not referring to anything in TLS, you're just > reusing the code point. So, I would probably not make any change > here. > > -Ekr > > > > > > On Sun, Jun 27, 2021 at 7:31 PM Kenneth Vaughn > wrote: > >> I would like to present https://datatracker.ietf.org/doc/draft-vaughn-tl= stm-update-01/, a new version of the proposed update of RFC 6353 (TLSTM). B= ased on feedback from this group, and the recent IETF decision to finalize = DTLS, the ITS community decided to keep support for DTLS in the update. The= result of that decision was to reverse a number of changes in the text and= it made more sense to write the proposed new version 01 as an update to RF= C 6353 rather than a replacement of RFC 6353. The result is a shorter docum= ent where the changes are more evident. >> >> I would like to request 10-15 minutes at IETF meeting of the Security Di= spatch group to discuss the possibility of launching an effort to continue = the development of this document as an official IETF document. >> >> Regards, >> Ken Vaughn >> >> Trevilon LLC >> 6606 FM 1488 RD #148-503 >> Magnolia, TX 77354 >> +1-936-647-1910 >> +1-571-331-5670 cell >> kvaughn@trevilon.com >> www.trevilon.com >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > > --000000000000660c8f05c8bfa3b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 4, 2021 at 10:56 AM Kenne= th Vaughn <kvaughn@trevilon.com<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">
Correct, TLS 1.2 provided sep= arate one octet identifiers for the hash and signature algorithm. TLS 1.3 r= eplaces the two identifiers with a single, two-octet cipher suite identifie= r that indicates a unique combination of hash and signature algorithm.




<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Option 2 is that we update RFC 6353 with a new fi= ngerprint algorithm that uses the 1.3 registry (and then there is no additi= onal requirement on IANA)

I don't see how you can use either of the TLS 1.3 registries that incl= ude hashes (signature scheme or cipher suite) as both have multiple entries= for the same hash algorithm (e.g., RSA and ECDSA with SHA-256, AES_128_GCM= and Chacha20Poly1305 with SHA-256). This is going to create an enormous am= ount of confusion.

On Aug 4, 2021, at 12:01 PM, Eric R= escorla <ekr@rtfm.com<= /a>> wrote:

Hi folks,

I'm tryi= ng to follow the change in S 2.1 about the TLSTM fingerprint.

In TLS= 1.2, one represented signature algorithms as:

=C2=A0 =C2=A0 =C2=A0 = struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HashAlgorithm hash;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SignatureAlgorithm signature;=C2=A0 =C2=A0 =C2=A0 } SignatureAndHashAlgorithm;

We found in TLS = 1.3 that it was not really possible to mix-and-match
them and so changed= this to a two-byte SignatureScheme that represented
the pair of hash an= d algorithm as well as any other values but without
any other internal s= tructure. E.g.,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsa_pss_pss_sha25= 6(0x0809),

As I understand it, 6353 used the TLS 1.2 HashAlgorithm i= dentifier to
indicate which hash was used to make a fingerprint, and you= 're changing
this because TLS 1.3 deprecated this field? If so, I do= n't think this
is necessary: you're not referring to anything in= TLS, you're just
reusing the code point. So, I would probably not m= ake any change
here.

-Ekr





On Sun, Jun 27, 2021= at 7:31 PM Kenneth Vaughn <kvaughn@trevilon.com> wrote:
= 
I would like to present https:/=
/datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/, a new version =
of the proposed update of RFC 6353 (TLSTM).=C2=A0Based on feedback from thi=
s group, and the recent IETF decision to finalize DTLS, the ITS community d=
ecided to keep support for DTLS in the update. The result of that decision =
was to reverse a number of changes in the text and it made more sense to wr=
ite the proposed new version 01 as a=
n update to RFC 6353 rather than a replacement of RFC 6353. The result is a=
 shorter document where the changes are more evident.
I would like to req=
uest 10-15 minutes at IETF meeting of the Security Dispatch group to discus=
s the possibility of launching an effort to continue the development of thi=
s document as an official IETF document.
=
=
=
Regards,
Ken Vaughn
<= br>
Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-= 936-647-1910
+1-571-331-5670 cell

_________________________________________= ______
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

--000000000000660c8f05c8bfa3b6-- From nobody Fri Aug 6 16:44:44 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 394DF3A1EA6 for ; Fri, 6 Aug 2021 16:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=krose.org 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 aB6Ktaa77--N for ; Fri, 6 Aug 2021 16:44:36 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 6C8803A1EA3 for ; Fri, 6 Aug 2021 16:44:36 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id c9so12967189wri.8 for ; Fri, 06 Aug 2021 16:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=dZCVaWlR3bbmfSedwhgxxCetA7NGhMU9/64Bv3j4/0w=; b=Y+Z8yFBkP71+bBh/8V/VEHZSxMFefBax0sShFyI/J0y6jjToh01GGF/QvCbI5kATXt xSGyIuA7tnjvYaqGZ0JyrfiQSlbP0jrmvtq88W/eyHgaO4dWh4oyvMEoCu/RT3OL5Xce VXc0+hXv0sUrn0M+bNfowMdFIhtGfWdhDOOTE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=dZCVaWlR3bbmfSedwhgxxCetA7NGhMU9/64Bv3j4/0w=; b=jYSQ7A6VVJbpEwrBfR9Njv8Ivdrv8PQKSRReY3gFkmNE7outxIxdX3+2+f19XMPW/g fGSyOnuac4jDswVT0FrAZxKshtvsbyq2hHiG2DJx4fvrTbG3hXnuKxM3lH54QNOQgutf hWOWlqLQ9FzJ2Ev3HtkAdULWUnRcbWOwH9HmypiIwM2eOI/KRoKJ6cKKC7PuGCs1Tvp5 reCVCrO/VfuUJurDUhA6wH9ZtlEkCR42rZg+tkWP47nYYwLicydsUfccpMU7EhqyqSFl yBvdXSmBgkllB45omtYG+NYdjT99CRlmLFndCj49lAIr3Vvw6RCfug7yeJXD5M9FtERX UjTQ== X-Gm-Message-State: AOAM531d0nHqSaw/y3GCM1wM9Qn13YUR8DWPREOlTHpIADbK+cLV2XQg s8MZqxZzqE1xWp9VYjU1U0hU7j5H9nAjbwOWTpYdWd63bQY= X-Google-Smtp-Source: ABdhPJxoheD2P+/oJEoctGM9nPkpklwcEJIkT/cBAJK0xXyoA8jIzLgW5eYA6n3g4649KgZTbJwiVcDjVwhHdEzPZcU= X-Received: by 2002:adf:cd92:: with SMTP id q18mr13425956wrj.18.1628293472726; Fri, 06 Aug 2021 16:44:32 -0700 (PDT) MIME-Version: 1.0 From: Kyle Rose Date: Fri, 6 Aug 2021 19:44:21 -0400 Message-ID: To: secdispatch@ietf.org Cc: Jake Holland Content-Type: multipart/alternative; boundary="000000000000083cf605c8ec9ec8" Archived-At: Subject: [Secdispatch] Multicast Security and Privacy Considerations 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: Fri, 06 Aug 2021 23:44:42 -0000 --000000000000083cf605c8ec9ec8 Content-Type: text/plain; charset="UTF-8" Secdispatch participants: Across two SDOs (IETF and W3C), multiple parties have begun to look into how to make multicast safe within the Web security model. As part of this effort, Jake Holland and I have been putting together a security and privacy considerations document for multicast, akin to that for WebRTC (RFC 8826), that attempts to identify where multicast inherently differs from unicast in usage patterns and protocol constraints, and then lays out a set of requirements for multicast protocols that we believe would allow them to fit within the spirit of the Web security model. From the abstract: > Interdomain multicast has unique potential to solve delivery scalability for popular content, but it carries a set of security and privacy issues that differ from those in unicast delivery. This document analyzes the security threats unique to multicast-based delivery for Internet and Web traffic under the Internet and Web threat models. We come to secdispatch primarily with the aim of finding a venue within the IETF in which to continue to flesh out and improve this work. Considering the potential security and privacy implications for browsers of introducing a model for content delivery that in many ways fundamentally differs from that provided by existing unicast transports, we are especially interested in the question of whether this fits into any existing working groups (whether in the security area or otherwise) or would necessitate a new group, such as a reopening of MSEC. Of course, any helpful feedback is welcomed. The draft and associated GitHub repo can be found here: https://datatracker.ietf.org/doc/draft-krose-multicast-security/ https://github.com/squarooticus/draft-krose-multicast-security Thanks, Kyle (and Jake) --000000000000083cf605c8ec9ec8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sec= dispatch participants:

Across two SDOs (IETF and W3C), multiple part= ies have begun to look into how to make multicast safe within the Web secur= ity model. As part of this effort, Jake Holland and I have been putting tog= ether a security and privacy considerations document for multicast, akin to= that for WebRTC (RFC 8826), that attempts to identify where multicast inhe= rently differs from unicast in usage patterns and protocol constraints, and= then lays out a set of requirements for multicast protocols that we believ= e would allow them to fit within the spirit of the Web security model. From= the abstract:

> Interdomain multicast has unique potential to so= lve delivery scalability for popular content, but it carries a set of secur= ity and privacy issues that differ from those in unicast delivery. This doc= ument analyzes the security threats unique to multicast-based delivery for = Internet and Web traffic under the Internet and Web threat models.

W= e come to secdispatch primarily with the aim of finding a venue within the = IETF in which to continue to flesh out and improve this work. Considering t= he potential security and privacy implications for browsers of introducing = a model for content delivery that in many ways fundamentally differs from t= hat provided by existing unicast transports, we are especially interested i= n the question of whether this fits into any existing working groups (wheth= er in the security area or otherwise) or would necessitate a new group, suc= h as a reopening of MSEC. Of course, any helpful feedback is welcomed.

The draft and associated GitH= ub repo can be found here:

https://datatracker.ietf.org/doc/draft-krose-mult= icast-security/
https://github.com/squarooticus/draft-krose-multicas= t-security
=
Thanks,
Kyle (and Jak= e)
--000000000000083cf605c8ec9ec8--