From nobody Tue Mar 2 20:56:57 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 E927E3A1834 for ; Tue, 2 Mar 2021 20:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=lowentropy.net header.b=FCfMMtUd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AlkF0SAO 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 GPSQgszd1qPT for ; Tue, 2 Mar 2021 20:56:53 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D163A18E2 for ; Tue, 2 Mar 2021 20:56:53 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C054F5C0118 for ; Tue, 2 Mar 2021 23:56:51 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 02 Mar 2021 23:56:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=VSjhg3dMDcaAyGcQjPl52n31tlIbXpB sI4vrlqsYeeQ=; b=FCfMMtUdWZQgAtOhIWRCrcua3ete++3icrcUwLsY8oQGDqn so4xn8S/jUI1pkI5QJACneG30GzTw5KHI4TrsrU0a4vF7SutMu3xWAZTWPvMcEny LUadQlxyrITRMUQbu79k4Ktl5GZCY7uu+eJDOKjSXasY4mu6/+55ovUC3yssZ+ZY 5zqzK3WjrdpC2PyjVCpCQaD4emgm9Al98URY0/JhJWYkMuxH21Udw0rBW8Cfp5Pp Vli9y3r2bMMGaMviIcKrVZ8s2GIuUqvsc2lLD0A1psP/AQ30TIW/2aiaiRoVinDa rI4h+QKieyQ+/9bHIksYAOXo2gjV2Ra96+Fnb6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=VSjhg3 dMDcaAyGcQjPl52n31tlIbXpBsI4vrlqsYeeQ=; b=AlkF0SAOD/YUAGeVxcyJW8 K/7tCbgJSoM3/fy+uYK9J+VoysEp5n2niaG0AVAbVFA+cSZrtYNXikxukARS+jcU Rc34QePhRC0KltO+FH/H6qfMNABctGD0CpiwVxK1bpeu0CcsgGhMHpuCXe1K4n/a kaqYIHJl6/T0hGQZ18Cbue8Xgof1hJd9lOPL0rkyA6/jJpp/qyykaUJz+rkrjkOb TGUl+ZaE866srzwSVmEH/Fl2b96mnF8jepf6LNqvfnbla8P96rZAvvU/Avh3yGYs hV0sAgEhcGN3sQ8DeDg23VfLxg5Oo6ExM8oequ/wKTJjznDlt1YDzdLFfip3U3GA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtuddgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekudelveffgfekjefgke dtveeufeevtdevueehveetvdejfeeigefgheekgeehtdenucffohhmrghinhephhhtthhp fihgrdhorhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 62B994E05BF; Tue, 2 Mar 2021 23:56:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: In-Reply-To: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> Date: Wed, 03 Mar 2021 15:56:25 +1100 From: "Martin Thomson" To: secdispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 04:56:55 -0000 What Rich is doing here is good. SAN is dead and we should ensure that our documentation reflects that. (Even at the time of 6125 it was a holdover from a previous era.) Is now the time that we get to talk about other updates to RFC 6125? Because there is no IP-ID reference identity in RFC 6125 and HTTP had to define one just to document what happens in practice: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.ip-id I don't want to get in the way of making actual progress here, but knowing the difficulties with getting 6125 done, it might be safer to do this work in a working group. I have no opinion regarding whether it is a new one or UTA. On Fri, Feb 5, 2021, at 02:43, Salz, Rich wrote: > I would like to present https://datatracker.ietf.org/doc/draft-rsalz-use-san/ > > This updates RFC 6125 to remove commonName as a way to identify the > server; just use subjectAltName. It also limits where the "*" can go > in wildcard certificates. This is a simplification of widely > implemented existing practice. It may even be de facto what's mostly > done. Perhaps the wildcard limitation is controversial and I'd be > willing to remove it. > > 6125 was AD-sponsored. I think this could also be, or perhaps it could > go to UTA. I would not present any slides, and think 10-15 minutes > would be enough time. > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > From nobody Tue Mar 2 21:29:03 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 733603A1961 for ; Tue, 2 Mar 2021 21:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 (2048-bit key) header.d=icloud.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 AHZ-PQifPA-S for ; Tue, 2 Mar 2021 21:29:00 -0800 (PST) Received: from mr85p00im-ztdg06011901.me.com (mr85p00im-ztdg06011901.me.com [17.58.23.198]) (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 352DF3A1960 for ; Tue, 2 Mar 2021 21:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1614749339; bh=uGWtgdViE1Hdu9skjac0TB0oIBbKFXzM1h+d6XSSlxM=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=j/g+EB3bqs7YlM82LolyJ30JIYYXwh051nqXsdnDnQ0ercVN8rLFpjz/7deljc+l3 P2yvkwCk3tJa7n1eFZ77r+fYRXoH1WBniz6edau7MWbqztxIhq6vkmpF8fUSRtnuA8 58stHKvxp/qUgTQeCD4XiYisV5GKCqhSdUNMUSrOTGiT0aHDUj1tRPID/6AAaBmxBR mFqasGN7ca6BOZSi5Heg9mJq3ygBBCZW+WdXvSMZKjdEtMGZmmfwqA99Qz2a2aFdzn lf/7/SZA0Iwzq5SraUaahP2zsqAuVnqy8dDK5znwOOGuYhJQ/WoL/cdbEiTBtGhB3i 2Lzo3xDGvWDBQ== Received: from [17.234.26.21] (unknown [17.234.26.21]) by mr85p00im-ztdg06011901.me.com (Postfix) with ESMTPSA id A45DAA6080A; Wed, 3 Mar 2021 05:28:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Carrick Bartle In-Reply-To: Date: Tue, 2 Mar 2021 21:28:58 -0800 Cc: secdispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FE56DB9-3126-4DFD-9CB1-300C14C8F626@icloud.com> References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> To: Martin Thomson X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-02_08:2021-03-01, 2021-03-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=730 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2103030041 Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 05:29:01 -0000 > SAN is dead=20 Wait, what? Do you mean CN? > On Mar 2, 2021, at 8:56 PM, Martin Thomson wrote: >=20 > What Rich is doing here is good. SAN is dead and we should ensure = that our documentation reflects that. (Even at the time of 6125 it was = a holdover from a previous era.) >=20 > Is now the time that we get to talk about other updates to RFC 6125? = Because there is no IP-ID reference identity in RFC 6125 and HTTP had to = define one just to document what happens in practice: = https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#http= s.ip-id >=20 > I don't want to get in the way of making actual progress here, but = knowing the difficulties with getting 6125 done, it might be safer to do = this work in a working group. I have no opinion regarding whether it is = a new one or UTA. >=20 > On Fri, Feb 5, 2021, at 02:43, Salz, Rich wrote: >> I would like to present = https://datatracker.ietf.org/doc/draft-rsalz-use-san/ >>=20 >> This updates RFC 6125 to remove commonName as a way to identify the=20= >> server; just use subjectAltName. It also limits where the "*" can go=20= >> in wildcard certificates. This is a simplification of widely=20 >> implemented existing practice. It may even be de facto what's mostly=20= >> done. Perhaps the wildcard limitation is controversial and I'd be=20 >> willing to remove it. >>=20 >> 6125 was AD-sponsored. I think this could also be, or perhaps it = could=20 >> go to UTA. I would not present any slides, and think 10-15 minutes=20 >> would be enough time. >>=20 >>=20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >>=20 >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Tue Mar 2 21:55:12 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 557E83A1A02 for ; Tue, 2 Mar 2021 21:55:10 -0800 (PST) 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 x8j35-YR3exv for ; Tue, 2 Mar 2021 21:55:08 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3B0493A1A01 for ; Tue, 2 Mar 2021 21:55:07 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1235t1pE023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Mar 2021 00:55:06 -0500 Date: Tue, 2 Mar 2021 21:55:00 -0800 From: Benjamin Kaduk To: Martin Thomson Cc: secdispatch@ietf.org Message-ID: <20210303055500.GB56617@kduck.mit.edu> References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 05:55:10 -0000 On Wed, Mar 03, 2021 at 03:56:25PM +1100, Martin Thomson wrote: > What Rich is doing here is good. ~~SAN~~CN is dead and we should ensure that our documentation reflects that. (Even at the time of 6125 it was a holdover from a previous era.) > > Is now the time that we get to talk about other updates to RFC 6125? Because there is no IP-ID reference identity in RFC 6125 and HTTP had to define one just to document what happens in practice: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.ip-id I do have a longstanding item in my list of things to do for updating 6125 in this manner. (Note that https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-25#section-4.4.1 has also had to define an IPADDR-ID.) I *also* have a longstanding item in my list for doing something analogous to 6125 but for client authentication. That, however, is a much more open-ended question that should be a separate effort. > I don't want to get in the way of making actual progress here, but knowing the difficulties with getting 6125 done, it might be safer to do this work in a working group. I have no opinion regarding whether it is a new one or UTA. I am hopeful that the UTA chairs can provide some thoughts here. -Ben > On Fri, Feb 5, 2021, at 02:43, Salz, Rich wrote: > > I would like to present https://datatracker.ietf.org/doc/draft-rsalz-use-san/ > > > > This updates RFC 6125 to remove commonName as a way to identify the > > server; just use subjectAltName. It also limits where the "*" can go > > in wildcard certificates. This is a simplification of widely > > implemented existing practice. It may even be de facto what's mostly > > done. Perhaps the wildcard limitation is controversial and I'd be > > willing to remove it. > > > > 6125 was AD-sponsored. I think this could also be, or perhaps it could > > go to UTA. I would not present any slides, and think 10-15 minutes > > would be enough time. > > > > > > _______________________________________________ > > Secdispatch mailing list > > Secdispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/secdispatch > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Wed Mar 3 05:32:30 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 2F8B13A115C for ; Wed, 3 Mar 2021 05:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=ericsson.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 m8lpB0xqntDc for ; Wed, 3 Mar 2021 05:32:27 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60044.outbound.protection.outlook.com [40.107.6.44]) (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 35C473A115A for ; Wed, 3 Mar 2021 05:32:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iDlQBMbVKkJSFCaWiGkOX1mSF0+HqzW7RsqzrUNumC1H1M0e+euBpTi1HYDycfGB5Ch2rlfJMvTbat28dRuizbt0FhQehAy97TWgLhUbemV1DpI7YLCBkAufOmuld6l6mk24ZGduVp9wx1cbVnqUTnv6MkL/z6y52sw1Mk18McPkzSSXMLCUqEs7mYThSLXVYe0jgIwoT/BnUYq1zgnkgMQXdQY4/wjQgQE7waMEpViKuv3tOKg6MitDma98AYy7U1F7swUNscbYnsVfc1vrLQqpI6VMtvLqtHdFA2DwF9S6r58RhKDsKQQeX2SH55qfkRgoxJIP1VG1XxsErHRPlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AQ+c/Sy+McP83KQZvfcKJmNVlFGGwGGHtVJy8KGx7X0=; b=kay9bU397I3ujODgOL3BJzv9fH4kAyrC2R6Gols35yeyssY/JErK9Dr954voype+dfTMel0/icDMDJpouAAA30ilVIvN9v2Eb0yME10VDOz6G2EPidkOEDIgpTpULcm+JH1TgKyZIFpcO2gHi+DiD/uoClVnGeNV+dAoy+i2E+z97HYvi3MLlFnT3SsfaLipyS55qlL72oR1p+frJVFaHkZWEckgh3ywH/kXIXJM7Ykgabaz7JcvlQyqXdMLu7d6Oj1E/5GZJMWHej5WrobsiODbVqCvsxSBWUiprC0gnx+HuM3Tg4olZH82hQqfnXAcbekB1JY3CszxVBgfICLSIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AQ+c/Sy+McP83KQZvfcKJmNVlFGGwGGHtVJy8KGx7X0=; b=jUfgPJRuHoO0yw7i1yS+i6pqe2Fg8/gVM0pLMnspdNnmtYBuJWGMNwZNDolTAE4AfR58BCyWR/yOwSnSIB/wMHYeWzsr1NVMsz8nkBIRY/JpdG8E/K3YE2FHbx+JUL8HcVzUxih4kiEApyjvJxGjhU+aQqJSmUo9SJPKEc+ousw= Received: from (2603:10a6:3:4b::8) by HE1PR0702MB3610.eurprd07.prod.outlook.com (2603:10a6:7:7f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.8; Wed, 3 Mar 2021 13:32:22 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::69ab:83ff:dd6e:3536]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::69ab:83ff:dd6e:3536%4]) with mapi id 15.20.3912.017; Wed, 3 Mar 2021 13:32:22 +0000 From: John Mattsson To: Benjamin Kaduk , Martin Thomson CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Requesting agenda time for draft-rsalz-use-san Thread-Index: AQHW+wyJezb1AHqFOUaUt+h0/CBr6Kpx3QeAgAAQXgCAAJCMgA== Date: Wed, 3 Mar 2021 13:32:21 +0000 Message-ID: <0475F1DC-2242-44B6-8A70-29A23C1C67E1@ericsson.com> References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> <20210303055500.GB56617@kduck.mit.edu> In-Reply-To: <20210303055500.GB56617@kduck.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: acfc68e8-a3a3-41f7-11e9-08d8de48c662 x-ms-traffictypediagnostic: HE1PR0702MB3610: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: famPfEZDngEZblWh+zJdqILfzNuFr3IqxcWZxt4t2ZpLUfRd+gIENe7DLtY4eoOjL73/Nw4e6BEns3CR+y64gItW8c2z8iH/g96awmHKxbljgYvBmZyr3X8lA7i4QGu5THNs1w79fpZ5x3Bfw6UY1dDJI0qnvK7tR+VmkGbUpmAbOFqkLrDQvsycu2lOZSSkdNVWzz0jSsBB1R1BBSIM7yMg/ZV4+0lrrRA3G17et60WCt5JFcLpPU8FSkV+fjI5U/QTdPVgt/L5I1usWYK3dEa76CjVpbEVQW0DaPUp1kWWSUCAmWV0y7tHiV6b4YietCIw+feiAzkfJnf/4Vhoz0L3HzbavjjoLRcbIXl3zDfIP8uaDLOrecEpz+yJGm2ky+p03pSoe/ja3FHIoNmo3jW7C5qBQlUAlB8RsEdt5BrNgd+HAhA8jEF7uicmJxUi1RWXPFF4i1T7aMDjclACE7cAZ9CgU+J120f9nIi1qjFEcZDvyOkz2wkqFx8pc6ygSOXnR7Y3e8cutoJz2z8LhI44k+oYM7JjTvzdMoKcBihPUhwK95ztIBrVGyEdR2rclzeKSfZCpoPkgpKW6bcbYpQc2A1rkue1f9cduVAyPP6VZJhtNdvzfTpmXJjKrdN3LRr4pSCkyz4rDCMR7chpdA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(366004)(396003)(39860400002)(2616005)(83380400001)(966005)(71200400001)(8936002)(6486002)(36756003)(44832011)(4326008)(2906002)(8676002)(66946007)(6512007)(76116006)(66446008)(66476007)(66556008)(64756008)(478600001)(316002)(110136005)(5660300002)(33656002)(86362001)(6506007)(26005)(186003)(53546011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?c2xGK3FuQmx4WkhlSEROM3lYZkhlSm9Jc1MvdVFDK2w4cmtYN05DRjVxT1ps?= =?utf-8?B?SzYwUnhyeTk1aHNFdmZidUl2Y1gvU1EzOC9rRFQ1YWVOdWwwMUp0T3dmWUhY?= =?utf-8?B?RlhFUVpheURwVUU5RUZFQllBZTlWb001Vm9FdWJaNTRBRFJJZHpqdzRZNCtm?= =?utf-8?B?NStRbXB2Z3dmOG9PK0lEbnNTRW0waEh6L1BZREJaeERzaGgyY0NsaEtkV1Zz?= =?utf-8?B?RHVnU3lZZEZCUHN3VzJodFZ6VStJTFI5SkZNTDVnQzAvSWpobHpmYTBGcWhz?= =?utf-8?B?ODFaQWVjak05WUhNVVlBNzJ3MWVicU01SEZWMkgwSVJ4d1I1UXYxRWdxc0NO?= =?utf-8?B?dElia2FkSnZ3MmRVaG1ncDlIVDlzcUI3bDI3WUJCOFJkcTRpcTJkZzNnQ21h?= =?utf-8?B?NTllc1ZiZnA1R1lwSWk3bzBJcEpqR0M4cndHVGVZQml2clNHSXdyQi9RNkdh?= =?utf-8?B?QlZKRTNJRGhSYnZsYXQ1dGZqUG5wbUlqVkJFSGczRUc5ZlZ5TVRiU3ZydWVU?= =?utf-8?B?RzIxM2JZVHBCc0NyK2RKc3FyazVDTnhLV3k3RFVGLzQyUVJOYjJPMng2Wmpr?= =?utf-8?B?KzdJMGRqVm9QN1QyTWpJNTJ3S2h3VTBlU2hWeGtaVWJxeVlidklpVld2ZWJ6?= =?utf-8?B?RFp0aStqeDNrcHhFVGZKUlloK0hWRzRXVVl5akxHbkJRNC9BblVFcDc1NEZK?= =?utf-8?B?V1dNRWYvM2RpU1ltc1FSUFltSm1QZ0xPbHg5NXFsdGdkVnV3d0p6QWNJd09j?= =?utf-8?B?aGJoem9la0t1a3prQWo0ZUxSTUwvN1JCR0lRWDB5Y2gzRERSa2ZpV0RSWkYy?= =?utf-8?B?U0E3WTNnUTBrT01HRW9sVG1lTW1pcUFVWlp6TDFRbC82eExkRTJPQXZoQXVO?= =?utf-8?B?dkRTeFU4TVVNRElTb1ZJazYrSlQ4Wmp5bFE5UDRXdXJEMWpuRzE2RmFyYnN3?= =?utf-8?B?K0lPUHQ2T2QxcmVub2ZmZVdib3dMVTk5Y0l5SlhPekRRL05KV0Z6TlhtN3l3?= =?utf-8?B?U0xMNDZ4OEowMlB6QTkvS21hZUhoUW5zWTByTnY1N2FMZDY1YUVUWGY4QW80?= =?utf-8?B?Q2hIcTlNU0c3Rll4T3NueFVRWlcxKzZrZEU1ZmErT0RQYW1sbmYxd2IzMTlo?= =?utf-8?B?cFhwMkJwVzZtb0RheUhWTDc5MUM1bUE2QnQ1dU01ZjA4Zm1pa1NjMlU0QXl5?= =?utf-8?B?TkNOVDdHRmFDeUlJYi9oT2FRY0xTRUFFQmNlYTlHaWVtcEhRMDd6TnpYVFpN?= =?utf-8?B?dkpvN2dHNFQ1SVp0L1hnbFhCdEJCMzcwODdFbldBV213MnhaYmxnc2tnZmlk?= =?utf-8?B?bjh2cXNTN1IwckN4bk51YkhYRTc1ZndJS2lBR0REcklWQnc1dmFuYnZRaEkx?= =?utf-8?B?alQ3aHNTdjhaU3R5aWFaTkM5QW5JMWFheGFjVEtXZmxwTGtVQkJZUEpYUDlS?= =?utf-8?B?WkhSNVpKVnJQUlFUS1VXK2dLbmtjVW4zVlM3dW1TMWQ0SkVPUFB6bmhJUEhM?= =?utf-8?B?YnZlY2o3SjVzSm9rUzkyVUJydFNoTUMyd01TdEpTc0QyL0pBRm1VZUI0UUd6?= =?utf-8?B?SkpINmJIYzhSR2IyQkJ3dm9LMTBuQ0JhNndCMVZsaGNZS2J3cnJBZWdGRGZF?= =?utf-8?B?QzZYL2tBak4rUGVEd2hOd2VyL3c0VDNJUG4yekVheldqL0xKQzdJa0dNc0N0?= =?utf-8?B?RmRmRFJZVlZ6T3pLOTdhUkRyZ00yQlpuWWFYUTZUNzErdUdpUFQ3NnJMRUxI?= =?utf-8?Q?DzrBAwQ0qO/yXiFIczqy3LO+naSRdYi67XTB9TF?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5F811FF0BB894249B07D6DF9DCB62B0A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: acfc68e8-a3a3-41f7-11e9-08d8de48c662 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2021 13:32:21.9522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dYopGrmtVS2nd0BtvhnmFPirMBRmssBDbRfa3xoQ6HAV74bGMvAUqdCvA8meLPC28BsdMSA5wDjbsYc35t7lYXq15Y/aDqiHX1bb0E+dMX8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3610 Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 13:32:29 -0000 KzEgZm9yIGRyYWZ0LXJzYWx6LXVzZS1zYW4NCisxIGZvciBCZW4ncyBsaXN0IG9mIHRoaW5ncyB0 byBkbyBmb3IgdXBkYXRpbmcgNjEyNQ0KDQpSRkMgNjEyNSBpcyBpbXBvcnRhbnQuIEkgdGhpbmsg ZHJhZnQtcnNhbHotdXNlLXNhbiBhbmQgQmVuJ3MgbGlzdCBvZiB0aGluZ3MgdG8gZG8gZm9yIHVw ZGF0aW5nIDYxMjUgc2hvdWxkIGJlIHBhcnQgb2YgUkZDNjEyNWJpcyBkb25lIGluIGEgV0cuDQoN CkpvaG4NCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNlY2Rpc3BhdGNo IDxzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQmVuamFtaW4gS2Fk dWsgPGthZHVrQG1pdC5lZHU+DQpEYXRlOiBXZWRuZXNkYXksIDMgTWFyY2ggMjAyMSBhdCAwNjo1 NQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4NCkNjOiAic2VjZGlzcGF0 Y2hAaWV0Zi5vcmciIDxzZWNkaXNwYXRjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbU2VjZGlz cGF0Y2hdIFJlcXVlc3RpbmcgYWdlbmRhIHRpbWUgZm9yIGRyYWZ0LXJzYWx6LXVzZS1zYW4NCg0K T24gV2VkLCBNYXIgMDMsIDIwMjEgYXQgMDM6NTY6MjVQTSArMTEwMCwgTWFydGluIFRob21zb24g d3JvdGU6DQo+IFdoYXQgUmljaCBpcyBkb2luZyBoZXJlIGlzIGdvb2QuICB+flNBTn5+Q04gaXMg ZGVhZCBhbmQgd2Ugc2hvdWxkIGVuc3VyZSB0aGF0IG91ciBkb2N1bWVudGF0aW9uIHJlZmxlY3Rz IHRoYXQuICAoRXZlbiBhdCB0aGUgdGltZSBvZiA2MTI1IGl0IHdhcyBhIGhvbGRvdmVyIGZyb20g YSBwcmV2aW91cyBlcmEuKQ0KPiANCj4gSXMgbm93IHRoZSB0aW1lIHRoYXQgd2UgZ2V0IHRvIHRh bGsgYWJvdXQgb3RoZXIgdXBkYXRlcyB0byBSRkMgNjEyNT8gIEJlY2F1c2UgdGhlcmUgaXMgbm8g SVAtSUQgcmVmZXJlbmNlIGlkZW50aXR5IGluIFJGQyA2MTI1IGFuZCBIVFRQIGhhZCB0byBkZWZp bmUgb25lIGp1c3QgdG8gZG9jdW1lbnQgd2hhdCBoYXBwZW5zIGluIHByYWN0aWNlOiBodHRwczov L3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTZjOThjZjM4LTMzMDNmNjEzLTZjOTg4ZmEz LTg2NjAzODk3M2ExNS1kMDkyZjZiZDA0ZTcyMTY5JnE9MSZlPWFhODAzNDQwLWU4NTctNGRlZS1h NWZlLTNjNGFiOGZmM2U4MSZ1PWh0dHBzJTNBJTJGJTJGaHR0cHdnLm9yZyUyRmh0dHAtY29yZSUy RmRyYWZ0LWlldGYtaHR0cGJpcy1zZW1hbnRpY3MtbGF0ZXN0Lmh0bWwlMjNodHRwcy5pcC1pZA0K DQpJIGRvIGhhdmUgYSBsb25nc3RhbmRpbmcgaXRlbSBpbiBteSBsaXN0IG9mIHRoaW5ncyB0byBk byBmb3IgdXBkYXRpbmcgNjEyNQ0KaW4gdGhpcyBtYW5uZXIuICAoTm90ZSB0aGF0DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kdG4tdGNwY2x2NC0yNSNzZWN0aW9uLTQu NC4xIGhhcw0KYWxzbyBoYWQgdG8gZGVmaW5lIGFuIElQQUREUi1JRC4pDQoNCkkgKmFsc28qIGhh dmUgYSBsb25nc3RhbmRpbmcgaXRlbSBpbiBteSBsaXN0IGZvciBkb2luZyBzb21ldGhpbmcgYW5h bG9nb3VzDQp0byA2MTI1IGJ1dCBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiAgVGhhdCwgaG93 ZXZlciwgaXMgYSBtdWNoIG1vcmUNCm9wZW4tZW5kZWQgcXVlc3Rpb24gdGhhdCBzaG91bGQgYmUg YSBzZXBhcmF0ZSBlZmZvcnQuDQoNCj4gSSBkb24ndCB3YW50IHRvIGdldCBpbiB0aGUgd2F5IG9m IG1ha2luZyBhY3R1YWwgcHJvZ3Jlc3MgaGVyZSwgYnV0IGtub3dpbmcgdGhlIGRpZmZpY3VsdGll cyB3aXRoIGdldHRpbmcgNjEyNSBkb25lLCBpdCBtaWdodCBiZSBzYWZlciB0byBkbyB0aGlzIHdv cmsgaW4gYSB3b3JraW5nIGdyb3VwLiAgSSBoYXZlIG5vIG9waW5pb24gcmVnYXJkaW5nIHdoZXRo ZXIgaXQgaXMgYSBuZXcgb25lIG9yIFVUQS4NCg0KSSBhbSBob3BlZnVsIHRoYXQgdGhlIFVUQSBj aGFpcnMgY2FuIHByb3ZpZGUgc29tZSB0aG91Z2h0cyBoZXJlLg0KDQotQmVuDQoNCj4gT24gRnJp LCBGZWIgNSwgMjAyMSwgYXQgMDI6NDMsIFNhbHosIFJpY2ggd3JvdGU6DQo+ID4gSSB3b3VsZCBs aWtlIHRvIHByZXNlbnQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnNh bHotdXNlLXNhbi8NCj4gPiANCj4gPiBUaGlzIHVwZGF0ZXMgUkZDIDYxMjUgdG8gcmVtb3ZlIGNv bW1vbk5hbWUgYXMgYSB3YXkgdG8gaWRlbnRpZnkgdGhlIA0KPiA+IHNlcnZlcjsganVzdCB1c2Ug c3ViamVjdEFsdE5hbWUuICBJdCBhbHNvIGxpbWl0cyB3aGVyZSB0aGUgIioiIGNhbiBnbyANCj4g PiBpbiB3aWxkY2FyZCBjZXJ0aWZpY2F0ZXMuIFRoaXMgaXMgYSBzaW1wbGlmaWNhdGlvbiBvZiB3 aWRlbHkgDQo+ID4gaW1wbGVtZW50ZWQgZXhpc3RpbmcgcHJhY3RpY2UuIEl0IG1heSBldmVuIGJl IGRlIGZhY3RvIHdoYXQncyBtb3N0bHkgDQo+ID4gZG9uZS4gUGVyaGFwcyB0aGUgd2lsZGNhcmQg bGltaXRhdGlvbiBpcyBjb250cm92ZXJzaWFsIGFuZCBJJ2QgYmUgDQo+ID4gd2lsbGluZyB0byBy ZW1vdmUgaXQuDQo+ID4gDQo+ID4gNjEyNSB3YXMgQUQtc3BvbnNvcmVkLiBJIHRoaW5rIHRoaXMg Y291bGQgYWxzbyBiZSwgb3IgcGVyaGFwcyBpdCBjb3VsZCANCj4gPiBnbyB0byBVVEEuIEkgd291 bGQgbm90IHByZXNlbnQgYW55IHNsaWRlcywgYW5kIHRoaW5rIDEwLTE1IG1pbnV0ZXMgDQo+ID4g d291bGQgYmUgZW5vdWdoIHRpbWUuDQo+ID4gIA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gU2VjZGlzcGF0Y2ggbWFpbGluZyBs aXN0DQo+ID4gU2VjZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNlY2Rpc3BhdGNoIG1haWxpbmcgbGlz dA0KPiBTZWNkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpTZWNkaXNwYXRjaCBtYWlsaW5nIGxpc3QNClNlY2Rpc3BhdGNoQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNo DQoNCg== From nobody Wed Mar 3 08:09:42 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 4231A3A15B6 for ; Wed, 3 Mar 2021 08:09:40 -0800 (PST) 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 uALqKMCM1jaY for ; Wed, 3 Mar 2021 08:09:37 -0800 (PST) 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 A5EFE3A15B4 for ; Wed, 3 Mar 2021 08:09:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 93B67389A5; Wed, 3 Mar 2021 11:14:13 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QzrSXB2btuda; Wed, 3 Mar 2021 11:14:12 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B769838995; Wed, 3 Mar 2021 11:14:12 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 04072885; Wed, 3 Mar 2021 11:09:35 -0500 (EST) From: Michael Richardson To: "Martin Thomson" , secdispatch@ietf.org In-Reply-To: References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> 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] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 16:09:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Martin Thomson wrote: > What Rich is doing here is good. SAN is dead and we should ensure th= at > our documentation reflects that. (Even at the time of 6125 it was a > holdover from a previous era.) I agree. The question is: how do we hold the funeral and memorial service? That is, how long is the tail? https://datatracker.ietf.org/doc/draft-rsalz-use-san/ is short and sweet, a= nd we could easily publish it pretty much as is, and we'd get somewhere. It seems that clients must take the first step here. The major browsers all auto-update, and so if this isn't out there already, could be out there within six months. Libcurl is in ubiquitous use out there operating m2m transfers of many kind= s. **It is unclear to me if there is any work to do** Pretty much all these things already look at SAN, so the lack of CN shouldn= 't be an issue, except for some communications out there where there is a SAN = missing. I suspect that this is mostly in the roll-your-own situation. I'd like the document to give an Implementation or Deployment overview. This would be particularly useful to re-assure managers about removing CN from their certificates. Let me say that it's really frustrated for embedded system builders to wind up in a situation where they can't get a security patch installed because moving to the next version has a disconnect like this. They may require that they update a long-installed system, and they can't g= et the server side updated with SAN, because that system is also on a long lifespan update cycle. I've watched this both from within a team and outside. Within the team, I've lost the battle of, "we need to be control our destin= y" argument, i.e. that is "we need to build it all from source so we can backport patches". {That team still has Ubuntu Hardy devices in the field which have no updates in a decade. Fortunately, the hardware is dyin= g, and some of the customers have replaced 1000 devices at a time with a competing solution} > Is now the time that we get to talk about other updates to RFC 6125? > Because there is no IP-ID reference identity in RFC 6125 and HTTP had > to define one just to document what happens in practice: > https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html= #https.ip-id > I don't want to get in the way of making actual progress here, but > knowing the difficulties with getting 6125 done, it might be safer to > do this work in a working group. I have no opinion regarding whether > it is a new one or UTA. Yeah, "better is the enemy of good enough" I suggest that we publish https://datatracker.ietf.org/doc/draft-rsalz-use-= san/ as is. I think that it's short enough that AD sponsor is enough. I suggest that RFC6125 deserves to advance to Internet Standard, and it mig= ht require a revision to get there. I feel the same way about RFC5280. LAMPS seems like the right place to do this, but maybe there are other opinions. =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+93Q3WUFAmA/tL4ACgkQgItw+93Q 3WUsYAf/cMu4k0ODrhq8yiPHhaT0uln1XNlZdGiJQajSadt5rgpd5jt1oylcYmLX sA5EmXqi0+45LF5Gh7Cj1Hrz2DoWq2TVRJR9tWJmtDo/9hGqkUzsbcn68JxJCRPj xBfMiFejPe6NK2Hy3Vjj6bfQIxCXxEOli0KmnqdBi5aaCCZXy4reIgnuGfCTftxA Yxvh+YF/roXXRsOcTt9/kAapBFtgvmwnWIjNok+uVaIfBkQuHYITh0PzvSPLLbeF 66NT8fMPOzc88MsFCAsFLNEQX7AGU/0L+e4PgP60WyGlDJwoZLt8j1kjDqz+4ssd h0nTaZ/W50q8nNPtIJ1OmSAJF0YLrg== =q+U3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 3 08:29:36 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 2DA073A1604 for ; Wed, 3 Mar 2021 08:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 p4Gdd53Ao_e2 for ; Wed, 3 Mar 2021 08:29:33 -0800 (PST) Received: from dog.elm.relay.mailchannels.net (dog.elm.relay.mailchannels.net [23.83.212.48]) (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 CE43D3A1603 for ; Wed, 3 Mar 2021 08:29:32 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0AC397030E0; Wed, 3 Mar 2021 16:21:19 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-105-161-82.trex.outbound.svc.cluster.local [100.105.161.82]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C2DF070312B; Wed, 3 Mar 2021 16:21:18 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.105.161.82 (trex/6.0.2); Wed, 03 Mar 2021 16:21:18 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arithmetic-Stupid: 4521a7bf079f91c1_1614788478863_3987752677 X-MC-Loop-Signature: 1614788478863:1630779557 X-MC-Ingress-Time: 1614788478863 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id 86D587EF38; Wed, 3 Mar 2021 08:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0BFKiyDSdK1143 qjS4VRi0EdPdc=; b=q9758LduevIE6WnVFcrNGNZLjJg3KAdThih5yifT7WisAJ wW9AXngCa2tvfvTkVYL4x0VZtBR6svIdwjBa8NeOaua8DQ7OZYlnm4IPhpcplLUp EhEE9onb3NbDx8cV4uF4SpfRreDvMQTOrsRZekx1AEXNtwHZH2/Q1NxS/3qpI= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id C813C7EFBD; Wed, 3 Mar 2021 08:21:16 -0800 (PST) Date: Wed, 3 Mar 2021 10:21:14 -0600 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Carrick Bartle Cc: Martin Thomson , secdispatch@ietf.org Message-ID: <20210303162113.GI30153@localhost> References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> <5FE56DB9-3126-4DFD-9CB1-300C14C8F626@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FE56DB9-3126-4DFD-9CB1-300C14C8F626@icloud.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 16:29:34 -0000 On Tue, Mar 02, 2021 at 09:28:58PM -0800, Carrick Bartle wrote: > > SAN is dead > > Wait, what? Do you mean CN? Question seconded. From nobody Wed Mar 3 10:11:37 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 8B2493A17D0 for ; Wed, 3 Mar 2021 10:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FDtXTtRg3cX9 for ; Wed, 3 Mar 2021 10:11:33 -0800 (PST) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (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 D1F3F3A17CA for ; Wed, 3 Mar 2021 10:11:33 -0800 (PST) Received: by mail-yb1-f173.google.com with SMTP id u3so25523911ybk.6 for ; Wed, 03 Mar 2021 10:11:33 -0800 (PST) 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=A/Dus6peZbLDdqErjMW/hY9biA+GBMITV5XGqaXkpSE=; b=QcbicDqg3MwXrQhy7ypCCvS9lPLBmm7nrFyQgeB6T1TQl0iAStZQ/cm3uYyIdgyqOz y7eYFL/YDtjh2MkauJQWj4A/Bys78djbw6DS9bms1G1y80MupSnPYiTbTUCzbU5qI2XR j4sCpYn+ywwF1OoWugXTChks/wfx2JR9dRQAcihWdYQ46kQZkb1pkH4FWunUjAu4KSoQ 9nRPZIsDuRYYx250U+jXD8mNQDL0QpYju3jQV1bZgJohTrdGYrMj8130ri0OJqk5FnOm U2Nmvwi3pT23OS815S11+wS1tolfXxpzfeOA3PbpdrHvWvtI/cyJebwXvrZl08AIhIXP GD1g== X-Gm-Message-State: AOAM53329Y8G9QOw6hKsnvSzrCkHlpKZ76XfBLGF09M9UD6WqNYL+FlT LERTAKMNFFtAytVTljQsCoJ5QC5jfpiEZU7GHrRoINwN8ZQ2Mw== X-Google-Smtp-Source: ABdhPJyjiHkh5HHd0J+LOi76pQY/aMi8TQC+kEQn7FjRFKLtlgz3Yqe49pjUD5bnLVjpSPiRqB4f2TNAfGny9lE+4NM= X-Received: by 2002:a25:50d8:: with SMTP id e207mr721066ybb.56.1614795093033; Wed, 03 Mar 2021 10:11:33 -0800 (PST) MIME-Version: 1.0 References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> In-Reply-To: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> From: Phillip Hallam-Baker Date: Wed, 3 Mar 2021 13:11:22 -0500 Message-ID: To: "Salz, Rich" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e7c68305bca5c7da" Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 18:11:36 -0000 --000000000000e7c68305bca5c7da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did a quick look at what CABForum has on this. They are in the same state= . Given that CABForum has the ability to actually enforce a profile and given that this has been in place since we EOLed RSA1024, it is highly unlikely that there are any browsers currently in use that rely on the CN field. These are the EV guidelines but I doubt anyone does different for DV. This change should be synchronized with CABForum if people want this properly dead. https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.7= .0.pdf Contents: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject=E2=80=99= s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under Appendix F. On Thu, Feb 4, 2021 at 10:44 AM Salz, Rich wrote: > I would like to present > https://datatracker.ietf.org/doc/draft-rsalz-use-san/ > > This updates RFC 6125 to remove commonName as a way to identify the > server; just use subjectAltName. It also limits where the "*" can go in > wildcard certificates. This is a simplification of widely implemented > existing practice. It may even be de facto what's mostly done. Perhaps th= e > wildcard limitation is controversial and I'd be willing to remove it. > > 6125 was AD-sponsored. I think this could also be, or perhaps it could go > to UTA. I would not present any slides, and think 10-15 minutes would be > enough time. > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000e7c68305bca5c7da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I d= id a quick look at what CABForum has on this. They are in the same state.

Given that CABForum has th= e ability to actually enforce a profile and given that this has been in pla= ce since we EOLed RSA1024, it is highly unlikely that there are any browser= s currently in use that rely on the CN field.=C2=A0

These are the EV guidelines but I doubt anyone d= oes different for DV.

Thi= s change should be synchronized with CABForum if people want this properly = dead.



=
Contents: If present= , this field MUST contain a single Domain Name(s) owned or controlled by th= e Subject and to be associated with the Subject=E2=80=99s server. Such server MAY be owned and = operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates= except as permitted under Appendix F.=C2=A0=C2=A0

On Thu, Feb 4, = 2021 at 10:44 AM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
I would like to present https://datatracker.ietf.org/doc/draft-rsalz-use-san/
This updates RFC 6125 to remove commonName as a way to identify the server;= just use subjectAltName.=C2=A0 It also limits where the "*" can = go in wildcard certificates. This is a simplification of widely implemented= existing practice. It may even be de facto what's mostly done. Perhaps= the wildcard limitation is controversial and I'd be willing to remove = it.

6125 was AD-sponsored. I think this could also be, or perhaps it could go t= o UTA. I would not present any slides, and think 10-15 minutes would be eno= ugh time.


_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000e7c68305bca5c7da-- From nobody Wed Mar 3 14:38: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 79F843A1C82 for ; Wed, 3 Mar 2021 14:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=lowentropy.net header.b=Sn8H8+4D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DG74ggqG 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 FXHaiukzgV3W for ; Wed, 3 Mar 2021 14:38:39 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26323A1C86 for ; Wed, 3 Mar 2021 14:38:39 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BDEB818C2; Wed, 3 Mar 2021 17:38:38 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 03 Mar 2021 17:38:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=qh6itQcE7LLsp2OOmEyQMpq/jtRZ bImhpb1bU682MR0=; b=Sn8H8+4DHn0opCAzf7fblOtITj275ocF74lY14lTBc/3 CLDPDLR4XBpjynN03xNXUr92L8Xv6CkrD0WToodFB3wVOpJONqJfRpiYlipYoM8M 2yIcSutkCFVo81SgDT4YvR1LvlcCz9M7gmUVIB+QhbWch/zL3CNQSYz+ZzIIXN58 1/z/8iWUWg+opB05hHHD607iXz1spCyMvn47UgRKYuBO7unW45BVnd59DMTxP/Hg IdXa4Q7ycVFuKbLiIaily321Y6Qg1AC8hzzI5sTJFvOt+LE1r52+MBrMKfjuOUJE /+EYslelUW1kINWsaIcuCFR8hsDzhXMI4gmipKvuUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qh6itQ cE7LLsp2OOmEyQMpq/jtRZbImhpb1bU682MR0=; b=DG74ggqGBRZZAOtW4Ms6Qt LfLnTjUXMJZwaklwn6vVAIsGAyJ3cghj2k8VCH0kuJ6jlCJnyUClvsg3P1gunaZW He9B6pEziWeFK24gDx5oaS2xBEC53IrHcQt1dE4KFGZnKwmjP2eRBsjpwNejFFkL f6JSfefkVSK61+EeTD66u96TO+/Ziqa/exDJoQU0elmsIROLtMZam0G/lGxnu0/G uCeGSBUFsZdQqrGJPl84h78jSNfggGD9I3F7kW8tSIbJdusScgOuVW8VBXWRZxAl E84Hb7iKM5yFNiHIo+Xq4Oc4Km4XoqcczqvQPrOQNMPLCSHWgpKaifwvNRXoPxWw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtfecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhhtihhn ucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrg htthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeegffei gedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D9D254E074F; Wed, 3 Mar 2021 17:38:37 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <9b9855ba-9b49-4a6a-aa17-0bb7fe811f62@www.fastmail.com> In-Reply-To: <5FE56DB9-3126-4DFD-9CB1-300C14C8F626@icloud.com> References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> <5FE56DB9-3126-4DFD-9CB1-300C14C8F626@icloud.com> Date: Thu, 04 Mar 2021 09:38:17 +1100 From: "Martin Thomson" To: "Carrick Bartle" Cc: secdispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 22:38:42 -0000 On Wed, Mar 3, 2021, at 16:28, Carrick Bartle wrote: > > SAN is dead > > Wait, what? Do you mean CN? Wow, nice proofreading failure. Yeah. CN is dead. Long live SAN. From nobody Wed Mar 3 14:42:04 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 6D16D3A1C94 for ; Wed, 3 Mar 2021 14:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=lowentropy.net header.b=QXZrQoaU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oHZAYBww 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 mBVTn8TCF4un for ; Wed, 3 Mar 2021 14:42:00 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE313A1C93 for ; Wed, 3 Mar 2021 14:42:00 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 38A2016D9 for ; Wed, 3 Mar 2021 17:42:00 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 03 Mar 2021 17:42:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=RBsxlsSq9I6C2rTxjqibZPRjudQgEy2 Iy+6MuGa/wAc=; b=QXZrQoaUFoo9WVOYwqBgVuveRBFdTr3NnK18pqVhqzhE1EI QfEKUvjgjFnuJ0b0BlucpdvwHNS+t3N39bT5lY6C4hUaaMZ5VQNcJN8/JH6C+CaF G1xYi3zcuPunU45UfA/VweBQIFeUG5UCtm76PEYSycU2rK0Go0YCrezQH62lQw99 8JqN7VikoH6T0iezN2OCAEDHTFKjdFyaYT0EgYI82p/h9y8ACOvY0OwJAK4il/JZ J5hl3sWH0C+jnXsRSp0yMgFNk+mtNlYxHoitsUKysgdKEgT/FKU7ffJf+Hu/n5Um mCTh3U1PClVf36jIFDPp8anlFgRa7b+0QM232TA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RBsxls Sq9I6C2rTxjqibZPRjudQgEy2Iy+6MuGa/wAc=; b=oHZAYBwwu3knOCNqHtWlCs Br4eOVzfrHkXf2oBiSPeMVfuW8mVPly28PilBd3TI1H71p36z168EoBT8lZht7wO VJqVNYXgt9JRd8bqaX0tGcRE2m7aVdN9BU/gxgTPuKVaUN8THyT3F2dvv3T8KCVk g24RQCElf+CfvuE7RI8ycUCtqPfvVSfB2Lq8+pfYGggt+qB99cucAb9G5rfW8yLn 26cvqEw9Z7+aI4ROUMVPeZcdxmZwdyLBHVO53FZE+uxt27a17PS34eeKJk3BTCC2 O+1X/5sKvi4ruJiq/yn4MTB3wjgvKO7WBUZOzX9mvFtLdBVn9uPL0qTeXeKiYWHw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtfedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8A52F4E0751; Wed, 3 Mar 2021 17:41:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <3a753ee2-4535-4fa5-be72-ee3372b01acf@www.fastmail.com> In-Reply-To: References: <619EB16E-48E6-459A-A63A-18A805F75D34@akamai.com> Date: Thu, 04 Mar 2021 09:41:40 +1100 From: "Martin Thomson" To: secdispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Secdispatch] Requesting agenda time for draft-rsalz-use-san 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, 03 Mar 2021 22:42:03 -0000 On Thu, Mar 4, 2021, at 05:11, Phillip Hallam-Baker wrote: > This change should be synchronized with CABForum if people want this > properly dead. I propose we just do this and then tell them. I can talk to our representative, and we can encourage others to do. But the BRs are already pretty good on this point. A motion to expunge the backward-compatibility clause is all they really need to do, but I don't see them as being obligated to do that. It's OK if they don't. From nobody Thu Mar 4 11:20: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 02A643A14C5 for ; Thu, 4 Mar 2021 11:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=cert.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 EXRJTa4H31Fo for ; Thu, 4 Mar 2021 11:20:21 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 A7BFF3A14C4 for ; Thu, 4 Mar 2021 11:20:21 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 124JKJXv047621 for ; Thu, 4 Mar 2021 14:20:20 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 124JKJXv047621 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1614885620; bh=YGjw/aiZBUnkOI3dLDwYGMBC3hzXuxGZoJ/zA2mZHrU=; h=From:To:Subject:Date:From; b=hfJlflp5MUrYkKD3P5L8qzriVa82rnhKUCQv6Tt8Dt5+TRxGQsfTu9LBmlMsV6vWK hWTYjbQ6pCsFJWrqSbtZJTps0lX842LEt5VGpRatZlYg7RbiabRVHIW0vUtD0o4Nhx UiSGyVSvUHQKnDRf0G/zv97iaKmgzr1/RPM/3XlA= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 124JKI5x042589 for ; Thu, 4 Mar 2021 14:20:18 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Mar 2021 14:20:18 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.013; Thu, 4 Mar 2021 14:20:18 -0500 From: Roman Danyliw To: "secdispatch@ietf.org" Thread-Topic: Leadership changes for the WG Thread-Index: AdcRK2HvS63G3bVkRIy3tvCcsKaibw== Date: Thu, 4 Mar 2021 19:20:17 +0000 Message-ID: <48a524e361be4337ad06f224c0d85f8f@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Secdispatch] Leadership changes for the WG 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: Thu, 04 Mar 2021 19:20:23 -0000 Hi! Please join me in thanking Francesca Palombini for her leadership as co-cha= ir of SecDispatch as she departs to officially joins the IESG next week. I= n particular, she leaves the WG processes improved from where they started = by instituting clearer input guidance to work to be considered in the Secur= ity Area. In turn, please join me in welcoming Mohit Sethi as the new co-chair of Sec= Dispatch. He brings not only various chairing experience but also a broad = view of work across the IETF. Regards, Roman and Ben From nobody Mon Mar 8 05:09:15 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 D68463A2A39 for ; Mon, 8 Mar 2021 05:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uhasselt.be 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 YpTiMzTOvzub for ; Mon, 8 Mar 2021 05:09:06 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 9D5D43A29B0 for ; Mon, 8 Mar 2021 05:09:02 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id u14so11403983wri.3 for ; Mon, 08 Mar 2021 05:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:from:date:message-id:subject:to; bh=QOOcwmkdsWJm3i5wDT0GEV9rSzFm0DEFTHF8OvGnALE=; b=k9dGMXlAs9vsaDPT8RlykmZ5xsKAhpOBJqtxpZyhmejsDzJw2HgXXjqDUnuvo2EOBM ITun2jtUzSyUOHlQZrjOETDJh79viHYD4/HfKfE8U1Ch9p8WyD5cAAFOCs3Y4bxsqzhQ tpRTK0KQUpwwjzAXkPy+fIgs2kWM1ez3MOIjc= 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; bh=QOOcwmkdsWJm3i5wDT0GEV9rSzFm0DEFTHF8OvGnALE=; b=Trw+nV074eyYBjWU16lo9u3YEsMvTtPe9qY817lJ6wTfKZhraufnZCHvHWZLyO0bGI QXAJ9QCcIMhFvbn2dARaJ1kc24N9oqdBwYYlaKRa7r4df6J1n6MgxA0I+b9hF2N5nPSY XUdBXw1ltChfiOndwKq1bxcHcXfHAod7MJplW59ljDcy/chkh1yVT6vKt4m1iPTx7Nwp QOP29DlCAbnURyIaQYo61jsiwKSqRb1aSG7C0pw5weObLWsyGk8d1yKx2eNJlGQYgFTt Q2LngdVmkOCTM7bEFaPzJUJtrb56t+McW3y4aqBxg2UXiOIUkFyLm3Vd5KofYgQrLsqg 0htQ== X-Gm-Message-State: AOAM531mavHE8S6ANBpTczWCLHZYvjYK9m/qWIFyNgAkpIdH4FUpIORL cBy28s8M4QdR3T5CIEd1XZv2T3ERSDbMPl5rmv3W3wyvchcGVA== X-Google-Smtp-Source: ABdhPJyuN+ccy7ii6JLPTepEi9TjJwthAhgjXFL3y1/B9A4xpWlyZpR79ppIz0hlzFPzxjkGp8SMeDx9wFcp5iOUmLc= X-Received: by 2002:a5d:430a:: with SMTP id h10mr23621346wrq.162.1615208939818; Mon, 08 Mar 2021 05:08:59 -0800 (PST) MIME-Version: 1.0 From: Robin MARX Date: Mon, 8 Mar 2021 14:08:46 +0100 Message-ID: To: saag@ietf.org, secdispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000189fbe05bd062330" Archived-At: Subject: [Secdispatch] Introduction to qlog 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: Mon, 08 Mar 2021 13:09:15 -0000 --000000000000189fbe05bd062330 Content-Type: text/plain; charset="UTF-8" Hello saag and secdispatch, On Thursday, I have a slot during the saag meeting to talk with you about the qlog project. Since this is the first time this is discussed in this wg, and because it might be of interest to secdispatch as well, your chairs asked me to do a small introduction via the mailing list in preparation. qlog [1][2] started off as a way to do logging for HTTP/3 and QUIC (hence Quic LOGging). As QUIC encrypts almost all of its metadata, utilizing packet captures for analysis almost always requires full decryption of application (user) data as well, leading to potential scalability and especially privacy issues. As such, qlog instead proposes logging protocol metadata at the "endpoints"/implementations directly (e.g., client, server, load balancer, ...), where only the necessary (and properly anonymized) metadata can be recorded. This approach additionally allows the inclusion of events typically not seen on the wire, such as congestion control behaviour. All events are recorded in a structured format (currently JSON) using a fixed schema to make it easier to write cross-implementation tooling. This approach has since found some success for QUIC and HTTP/3, with the majority of implementations supporting the format [3] (or something similar) and actively using its associated qvis tooling [4] to debug and analyse implementations and deployments. As such, the qlog drafts are on track to be adopted by the QUIC wg following their re-charter after delivering QUIC v1 in the coming months. However, it is clear that qlog's basic principles (mainly: structured logging at endpoints) can be useful for many other (encrypted) protocols besides QUIC and HTTP/3 as well. As such, while for practical reasons the continued qlog work will happen in the QUIC wg, the goal is to define it as a protocol-agnostic framework, complete with guidelines to add event definitions for new protocols. This can already be seen in the current split in two drafts: the first defines a general-purpose schema with the format and high-level metadata [1], while the QUIC and HTTP/3-specific events are in the second document [2]. The idea would be to have different documents for additional protocols added in the future. In order to make sure qlog can indeed eventually be used as a substrate for many different protocols and use cases, we are now already soliciting feedback and insights from the wider IETF community. My presentation on qlog will give a bit more details on qlog, how it has been used in practice and about the main open challenges we hope you can help us with. It will hopefully also entice some of you to join the later discussions in the QUIC wg as well, of course ;) See you all on Thursday! With best regards, Robin [1]: https://datatracker.ietf.org/doc/draft-marx-qlog-main-schema/ [2]: https://datatracker.ietf.org/doc/draft-marx-qlog-event-definitions-quic-h3/ [3]: https://qlog.edm.uhasselt.be/anrw/files/DebuggingQUICWithQlog_Marx_final_21jun2020.pdf [4]: https://qvis.quictools.info -- dr. Robin Marx Postdoc researcher - Web protocols Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --000000000000189fbe05bd062330 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello=C2=A0saag and secdispatch,

On Thursday, I have a slot during the saag meetin= g to talk with you about the qlog project.=C2=A0
Since this is th= e first time this is discussed in this wg, and because it might be of inter= est to secdispatch as well, your chairs asked me to do a small introduction= via the mailing list in preparation.

qlog [1][2] = started off as a way to do logging for HTTP/3 and QUIC (hence Quic LOGging)= .
As QUIC encrypts almost all of its metadata, utilizing packet c= aptures for analysis almost always requires full decryption of application = (user) data as well, leading to potential scalability and especially privac= y issues.=C2=A0

As such, qlog instead proposes log= ging protocol metadata at the "endpoints"/implementations directl= y (e.g., client, server, load balancer, ...), where only the necessary (and= properly anonymized)=C2=A0metadata can be recorded.=C2=A0
This a= pproach additionally allows the inclusion of events typically not seen on t= he wire, such as congestion control behaviour.=C2=A0
All events a= re recorded in a structured format (currently JSON) using a fixed schema to= make it easier to write cross-implementation tooling.=C2=A0

=
This approach has since found some success for QUIC and HTTP/3, = with the majority of implementations supporting the format [3] (or somethin= g similar) and actively using its associated qvis tooling [4] to debug and = analyse implementations and deployments.
As such, the=C2=A0qlog d= rafts are on track to be adopted by the QUIC wg following their re-charter = after delivering QUIC v1 in the coming months.=C2=A0

However, it is clear that qlog's=C2=A0basic principles (mainly: stru= ctured logging at endpoints) can be useful for many other (encrypted) proto= cols besides QUIC and HTTP/3 as well.=C2=A0
As such, while for pr= actical reasons the continued qlog work will happen in the QUIC wg, the goa= l is to define it as a protocol-agnostic framework, complete with guideline= s to add event definitions for new protocols.
This can already be= seen in the current split in two drafts: the first defines a general-purpo= se schema with the format and high-level metadata [1], while the QUIC and H= TTP/3-specific events are in the second document [2].=C2=A0
The i= dea would be to have different documents for additional protocols added in = the future.=C2=A0

In order to make sure qlog can i= ndeed eventually be used as a substrate for many different protocols and us= e cases, we are now already soliciting=C2=A0feedback and insights from the = wider IETF community.
My presentation on qlog will give a bit mor= e details on qlog, how it has been used in practice and about the main open= challenges we hope you can help us with.=C2=A0
It will hopefully= also entice some of you to join the later discussions in the QUIC wg as we= ll, of course ;)=C2=A0

See you all on Thursday!
With best regards,
Robin

[1]:=C2=A0https://datatracker.ietf.org/doc/draft-marx-qlog-main-schema= /
[2]:=C2=A0https://datatracker.ietf.= org/doc/draft-marx-qlog-event-definitions-quic-h3/

--

<= /tr>Agoralaan Gebouw D - B-= 3590 Diepenbeek --000000000000189fbe05bd062330-- From nobody Wed Mar 10 04:38:59 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 B46073A08E4 for ; Wed, 10 Mar 2021 04:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.897 X-Spam-Level: X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=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 j19ZSyW3BoPr for ; Wed, 10 Mar 2021 04:38:56 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AF43A08C5 for ; Wed, 10 Mar 2021 04:38:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 32841300B72 for ; Wed, 10 Mar 2021 07:38:53 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fVnXx30VbAst for ; Wed, 10 Mar 2021 07:38:51 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id AEBE0300AE5 for ; Wed, 10 Mar 2021 07:38:51 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: <5747BBF6-F72F-4905-9D3D-1C900B529C17@vigilsec.com> Date: Wed, 10 Mar 2021 07:38:51 -0500 To: IETF SecDispatch X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [Secdispatch] draft-housley-ers-asn1-modules 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, 10 Mar 2021 12:38:58 -0000 https://datatracker.ietf.org/doc/draft-housley-ers-asn1-modules/ Some developers would like the IETF to use the latest version of ASN.1 = in its standards. This document provides alternate ASN.1 modules to = assist in that goal. The Evidence Record Syntax (ERS) [RFC4998] provides two ASN.1 modules, = one using the 1988 syntax, which has been deprecated by the ITU-T, and = another one using the 2002 syntax, which continued to be maintained and = enhanced. This document provides an alternate ASN.1 module that follows = the conventions established in [RFC5911], [RFC5912], and [RFC6268]. In addition, [RFC5276] specifies the mechanism for conveying Evidence = Records in the Server-Based Certificate Validation Protocol (SCVP) = [RFC5055]. There is only one ASN.1 module in [RFC5276], and it uses the = 1988 syntax. This document provides an alternate ASN.1 module using the = 2002 syntax and follows the conventions established in [RFC5911], = [RFC5912], and [RFC6268]. Note that [RFC5912] already includes an = alternate ASN.1 module for SCVP [RFC5055]. The original ASN.1 modules get some of their definitions from places = outside the RFC series. Some of the referenced definitions are somewhat = difficult to find. The alternate ASN.1 modules offered in this document = stand on their own when combined with the modules in [RFC5911], = [RFC5912], and [RFC6268]. The alternate ASN.1 modules produce the same bits-on-the wire as the = original ones. The alternate ASN.1 modules will be informative; the original ones are = normative. RECOMMENDED WAY FORWARD: AD sponsor an Informational RFC.= From nobody Sat Mar 13 02:15:35 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 D4AB73A0E7E for ; Sat, 13 Mar 2021 02:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=ericsson.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 fSaDvULIr_zT for ; Sat, 13 Mar 2021 02:15:32 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150071.outbound.protection.outlook.com [40.107.15.71]) (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 009D43A0E7F for ; Sat, 13 Mar 2021 02:15:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ScmiWAebt4Gb368nlXxUIhlUf64VeXRc4hE84Qi3yLQ9JzBazoUPJ0TLmbIjz+0YUQY41WSR4HRqV04Zn2hff25ROuqV/TUZGWRqhxftpcJb3uc+v/Ue5p4MiAuQKbuQ54xhNxrLV3AVbIBvKNehiBkTLe21crxyhEac2SRteGhFqAhtxT9NjlZaz1+thcnG6DTadECzEI0iznIbAvZUrhV+HyA0bDa25MIrZnHMtDFayWxwWT9vJQti+DNk//orKdfULfNc+88QyclgW+woC7TvNwW3Ud09Bln/Pz50SEoSlKOE4ia39boIDLHqtzBnzz9iMfG/hS3XD1Xx2jWR2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OslbVwXIWGpommiqbJGkdp3fXtaXgCFRRC6jOiqRExo=; b=NYxfWCWHeNNw5oE00Rm/4+m4DlzbnS46ujDIL5Hsqw9R7FNOQgKHzxjIFPnjpGERVLlGmB6ukIXCdTZKhkxPPGQyOQw1pNAtYZP/nNlZpJQKfG2uE6oFVv6TMsTvkwOAkP6rq6iA+6bn10nkCmLE40NK9t0atCUSMzBRbXIU4Rqf5McvZK3WdHoJqsX7EiTZF+3E3v0GQur4GxaS0lSlLxJ8JGcS5xbmtISP54rcUP4YYOeNghaDa/XCUSO89vubD2tvOHVBVUKv7YbNlBUOHuOI6HBO7NNiu18SYEs4Qtr5xs8x+Pjyn5TDj6CoK2Ze1Ti6x0yCEzDVWOcLWq6qXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OslbVwXIWGpommiqbJGkdp3fXtaXgCFRRC6jOiqRExo=; b=O4PCIrFeEuF5f1/7semKjndmdSfBsmTNMprEjKBp/G//RmS7IwxfywRCcPVk9kWj++WIe1eEFRpvVU7MS2dGVLSl+scnwPDxX0xAeQDYXjy5mR/uoX4WBFXhjNEmzVLnuxz0KOJIF0HEUMT2EqPOp6aKY+IPpygqPSPO7TmR6b4= Received: from HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:37::31) by HE1PR0701MB2508.eurprd07.prod.outlook.com (2603:10a6:3:72::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11; Sat, 13 Mar 2021 10:15:27 +0000 Received: from HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::9028:916a:402e:aa6a]) by HE1PR07MB3436.eurprd07.prod.outlook.com ([fe80::9028:916a:402e:aa6a%6]) with mapi id 15.20.3955.013; Sat, 13 Mar 2021 10:15:27 +0000 From: Mohit Sethi M To: IETF SecDispatch Thread-Topic: Minutes from secdispatch @ IETF 110 Thread-Index: AQHXF/HJ808k+Enx3UOWsYuCtM8v7w== Date: Sat, 13 Mar 2021 10:15:27 +0000 Message-ID: <5ac9f3eb-a350-bed5-8c58-d218479e3d2c@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:180:2ea8:a147:fe00:bc3:2037] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: caf9c735-443a-42e1-e56c-08d8e608ec7c x-ms-traffictypediagnostic: HE1PR0701MB2508: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DVDyqcdX17lpvlMtumyzJtQCAGvAb2eYpSsntX72RExFmZr/5pLo9EL/jmHSmr+rnBtaiqmveWHmLMYtXoTqv/b37qz5mepmP5A0p+N6Vj89JJyl8uCRVwFMjGbTwnJeazMDhozKvggqbvwpo91wRY5pWbLc/Kh7dKcLVdEJJ5jrWZkWzt5glBxcjy39jvVFBSlsjHaO/zeJUCKxZ9rpW/QWNfG1EBMRpwD7RKO1kqtR4JF+uzKwbumgWW7GO4Vfjw6d9mBfUTxoVdqaks5Mg7HpVZ0R9zctUz2N4NkmZOfRIfuxGrZTwnVSaz5tcz52QMgfAg25hO+KZc4pqoi/V4n6VOJEaUibJUC3CuddwK20BaBiGv+AaOApwK/z9malWWLb7Qu35Zdy97Iv5yT27mLIvILZWy8ZkOZ7pJkPMhW6FSBDXh2Ro/dVeY2nmwkHkgzSxhfBCqn0AKCIOq2mu3X5SmVDfwH1yEVWZQvsXzOaSaVT9u2HjqbrfpKBvHba6Cgt6Eh2FZqnQEX3zE/tQm8TzXDW8L2AsZZGrvRKF2HgGKn8SLUhj3nCjNzRK+i1wE0/xzC3fcdkorLq8xcL4OiZP1fm5e+vo+E+7pylwXa24xYp3sdUAF7DROoZkr6bPsHfXbac56mLN0whETg89serDX7np99adm1hfPoluWqgls/imXLg4w2oZCl/L2J1Ne6uMQ9AF22tYEGP5MT6xbLkxq+zkG6W8NT3A2P+4cM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3436.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(376002)(39860400002)(366004)(2906002)(6916009)(66446008)(5660300002)(86362001)(64756008)(966005)(6512007)(316002)(478600001)(4744005)(66556008)(66476007)(71200400001)(186003)(66946007)(8676002)(76116006)(2616005)(36756003)(83380400001)(8936002)(31686004)(31696002)(6506007)(6486002)(43740500002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?R1hDWG55bHlTRm02c0dnOUY0OU5NT05OZ1FpSkRZV29iQVJvTzZwSWVEbDRz?= =?utf-8?B?R3VhWXZrNG9jUS90Z0hSc3hKaStWa2IwbWJrU1B5ZSt3RktjZmJYRjk3YlNp?= =?utf-8?B?K2xTSEJWUHp0WWJ6ajBEaDlldnFOUmdRU284a1AxQWdJeEVUeFcvNHRQajVL?= =?utf-8?B?dTNYek83bG45WkhnNk1WdHFOZ0Qwb1NYOU9jdGdCMkx5cU9hU1JzcFdDdHdD?= =?utf-8?B?NkZGZGFIeENkVUV0eTFpRjJjdmtydDZQWVZLL2dWNEkrKzZ0blIxc0tTeWEr?= =?utf-8?B?aFFHbHd0VnRCUWJzZjQ4RDBFZkJtWnlnU29ESVJGMENHTWlBUkl6Y3N6YnJt?= =?utf-8?B?R1RtNy9GN3BxMlR4c1dSZXB5QjlDWVJPOVdmUUlUYXQ3RWhTYmFqYzhkTWVQ?= =?utf-8?B?dDcxTUNTMzZSNnNRdjAzWUIwbzJRZUQ5aVZZTVlIZ2F3MDdVSWhZdSsyVTF4?= =?utf-8?B?a0ljSE9qSVRkVGdId1lGSG9jTm1hUlFJMkkxRVhKQ2RndzAyWms4eW5BbnpQ?= =?utf-8?B?a0lHREtySFVSMzRvMGdWTFc1WXpFVUFvVHgrMGQyb0VmLzE4dHhKTjI1RnNB?= =?utf-8?B?dWZVYzlINHBTTDIwQmFnWU1nQmV2bkhXb01lemhUMXZzUW1nYXFBWkRhY2o3?= =?utf-8?B?VUZRN2VPUTRDR0kxM2tmV2VWcjZ4SzZpd2VOODhZTnV5M3pJSndsNjU3VDFi?= =?utf-8?B?dTh3Q1d2MDhNcEc2NWdaeFl4NG9YdmlHb29MZmhIZm1iZGIrLzAzS3R5YnRp?= =?utf-8?B?c0Rlc01kYng3TDZSNVFiTjRJeDBWWVN5bElCYmZZT01KNTdhSnhLUWViSlgz?= =?utf-8?B?WUt4NXVtQ3JSMHFQMjA1V0xBa0I0dlRhR09nZVh3UUludlhFY2xtYVpjQnpY?= =?utf-8?B?elcvZWt3RFd5TkRFY2xYbFp0MktNaXFBY09NV1NEQ1lYWWRRSjRPRFl3YTVD?= =?utf-8?B?Y3luMCtlaVpqSGlUT3ZVdEE0aVRFNFlKTSt4QXJPM0h2cXhLUG5BZG1EK3Rm?= =?utf-8?B?UkV3QVo5eHVCdkd4bWJScTV5RlVjd1B1ZCtIS0hySkp6MnowUE8wUmRKYUY1?= =?utf-8?B?QzJDNm8yN1NNZTZrb3MvaTNzMVExdWtKMUN5NzZiSWo4dC9QRm5xaW9jVEFt?= =?utf-8?B?cG5qQmxQUXRFaGZJS3lmTW9WTS9VQ2hjVTJDMmFheDRyUGdXamYybTE0eVJD?= =?utf-8?B?eVdiOW0xYWJhZU9Sc1hSbFFHdWxMMXRWVUJ1TXovVzYrL2Rna29yYlJ4NVV0?= =?utf-8?B?WkVYcjVDYnZqK2xLaVZTRFBCdFcyTGRJd1lyY2R3YXBUVjFqNHdSVytsNHBq?= =?utf-8?B?SEN0VFB1bWI1NDRydjVuMXFaeDhrK2d2UzZQMUsyRWlERnUzcTFVZXZQWEFa?= =?utf-8?B?T3hzRjY3b0RDby9ieW41OG0zQkMyaEtSWVo5M2IvM1A1eUlVQ1VpSEJyVmda?= =?utf-8?B?SXgyNjRTUjNKVGVhWWltYVJvTHlibVdkZG5scXF3SnZrMUN3RG5xTTFFdEE5?= =?utf-8?B?K2FiVjl4Q2Fmd0hlNDJJb0dIay90MDFTM2tJSUV5S1pHQW13RUEyejdMaUlN?= =?utf-8?B?WEVDekNxWTZxajI2NjBpVE1GWXg3Wm12YlJoRUxXYzlEQVhYSTNtNUlnRkhX?= =?utf-8?B?VDFsSGlwQ1lseHIweWRqZHdlWWhvQ0ovd2ovdUh1aVFyUEMwa3JMS3Q0SkJZ?= =?utf-8?B?ZE1mR2ZyQk96eWhwNVI1WFUwM2lXK2hieGtSODBiQzJLaEVTUUUxUTFxSzNi?= =?utf-8?B?U0twZ2ZZYnU2b0NNd3ZhaGVUOTVnSURCejROMW5IYjF4ZEVkdHpWcnBidXdS?= =?utf-8?Q?yHagGK6N2HlEHGmrKL0ugTvdCXPOVyTjnYY4g=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <666C82A6EBE8384D857402B49B75DB5A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3436.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: caf9c735-443a-42e1-e56c-08d8e608ec7c X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2021 10:15:27.3400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rS15iW9aOfUrq3fJIT9pVlaVM4ARctCXnZtKAElTkbtnAlcoRxdkOp1cJtvAcShDGnlTtoYNSWuMsgHKd/rLQqtAI2CAtl2Pr3WsriR2MEM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2508 Archived-At: Subject: [Secdispatch] Minutes from secdispatch @ IETF 110 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: Sat, 13 Mar 2021 10:15:34 -0000 RGVhciBhbGwsDQoNClRoYW5rIHlvdSBmb3IgcGFydGljaXBhdGluZyBpbiB0aGUgc2VjZGlzcGF0 Y2ggc2Vzc2lvbiBhdCBJRVRGIDExMC4gQSANCmJpZyB0aGFua3MgdG8gb3VyIG1pbnV0ZSB0YWtl cnM6IFBoaWxpcCBIYWxsYW0tQmFrZXIgYW5kIEtpcnN0eSBQYWluZS4NCg0KTWludXRlcyBmcm9t IHRoZSBzZWNkaXNwYXRjaCBzZXNzaW9uIGF0IElFVEYgMTEwIGhhdmUgbm93IGJlZW4gdXBsb2Fk ZWQ6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTEwL21hdGVyaWFscy9t aW51dGVzLTExMC1zZWNkaXNwYXRjaC0wMA0KDQpQbGVhc2UgcmVwb3J0IGFueSBpc3N1ZXMgYnkg TWFyY2ggMjEsIDIwMjEuDQoNCkthdGhsZWVuLCBSaWNoYXJkLCBhbmQgTW9oaXQNCg0KLS0NCg0K MS4gT2JsaXZpb3VzIEhUVFAgKE1hcnRpbiBUaG9tc29uKSDigJM+IHNob3J0LWxpdmVkIFdHLiBD aGFydGVyIHRvIGJlIA0Kd29ya3Nob3BwZWQgb24gdGhlIGxpc3QgdG8gZGVjaWRlIHNjb3BlIGFu ZCB3aGV0aGVyIGEgQm9GIGlzIG5lZWRlZC4NCg0KMi4gQ2lwaGVydGV4dCBmb3JtYXQgKFlhcm9u IFNoZWZmZXIpIOKAkz4gc2V0IHVwIGEgbmV3IG1haWxpbmcgbGlzdCBmb3IgDQpkaXNjdXNzaW9u LiBBRHMgdG8gaGVscCBhdXRob3JzIHdpdGggbGlzdCBzZXR1cC4NCg0KMy4gVXNlIHRoZSBTQU4g ZmllbGQgKFJpY2ggU2Fseikg4oCTPiBEaXNwYXRjaGVkIHRvIFVUQS4NCg0KNC4gTmV3IEFTTi4x IE1vZHVsZXMgZm9yIHRoZSBFdmlkZW5jZSBSZWNvcmQgU3ludGF4IChFUlMpIChSdXNzIA0KSG91 c2xleSnCoCAtPiBBRC1zcG9uc29yZWQgYnkgUm9tYW4uDQoNCg0K From nobody Wed Mar 17 18:25:01 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 170473A19EE for ; Wed, 17 Mar 2021 18:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=lowentropy.net header.b=J7jjkFwa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oOYu0SD8 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 yWwk-VKMn2ty for ; Wed, 17 Mar 2021 18:24:57 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E473A19F7 for ; Wed, 17 Mar 2021 18:24:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C1D071F4A for ; Wed, 17 Mar 2021 21:24:56 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 17 Mar 2021 21:24:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=KvpV9cM4lDiPnI48Znhmj1yzw36qnJAC6DfqcyuPj8Q=; b=J7jjkFwa p/PZC0MHxvIbhWhQP3nXeD1bB3kZtpfXfcq88bGpPQDrtiECa2Hv1cJ/zoaxrFhY 2WM2LFZqwAyRTzvyr2EYoZxB5QxNz4j07JE9cA5YYGynCpKFpc+kOudM3GHHxUgI s9WSoUuuwEC4jEGrP4/yv0M/9eUNvv5M6BuF2dsT7IUn3Atg1qFteRi6LLcMwjrk Lu7HV2WUqpODWN52A8EEWdWPNZUgSx20wpFh0iqgLSzc1IyrfNhiMHrkLN5ZvdAL +BBhdl5MGqUH7N1fYfXgeCgEr4F0TPOeGv3z+IaHSR+8EzLLFrMbBUsSFjC7uYY0 7lEcd7HUMivBmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=KvpV9cM4lDiPnI48Znhmj1yzw36qn JAC6DfqcyuPj8Q=; b=oOYu0SD8315/8GrI+xWznV0nRRHB3ZwXT5r0YklEyDL71 eyVeZBfzctS597xqfrfkRg/GQu65gN6M8x0Rvo5USblvDDJ0CyutLgjkB8tFfQod akp10cxRc5jsWBut9T+YIEC8exnc10PnhxDGUUtHx4m+HHCt67Vwrur6vJmcigrG 0YELsk2zGsqDXwUoREEvp6BtIGJTvSCGN7DYTQfuo0NBJdBSRZKRq5Cf+Zjgvd5Y ASpkKal4a/SvWEKyU4Ea2+5pDa8zn8r+hfxorUFbqxeiUzYrONfy/crDI5PqTnCR 9+1ceogqddwuQu7MtpIMtMH8aIXMZ7hfqdZpBdioA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefhedgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeegueehueejvdeiveffhedvke egffekgffgtdetleefkeeffedtjefhtdduvddutdenucffohhmrghinhepghhithhhuhgs rdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B70484E05B4; Wed, 17 Mar 2021 21:24:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> Date: Thu, 18 Mar 2021 12:24:33 +1100 From: "Martin Thomson" To: secdispatch@ietf.org Content-Type: text/plain Archived-At: Subject: [Secdispatch] Oblivious HTTP charter draft 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: Thu, 18 Mar 2021 01:24:59 -0000 Hi everyone, As we discussed last week, Oblivious HTTP was dispatched to a new working group. I've a proposal for charter text below. After discussing with a few people, it seems like the SEC area is the best venue for this work. It's security-focused work and this area has the best expertise in that area. However, as noted, this will require coordination with HTTP and DPRIVE. The former to ensure that we aren't abusing their protocol (or at least not TOO badly) and the latter to ensure that this is usable for their purposes. Read the current text or contribute text at https://github.com/unicorn-wg/ohttp-charter --- # Oblivious HTTP Working Group (OHTTP) Charter In a number of different settings, interactions between clients and servers involve information that could be sensitive when associated with client identity. Client-server protocols like HTTP reveal aspects of client identity to servers through these interactions, especially source addresses. Even without client identity, a server might be able to build a profile of client activity by correlating requests from the same client over time. In a setting where the information included in requests does not need to be correlated, the Oblivious HTTP protocol allows a server to accept requests via a proxy. The proxy ensures that the server cannot see source addressing information for clients, which prevents servers linking requests to the same client. Encryption ensures that the proxy is unable to read requests or responses. The OHTTP working group will define the Oblivious HTTP protocol, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. The working group will define any encryption scheme necessary and supporting data formats for carrying encapsulated requests and responses, plus any key configuration that might be needed to use the protocol. The OHTTP working group will include an applicability statement that documents the limitations of this design and any usage constraints that are necessary to ensure that the protocol is secure. The working group will define a format for any encryption keys that are needed. The working group will not describe how encryption keys are obtained. The working group will not define any methods for discovering proxy or server endpoints; specific uses of the protocol will need to describe discovery methods or rely on configuration. The OHTTP working group will work closely with other groups that develop the tools that OHTTP depends on (HTTPbis for HTTP, CFRG for HPKE) or that might use Oblivious HTTP (DPRIVE for DNS over HTTPS). The working group will use draft-thomson-http-oblivious as input. From nobody Thu Mar 18 06:09:26 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 A185D3A2B3E for ; Thu, 18 Mar 2021 06:09:24 -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 DSsXVqcO-9Bz for ; Thu, 18 Mar 2021 06:09:22 -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 D2D013A2B3C for ; Thu, 18 Mar 2021 06:09:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 33317389A3; Thu, 18 Mar 2021 09:14:53 -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 ZhaSUBWcel-A; Thu, 18 Mar 2021 09:14:52 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0C21F3899E; Thu, 18 Mar 2021 09:14:52 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2A81E1B9; Thu, 18 Mar 2021 09:09:18 -0400 (EDT) From: Michael Richardson To: "Martin Thomson" cc: secdispatch@ietf.org In-Reply-To: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> 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] Oblivious HTTP charter draft 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: Thu, 18 Mar 2021 13:09:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Martin Thomson wrote: > After discussing with a few people, it seems like the SEC area is the > best venue for this work. It's security-focused work and this area h= as > the best expertise in that area. However, as noted, this will require > coordination with HTTP and DPRIVE. The former to ensure that we aren= 't > abusing their protocol (or at least not TOO badly) and the latter to > ensure that this is usable for their purposes. Remember that we can have WGs in one area, but have a responsible AD from another area. Also, having co-chairs with different strenghts can really help here too. > --- > # Oblivious HTTP Working Group (OHTTP) Charter ... > In a setting where the information included in requests does not need > to be correlated, the Oblivious HTTP protocol allows a server to acce= pt > requests via a proxy. The proxy ensures that the server cannot see > source addressing information for clients, which prevents servers > linking requests to the same client. Encryption ensures that the proxy > is unable to read requests or responses. My understanding of how the protocol works is that we are really building a kind of hybrid HTTP/TLS proxy. That there is some intentional blurring of layers in order to get the desired properties. It seems weird that TLS is not mentioned :-) > The working group will define a format for any encryption keys that a= re > needed. The working group will not describe how encryption keys are > obtained. My understanding is that we don't need new infrastructure, because HTTPS provides what we need. So I think this text is unnecessary. > The working group will not define any methods for discovering > proxy or server endpoints; specific uses of the protocol will need to > describe discovery methods or rely on configuration. reasonable. I think that there may be push in the WG to provide some extension to allow the proxy to snoop on, but not modify, the traffic. It may be worth coding this into the charter as out of scope. =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+93Q3WUFAmBTUP0ACgkQgItw+93Q 3WWZbwf9FHzWSWanwIb8ZSF1UOiVXui6RT6Z1jRDKY0uA1IPpsXhCDK164ys2Z7o LVlgOW02le8tGFaSZ/fjLD9g2+6GpNeqnm6n7KsiMegIWJlbXw3aBnhG3HUddYyw iuoAgBHulDJYEWkHEltE/sKGDuqUFRBbvW3h/mckvsovJQCcWzvlZCqE16os8o8h 0w7AzPKr9anfkEIlsBjlpxh1UU/SNu+Pkj3LotzuXWVcZxo5KsCQsCk6ZNqeKpaL 3zFt0p/LpuQIAO1358OSGoNtSf669SLv8LiptSKj5FVCTPe6X89tApcYC29tOpYq 963mNS+v8oLym0pYR5MYfhbF/GgBJA== =LGtI -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 18 16:14:39 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 232E93A0DAE for ; Thu, 18 Mar 2021 16:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.12 X-Spam-Level: X-Spam-Status: No, score=-7.12 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=lowentropy.net header.b=FbhoAp+7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VG24CgFd 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 giDnbVJzVQCt for ; Thu, 18 Mar 2021 16:14:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914243A0DAD for ; Thu, 18 Mar 2021 16:14:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DF9335C01BE; Thu, 18 Mar 2021 19:14:34 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 18 Mar 2021 19:14:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=K0Erwbc25o6C5Aa71YPZgPA5xZmr fFvMUqQUgBq/dSY=; b=FbhoAp+7ldYjZaggIJxpFhn+W7Lca/xA3RqX+RaMEk1B gUuaGzRrLy/5x/Og7fC2sXDtuthE2DH4U/YmBv6MWMkqGFCoPx2PoxelkkbwF0zq XWrRdZ43VX1ooMELYJ9jBt/ONBot22k4M56WfjFta4aXo2tnfd7ZsR2Jd8SXB3sF Dl6Lhsl3/rQwM3+EqFt4kdgGmY/JByxFq5X/so+Fs3KS/U+BBNlB2rhVYlXQA+1u CVKAbPT2sLw0f08L0cGs08lc+4yklYe+YcGxhf9zDg5mQ8CESaYW8XClwr6KO2Ca Bi5L7AxOidr8WOkVFscegTCwvk0HM6FxmgVLRR2ljg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=K0Erwb c25o6C5Aa71YPZgPA5xZmrfFvMUqQUgBq/dSY=; b=VG24CgFd7rmC9pX9cBtwSL NA2PGUqms5wD3afanfqeWf6wnYjNHRZJ2NJBnMltQVWKP1vG0OeskL7sa9/U0WUi G/Sx7mWyTO1WfBaiJfewCiCegmJ4MaT9nZfdz+Moz0LuTRJqHB/G2OMVeN5xsB5B FaYQYhN8jzhuscfUfTRKOlLBHVIRC9DhzaBO7qKZ7VJbwc9tmr1qdlRQqXa5SGPe pu8+SQScpMOdiSPYoMnegITQVRNkPkyX2c4eAYTfYOvEtmem+ZxOj8pbrFQnX/ip aRAATTHtSHCvUrO9zvx1/B3jyxNb+OkadUdIea5eZhrtKX5MBpvOV3YNdOQh5lYg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefjedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehleduudehhfeiffffhf ffvdeiffejhefhiefhffehvefhhfevgeejhffgtdehffenucffohhmrghinhephhhtthhp shhprhhovhhiuggvshifhhgrthifvghnvggvugdrshhonecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgv th X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35AB94E05A2; Thu, 18 Mar 2021 19:14:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <40db4a3b-3ad1-48f2-84ca-b9a892ebebeb@www.fastmail.com> In-Reply-To: <7599.1616072958@localhost> References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> <7599.1616072958@localhost> Date: Fri, 19 Mar 2021 10:14:14 +1100 From: "Martin Thomson" To: "Michael Richardson" Cc: secdispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Secdispatch] Oblivious HTTP charter draft 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: Thu, 18 Mar 2021 23:14:37 -0000 Thanks for the response Michael, On Fri, Mar 19, 2021, at 00:09, Michael Richardson wrote: > It seems weird that TLS is not mentioned :-) It doesn't mention IP either. Maybe we can just take TLS as read. > > The working group will define a format for any encryption keys that are > > needed. The working group will not describe how encryption keys are > > obtained. > > My understanding is that we don't need new infrastructure, because HTTPS > provides what we need. So I think this text is unnecessary. Maybe the draft isn't clear enough on this point. For reasons described in draft-wood-key-consistency, key acquisition is not that simple. The draft does mention HTTPS, but carefully avoids specifying its use. I think that this bit of scope-limiting is critical. > I think that there may be push in the WG to provide some extension to allow > the proxy to snoop on, but not modify, the traffic. > It may be worth coding this into the charter as out of scope. I thought that "Encryption ensures that the proxy is unable to read requests or responses." was pretty clear on this point. FWIW, I think that the IETF has been pretty good at resisting attempts to remove essential protections in our protocols. I don't see a need to codify that in a charter; it would say more about our lack of confidence than it would affect outcomes. From nobody Sat Mar 20 15:35:55 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 790B33A0AB6 for ; Sat, 20 Mar 2021 15:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Eld9Vz69FSkD for ; Sat, 20 Mar 2021 15:35:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 682033A0AB5 for ; Sat, 20 Mar 2021 15:35:50 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12KMZijd017464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Mar 2021 18:35:48 -0400 Date: Sat, 20 Mar 2021 15:35:43 -0700 From: Benjamin Kaduk To: Martin Thomson Cc: secdispatch@ietf.org Message-ID: <20210320223543.GJ79563@kduck.mit.edu> References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> Archived-At: Subject: Re: [Secdispatch] Oblivious HTTP charter draft 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: Sat, 20 Mar 2021 22:35:54 -0000 On Thu, Mar 18, 2021 at 12:24:33PM +1100, Martin Thomson wrote: [...] > The OHTTP working group will define the Oblivious HTTP protocol, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. The working group will define any encryption scheme necessary and supporting data formats for carrying encapsulated requests and responses, plus any key configuration that might be needed to use the protocol. What does it mean to "define an[y] encryption scheme"? > The OHTTP working group will include an applicability statement that documents the limitations of this design and any usage constraints that are necessary to ensure that the protocol is secure. Is this intended to be an Applicability Statement as defined in RFC 2026? > The working group will define a format for any encryption keys that are needed. The working group will not describe how encryption keys are obtained. The working group will not define any methods for discovering proxy or server endpoints; specific uses of the protocol will need to describe discovery methods or rely on configuration. Why do we need new formats for encryption keys? Don't we already have a bunch of those? Defining how to obtain keys is necessary, of course. Thanks, Ben > The OHTTP working group will work closely with other groups that develop the tools that OHTTP depends on (HTTPbis for HTTP, CFRG for HPKE) or that might use Oblivious HTTP (DPRIVE for DNS over HTTPS). > > The working group will use draft-thomson-http-oblivious as input. > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Sat Mar 20 15:59:25 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 743A93A0BF8 for ; Sat, 20 Mar 2021 15:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_BLOCKED=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 qrid4bLbKkCe for ; Sat, 20 Mar 2021 15:59:22 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 389423A0BF6 for ; Sat, 20 Mar 2021 15:59:22 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id 15so16520748ljj.0 for ; Sat, 20 Mar 2021 15:59:22 -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=hi7PrTw5WuRgsf8AX+vMWu09MAr93MwMSrdXb5J9kIc=; b=gHKk6E+Lvwif26FEFUovbwvz19tzC6iAGA7P51FrcfzhwveMBE3vJYj5HWwNwjvy1u P6l99JDnpIYcBe/gcD15vKqBPlfeE47dDOYn6g4290ggS/0vRgjKtcFquBmUg+a+hp/G 0i73HdsnKNYtKpAtgaqKviILTQ25J5LIQmrPMLNmGMWU4MvKelqZNBmbDRamPnfZQaOb 9XYD1itiqKq7JY1hIVqpWpM4wDatbHffswtsFIjDE/X/0gAE8PE1aoNHbo59gRuk64zn LGssgOfN+ZW5kVZFoC/wOWgX7vAd5mwPnzMo4k/E8RpXo5H1xL5ln30Q/X0lMRkm/VmK YNsA== 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=hi7PrTw5WuRgsf8AX+vMWu09MAr93MwMSrdXb5J9kIc=; b=pNl78aLLzOhfk8XmWIwxarrffuxpeuvvgdnxFHx+upEXYHAvPQCjD2PAanX0jcCG1v fm0Wgl5Y2pV8OVvit6D8qUE95YOkpoTySPpSYZaVkuwrrgNX7jYeYBc+3gqavqhn/lQP erLW2/e8gmR4sG5ddtXiN9XlqB8ln8bcraLx4XAxt3KJx3hSErr2LClGANxGRy29RRNP xYLWjtC8W0u5hW4fFCPmwbCkhXc4dFFSKhQak/EEMbgJ/1ezId8SpTZE+wpS2K0UdBWj Ql/iinf369pd781hqFrLiqjvsi71aj1EJwkU/BgZ5SRDlcwUVHI40bnaWSOmcMFPV7YK pmCQ== X-Gm-Message-State: AOAM530IA8s/dNuL7xzZ0RpnAjQewTNbXZhY/uEKaHHaaQlUWE3QlEv+ cujMrP+xCTuHG1hclhG06R98zN9plc/uk14ohWDv9g== X-Google-Smtp-Source: ABdhPJzdhGB8wDqbqIB1ah0qWZWBXWZn8U4zYnQrg4wfgSQvGRmDU3zxBerU4HYYhMG16GWDcGFZZ3S1XEya3WS3BHc= X-Received: by 2002:a2e:b053:: with SMTP id d19mr4922259ljl.82.1616281158237; Sat, 20 Mar 2021 15:59:18 -0700 (PDT) MIME-Version: 1.0 References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> <20210320223543.GJ79563@kduck.mit.edu> In-Reply-To: <20210320223543.GJ79563@kduck.mit.edu> From: Eric Rescorla Date: Sat, 20 Mar 2021 15:58:42 -0700 Message-ID: To: Benjamin Kaduk Cc: Martin Thomson , IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000004b547005bdffc8f5" Archived-At: Subject: Re: [Secdispatch] Oblivious HTTP charter draft 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: Sat, 20 Mar 2021 22:59:24 -0000 --0000000000004b547005bdffc8f5 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 20, 2021 at 3:35 PM Benjamin Kaduk wrote: > On Thu, Mar 18, 2021 at 12:24:33PM +1100, Martin Thomson wrote: > [...] > > The OHTTP working group will define the Oblivious HTTP protocol, a > method of encapsulating HTTP requests and responses that provides > protected, low-latency exchanges. The working group will define any > encryption scheme necessary and supporting data formats for carrying > encapsulated requests and responses, plus any key configuration that might > be needed to use the protocol. > > What does it mean to "define an[y] encryption scheme"? > I believe this just means "data format". > The OHTTP working group will include an applicability statement that > documents the limitations of this design and any usage constraints that are > necessary to ensure that the protocol is secure. > > Is this intended to be an Applicability Statement as defined in RFC 2026? > > > The working group will define a format for any encryption keys that are > needed. The working group will not describe how encryption keys are > obtained. The working group will not define any methods for discovering > proxy or server endpoints; specific uses of the protocol will need to > describe discovery methods or rely on configuration. > > Why do we need new formats for encryption keys? Don't we already have a > bunch of those? Defining how to obtain keys is necessary, of course. > What you need is actually more like a format for defining the complete parameter space that the server accepts (key, HPKE algorithm, etc.) Effectively what's in HPKEConfig: https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi -Ekr > Thanks, > > Ben > > > The OHTTP working group will work closely with other groups that develop > the tools that OHTTP depends on (HTTPbis for HTTP, CFRG for HPKE) or that > might use Oblivious HTTP (DPRIVE for DNS over HTTPS). > > > > The working group will use draft-thomson-http-oblivious as input. > > > > _______________________________________________ > > Secdispatch mailing list > > Secdispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/secdispatch > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000004b547005bdffc8f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Mar 20, 2021 at 3:35 PM Benja= min Kaduk <kaduk@mit.edu> wrote:=
On Thu, Mar 18,= 2021 at 12:24:33PM +1100, Martin Thomson wrote:
[...]
> The OHTTP working group will define the Oblivious HTTP protocol, a met= hod of encapsulating HTTP requests and responses that provides protected, l= ow-latency exchanges. The working group will define any encryption scheme n= ecessary and supporting data formats for carrying encapsulated requests and= responses, plus any key configuration that might be needed to use the prot= ocol.

What does it mean to "define an[y] encryption scheme"?

I believe this just means "data format"= .


> The OHTTP working group will include an applicability statement that d= ocuments the limitations of this design and any usage constraints that are = necessary to ensure that the protocol is secure.

Is this intended to be an Applicability Statement as defined in RFC 2026?
> The working group will define a format for any encryption keys that ar= e needed. The working group will not describe how encryption keys are obtai= ned. The working group will not define any methods for discovering proxy or= server endpoints; specific uses of the protocol will need to describe disc= overy methods or rely on configuration.

Why do we need new formats for encryption keys?=C2=A0 Don't we already = have a
bunch of those?=C2=A0 Defining how to obtain keys is necessary, of course.<= br>

What you need is actually more like a f= ormat for defining the complete parameter space that the server accepts (ke= y, HPKE algorithm, etc.) Effectively what's in HPKEConfig:
https://tlswg.org/draft-ietf-= tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi

-Ekr



Thanks,

Ben

> The OHTTP working group will work closely with other groups that devel= op the tools that OHTTP depends on (HTTPbis for HTTP, CFRG for HPKE) or tha= t might use Oblivious HTTP (DPRIVE for DNS over HTTPS).
>
> The working group will use draft-thomson-http-oblivious as input.
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@= ietf.org
> https://www.ietf.org/mailman/listinfo/secdispa= tch

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000004b547005bdffc8f5-- From nobody Sun Mar 21 16:33:13 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 282623A0B55 for ; Sun, 21 Mar 2021 16:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=lowentropy.net header.b=U8CGTwvp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h1ISsiHy 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 rJOS2ch90ZfA for ; Sun, 21 Mar 2021 16:33:02 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8388A3A0ABB for ; Sun, 21 Mar 2021 16:33:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9BA7E5C00B0; Sun, 21 Mar 2021 19:33:01 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 21 Mar 2021 19:33:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=oZH43o8ewc8InLPYgXr/LeqEdSOj kE3RGvYsCvsTRhA=; b=U8CGTwvpcEl5Q4knqcBXXhkPLyxQl5iyLMhgSz/ixhCX Ief/tGVQA4PIDSbl9RQeBNzO1BVJ4UgMPyQz7bYBdBmVo+0vbNfTZE8wxjw0yPMf RdKnrYYumL71yka+zRZsKKeEJg2AcHYdEaOD9Qfzgwo0tGNgsuNIctAQymycwQkh 0RQjQxleHehXtdQlvoNeKi5hmhgJqH+uXk1jMTSsKrwH4Ri7zRY4ArmSnowcfL3t bawRXlmpp/d5Zho6V5gkSNN0VBUjBrUwn8uaxc2Q2nito1GV+8g2wbWTVeDf/vJR lr3jgdXxlIFzENP1IdA0opw2/iwpjHT/3o6STubAgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=oZH43o 8ewc8InLPYgXr/LeqEdSOjkE3RGvYsCvsTRhA=; b=h1ISsiHySKL6Z5TEGuVE8d hob5ztOHpJV5wVms0iVyQjA2+fctZ92cAdvOXfQt5Fz7AtcExR4n8BSH2XkA4wq/ he3tQ9KrWqfvZGFe98kd2COIkRYzjL2Sb0+zzoIgStY9uq9qoA+f7bwb/YIp4HGt BI1XBbaH8ut227nLbOVR+RN6L6dJmbYLqxF6uDZiW1rpbTvE+YEgqoWtZK5GHvh9 NIyTkSvkcLsKpbVSaKlwH+YngCSxR2pkzS3qovMfBKWilE+0z2xX2gOeY8kL5dV0 q8G0WWBVQ8dK1/D3Y9q5xcoGxcmA3z/EwonMJ/GvkE9BdYM/1RknwIDvaIl1eTOw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudegfedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepudekuedtvdegudevteefvddvffffheelveefueffgfeivdejtdet tdeiudelleffnecuffhomhgrihhnpehtlhhsfihgrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidr nhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1CBC64E05F8; Sun, 21 Mar 2021 19:33:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <7b679237-4201-4cff-aa8f-bff1b303dd83@www.fastmail.com> In-Reply-To: References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> <20210320223543.GJ79563@kduck.mit.edu> Date: Mon, 22 Mar 2021 10:32:44 +1100 From: "Martin Thomson" To: "'Eric Rescorla'" , "'Benjamin Kaduk'" Cc: "IETF SecDispatch" Content-Type: text/plain Archived-At: Subject: Re: [Secdispatch] Oblivious HTTP charter draft 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, 21 Mar 2021 23:33:12 -0000 On Sun, Mar 21, 2021, at 09:58, Eric Rescorla wrote: > I believe this just means "data format". Correct. I was just spelling out the crypto piece given how important it is. > > Why do we need new formats for encryption keys? Don't we already have a > > bunch of those? Defining how to obtain keys is necessary, of course. > > What you need is actually more like a format for defining the complete > parameter space that the server accepts (key, HPKE algorithm, etc.) > Effectively what's in HPKEConfig: > > https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi This is also right. FWIW, the two documents currently share a common core and I'd like to keep it that way. I don't think that it makes sense to have one depend on the other from a logistical perspective, but making that small piece of code reusable is worthwhile. From nobody Wed Mar 24 16:52:29 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 7D2C53A1251 for ; Wed, 24 Mar 2021 16:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 F7MIcmEDl-PB for ; Wed, 24 Mar 2021 16:52:23 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 250F23A1250 for ; Wed, 24 Mar 2021 16:52:23 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id c204so141733pfc.4 for ; Wed, 24 Mar 2021 16:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q0LRsHs6iWyA1okZ4fI8XLuQZhegTXxcVS7BgBUKCfk=; b=EhgIxI6+8kZlmfzfCnfuzxi/iUlAHYy7BeXpOoWFfDiNMhiiawwIP9AleLUu35los1 D8n+i+it02xztI1XahDZ2ye1FmYBLj6OprZ3d0YLnvpSEt4tgdgqbPEPesYgQsJCB0uX F9+9fglmyoTHnRMd1zfyhxF4ui06nWn0RwI01e2I6ReyY1TdjvpLNmwOxPBNhRxXoN0w vdPKnH/A0PXAYzhX3Qgp9Rsg0LHJxWf0reTj3vdNNL3YhNT6AKTo2mCC103ekoijuWJP XwwBgpJqSK2xBp4ojBQjWVwC9QuX+GSVbHsoYzcyJnluY12Ou4NgXruL4rQg7IkjhQcQ CAbQ== 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=Q0LRsHs6iWyA1okZ4fI8XLuQZhegTXxcVS7BgBUKCfk=; b=H22PalprQpzv8FmUacdd5uHwz9lQO3mxJfpnR1m/VAZE7KudvFOBxD9cZxWAWeQkio /ESfLRdBnccM5YIh+h/cubhjCKp0mmSHRIg8loBu8SNAxB6mib90bahEfvditeKTw7AC y1oI3kh0b7k8vD0a9y9/6sj1BUcrmwoqtGXfUi3rNBMfWII+UfGGInE2Kkzs+VLdxVja Xt4q6VbMehjBeF7pt3/S4p5prAD/P3oS0RFRnFhKB3Q2TBsASS6KyAovuusNL/eKmdN9 QJnYFK7ERhatlDIZE0rj1OwhYLxumKhiRQnOcozv62fmQX1QeER3OXmA8nj7WtcIe39U dYUA== X-Gm-Message-State: AOAM530dj2zgRWJlETXQyZVFi1WFhMZLPRl1BkXai+85pOghAX/fp289 vBCMBF0qgXWj8zgIv6iwh6g3tRp9Nzix6DidehM= X-Google-Smtp-Source: ABdhPJwqaKmP98bYUc4jp7CMPOoMDfedQ5bw/+P/4XYUQftIrdLzabSanRfKHZb9cGuixhFumdHGtZGt7IiYpE5DsQ8= X-Received: by 2002:a62:528e:0:b029:1f5:c5ee:a487 with SMTP id g136-20020a62528e0000b02901f5c5eea487mr5255224pfb.7.1616629942110; Wed, 24 Mar 2021 16:52:22 -0700 (PDT) MIME-Version: 1.0 References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> <20210320223543.GJ79563@kduck.mit.edu> <7b679237-4201-4cff-aa8f-bff1b303dd83@www.fastmail.com> In-Reply-To: <7b679237-4201-4cff-aa8f-bff1b303dd83@www.fastmail.com> From: David Schinazi Date: Wed, 24 Mar 2021 16:52:09 -0700 Message-ID: To: Martin Thomson Cc: Eric Rescorla , Benjamin Kaduk , IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000006ecd6b05be50fd58" Archived-At: Subject: Re: [Secdispatch] Oblivious HTTP charter draft 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, 24 Mar 2021 23:52:28 -0000 --0000000000006ecd6b05be50fd58 Content-Type: text/plain; charset="UTF-8" This draft charter looks good to me, I'd support creation of this WG. David (no hats) On Sun, Mar 21, 2021 at 4:34 PM Martin Thomson wrote: > On Sun, Mar 21, 2021, at 09:58, Eric Rescorla wrote: > > I believe this just means "data format". > > Correct. I was just spelling out the crypto piece given how important it > is. > > > > Why do we need new formats for encryption keys? Don't we already have > a > > > bunch of those? Defining how to obtain keys is necessary, of course. > > > > What you need is actually more like a format for defining the complete > > parameter space that the server accepts (key, HPKE algorithm, etc.) > > Effectively what's in HPKEConfig: > > > > > https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi > > This is also right. FWIW, the two documents currently share a common core > and I'd like to keep it that way. I don't think that it makes sense to > have one depend on the other from a logistical perspective, but making that > small piece of code reusable is worthwhile. > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000006ecd6b05be50fd58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This draft charter looks good to me, I'd support creat= ion of this WG.

David (no hats)

On Sun, Mar 21, 202= 1 at 4:34 PM Martin Thomson <mt@low= entropy.net> wrote:
On Sun, Mar 21, 2021, at 09:58, Eric Rescorla wrote:
> I believe this just means "data format".

Correct.=C2=A0 I was just spelling out the crypto piece given how important= it is.

> > Why do we need new formats for encryption keys?=C2=A0 Don't w= e already have a
> > bunch of those?=C2=A0 Defining how to obtain keys is necessary, o= f course.
>
> What you need is actually more like a format for defining the complete=
> parameter space that the server accepts (key, HPKE algorithm, etc.) > Effectively what's in HPKEConfig:
>
> = https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypt= ed-clienthello-confi

This is also right.=C2=A0 FWIW, the two documents currently share a common = core and I'd like to keep it that way.=C2=A0 I don't think that it = makes sense to have one depend on the other from a logistical perspective, = but making that small piece of code reusable is worthwhile.

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000006ecd6b05be50fd58-- From nobody Wed Mar 24 16:53:51 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 7326E3A12A4 for ; Wed, 24 Mar 2021 16:53:43 -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 5dIjT7IE8Q97 for ; Wed, 24 Mar 2021 16:53:39 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 ACD593A1278 for ; Wed, 24 Mar 2021 16:53:38 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id f16so861038ljm.1 for ; Wed, 24 Mar 2021 16:53:38 -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=2IZ+2Rlpa1HN0UDeOaQnEsNUSnYj1LBM1QZd9EE4LkA=; b=cyuis8WPltAAZQSezqSXQM0U3UqcofBOOjuj1hUzWNQn5YJcQ/PXABrtKXUrK4oEfL RBpQ2M162rk/KjXdsMtyrpR4az7aasPLtuNSShUOBdsBcFq13w6lUuVj0oBzRc0hPlxH LZyFAWVqo9uTz9soxD+Tu4hPv7uEGy/o/6kcFtB/vnmWeFd0PAv66KPtTmRZ2Jmjm5lZ AUr2OUYvS7NbJcfGGcmVQpWDhaqP7dcPMi1+paBWqqV0yo7aQJC0VYGxzUdi6cjjv+rq 9ga+9yoJJXDVYakHDZtt45ENG4M8nNMKFzxe8Tjq7Me+r7vyJVkegsBzu+KwVDmIK3Qp jkzw== 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=2IZ+2Rlpa1HN0UDeOaQnEsNUSnYj1LBM1QZd9EE4LkA=; b=qCCo9V+enfixbtWMLpK2pHaYNx/Vkjd1Od2XGWIVcXnfNVKLupfigfJt1H326Qb6tG GKiuuhRJa69D1nPmqXCDd2WrZ+B4nT0H4nM4HXW3af38visoq7BRGRqLezKQLfdX8CSH 7/mLofqiaacum+LiNaOmSQu9rDuHbcnLyS8NK0VmuZq+FXjhZ9i+hos6efilAfxY5qXY +ZSOK6ABgkt2qSa7GR/8MIaikY4KyUJjYAp44F+fOuR6QWasz1qGBfO4JcceFV5JLiJz kZUhzY6hx6dpAaFWiENmduz9qSFSpylyNBTctV/jcxyPttCxdb830vSk0RHoCDIo9Wwr ykeA== X-Gm-Message-State: AOAM531U0ll2GDNVNyNMaucw0wadz6pfWvUX1ehJJWoViqra8jCOQmh4 Uy8EU9qsRxEKSnw7P5+yzXR4iY1b89EJEkEWByVM7g== X-Google-Smtp-Source: ABdhPJzvDyZ1OSH2UC+6oaTs5l1QiD00mBMwUbC8/1gbcoJIYe7euzXvc8rsv3z+6dYlJCGgWKWqkvtgprvVtajI4iw= X-Received: by 2002:a2e:3609:: with SMTP id d9mr3840999lja.2.1616630015993; Wed, 24 Mar 2021 16:53:35 -0700 (PDT) MIME-Version: 1.0 References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> <20210320223543.GJ79563@kduck.mit.edu> <7b679237-4201-4cff-aa8f-bff1b303dd83@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Wed, 24 Mar 2021 16:52:59 -0700 Message-ID: To: David Schinazi Cc: Martin Thomson , Benjamin Kaduk , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000d63ce805be51015b" Archived-At: Subject: Re: [Secdispatch] Oblivious HTTP charter draft 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, 24 Mar 2021 23:53:50 -0000 --000000000000d63ce805be51015b Content-Type: text/plain; charset="UTF-8" As do I. On Wed, Mar 24, 2021 at 4:52 PM David Schinazi wrote: > This draft charter looks good to me, I'd support creation of this WG. > > David (no hats) > > On Sun, Mar 21, 2021 at 4:34 PM Martin Thomson wrote: > >> On Sun, Mar 21, 2021, at 09:58, Eric Rescorla wrote: >> > I believe this just means "data format". >> >> Correct. I was just spelling out the crypto piece given how important it >> is. >> >> > > Why do we need new formats for encryption keys? Don't we already >> have a >> > > bunch of those? Defining how to obtain keys is necessary, of course. >> > >> > What you need is actually more like a format for defining the complete >> > parameter space that the server accepts (key, HPKE algorithm, etc.) >> > Effectively what's in HPKEConfig: >> > >> > >> https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi >> >> This is also right. FWIW, the two documents currently share a common >> core and I'd like to keep it that way. I don't think that it makes sense >> to have one depend on the other from a logistical perspective, but making >> that small piece of code reusable is worthwhile. >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > --000000000000d63ce805be51015b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As do I.

On Wed, Mar 24, 2021 at 4:52 PM David Schinaz= i <dschinazi.ietf@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">This draft charter looks good to me, I'd support creati= on of this WG.

David (no hats)

On Sun, Mar 21, 2021= at 4:34 PM Martin Thomson <mt@lowentropy.net> wrote:
On Sun, Mar 21, 2021, at 09:58, Eric Rescorla = wrote:
> I believe this just means "data format".

Correct.=C2=A0 I was just spelling out the crypto piece given how important= it is.

> > Why do we need new formats for encryption keys?=C2=A0 Don't w= e already have a
> > bunch of those?=C2=A0 Defining how to obtain keys is necessary, o= f course.
>
> What you need is actually more like a format for defining the complete=
> parameter space that the server accepts (key, HPKE algorithm, etc.) > Effectively what's in HPKEConfig:
>
> = https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypt= ed-clienthello-confi

This is also right.=C2=A0 FWIW, the two documents currently share a common = core and I'd like to keep it that way.=C2=A0 I don't think that it = makes sense to have one depend on the other from a logistical perspective, = but making that small piece of code reusable is worthwhile.

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000d63ce805be51015b-- From kvaughn@trevilon.com Mon Mar 29 13:59:04 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 35BB93A2167 for ; Mon, 29 Mar 2021 13:59:04 -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 nVeDe_-t1OCz for ; Mon, 29 Mar 2021 13:58:59 -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 5D1633A2164 for ; Mon, 29 Mar 2021 13:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trevilon.com; s=default; h=To:Date:Message-Id:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=o64iT8L9m6HX/am8goU/GN7PwwUlWiFMIjcM3b29obg=; b=AyUFA0N5hhamjwvJK6yuIPQwiq r3S9kfl6SztK6tSseZPNMxC3TaI4i2Sp227zRPSPe9hXpjkvuOZT9XoB/s6DcJk2DRnIvpaHjp0e4 41hbgE7T2H6SNrpyUgsWO3zWs; Received: from 75-148-252-134-houston.hfc.comcastbusiness.net ([75.148.252.134]:63229 helo=[192.168.1.10]) by tre.trevilon.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lQyyQ-0003Rc-73 for secdispatch@ietf.org; Mon, 29 Mar 2021 20:58:58 +0000 From: Kenneth Vaughn Content-Type: multipart/alternative; boundary="Apple-Mail=_C0A31CAF-68C0-4F29-B4C8-B1E52C683A2C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <26F542F7-CBF8-4EFB-9581-296CDE5A8322@trevilon.com> Date: Mon, 29 Mar 2021 15:58:57 -0500 To: secdispatch@ietf.org X-Mailer: Apple Mail (2.3654.60.0.2.21) 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: [Secdispatch] TLSTM Update Draft 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: Mon, 29 Mar 2021 23:46:34 -0000 --Apple-Mail=_C0A31CAF-68C0-4F29-B4C8-B1E52C683A2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I would like to present = https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ = =20 This document is a proposal to update to RFC 6353 (TLS Transport Model = for SNMP) to reflect the needs of TLS 1.3.=20 As a little bit of background, SNMP is widely used within Intelligent = Transportation Systems (ITS) to monitor, manage and control field = devices, as defined in the National Transportation Communication for ITS = Protocols (NTCIP) standards, ISO standards, and specifications in the = United Kingdom. As you may know, CISA has declared the transportation = infrastructure to be =E2=80=9Ccritical infrastructure=E2=80=9D, and the = ITS community is very interested in ensuring that this infrastructure is = adequately protected, especially as these systems are increasingly = relied upon by modern connected vehicles.=20 RFC 6353 defines how to use (D)TLS 1.2 authentication to control data = access within SNMP. Unfortunately, its design is not entirely compatible = with TLS 1.3. As such, the ITS community is interested in producing an = update to RFC 6353 and believes it would be in everyone's best interests = to produce this document as an IETF publication, assuming that its = development can proceed in a timely manner.=20 In an effort to promote further discussion on this topic, the NTCIP and = ISO communities have requested that I reach out to the IETF to initiate = a conversation on this topic and I have been informed that this email = list is the appropriate location to start such discussions. There is = also a presentation available at = https://trevilon.com/download/RFC6353Proposal.pptx = that explains the = motivation behind this update proposal.=20 Many thanks for your considerations and I look forward to our future = discussions. Please let me know if you have any questions. Regards, Ken Vaughn Trevilon LLC --Apple-Mail=_C0A31CAF-68C0-4F29-B4C8-B1E52C683A2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello,

I would like to = present https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/=  

This = document is a proposal to update to RFC 6353 (TLS = Transport Model for SNMP) to reflect the needs of TLS = 1.3. 

As = a little bit of background, SNMP is widely used within Intelligent = Transportation Systems (ITS) to monitor, manage and control field = devices, as defined in the National Transportation Communication for ITS = Protocols (NTCIP) standards, ISO standards, and specifications in the = United Kingdom. As you may know, CISA has declared = the transportation infrastructure to be =E2=80=9Ccritical = infrastructure=E2=80=9D, and the ITS community is very interested in = ensuring that this infrastructure is adequately protected, especially as = these systems are increasingly relied upon by modern connected = vehicles. 

RFC 6353 defines how to use (D)TLS 1.2 authentication to = control data access within SNMP. Unfortunately, its design is not = entirely compatible with TLS 1.3. As such, the ITS community is = interested in producing an update to RFC 6353 and believes it would be = in everyone's best interests to produce this document as an IETF = publication, assuming that its development can proceed in a timely = manner. 

In= an effort to promote further discussion on this topic, the NTCIP and = ISO communities have requested that I reach out to the IETF to initiate = a conversation on this topic and I have been informed that this email = list is the appropriate location to start such discussions. There is = also a presentation available at https://trevilon.com/download/RFC6353Proposal.pptx tha= t explains the motivation behind this update proposal. 

Many thanks for = your considerations and I look forward to our future discussions. Please = let me know if you have any questions.

Regards,
Ken Vaughn
Trevilon LLC


= --Apple-Mail=_C0A31CAF-68C0-4F29-B4C8-B1E52C683A2C-- From nobody Tue Mar 30 09:41:26 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 72B8B3A1AA7 for ; Tue, 30 Mar 2021 09:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=heapingbits.net header.b=xXGpHHh4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GCyq/yAP 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 Xliw-HlXOnXY for ; Tue, 30 Mar 2021 09:41:18 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48F33A1AA9 for ; Tue, 30 Mar 2021 09:41:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 39DBF5C00C9 for ; Tue, 30 Mar 2021 12:41:17 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Tue, 30 Mar 2021 12:41:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=DbcqvOx3CAZOaIQ9clZ+wI+S8nQOcxR pm87MdantNT0=; b=xXGpHHh4ih/I4BKDUoV80bG7O2w4zgwFYtSZa2bI0TFMW2Y YmDz6asHOzoQcdmZDp8uhHSd+4Lcqo6A6hoHQAm0bp2gx+CDz41YmHsDxNGpmjO4 aao6ORu6SMafJk2OLtyiSnvq0KIIkDKZdG/o/+g1U/j5iURB2M8nm2Qtkw5yVF0U 8+AZsD8zdQBgbYLpA+4Z+7jdJbCqsHrxED1Vv9hfX7vEAARhEX/J+zZCNuFXYkGw G085GnA9a27mzx9Z+TU92RNQIY5JYVxhnnMYU6Nad9STID/S0FN4Zn13897arApd tf6uEpouQLjac29Rx0h6mrkcGNgDm/X8W/4FvkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DbcqvO x3CAZOaIQ9clZ+wI+S8nQOcxRpm87MdantNT0=; b=GCyq/yAPOKXUfPBvIrXexy ib11HpnhRi3w0aRH//4KyA1tkRjAhgVQX5kOj7oeitwHoEeU5Lx2CkN3doipLWKY LUrryni46MvTx7iknSOGvwebwP00wjYwsno4iFVnP01IOhtgpKh4X7NONc3m07gX VkOM7DEccgOVgRzjNiEW3ND23nZ4UmJj4I8lvd1jTWES6421qcG7JZbO99EKqpQ0 VEnArTc5D8/SBgqnHkjYsgTqvo5nok8DhR4Y/zB2MaqmvI2HQ7fn8MpFa+I3VHuS fbsHckl1Brcb/oDBZf7gqeI9ECbI3owOGnvQyjxkyvCcbKOf5SUkOrwQqoucdLaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeitddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepheelkeethf ffudeikeeifffhkefhjedvleekheffuddvffeghfdtfeduteevieeunecuffhomhgrihhn pehtlhhsfihgrdhorhhgpdhivghtfhdrohhrghdpgedtihgvthhfrdhorhhgnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D7C40160060; Tue, 30 Mar 2021 12:41:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <6580c024-d9a5-41ee-b0b8-e079496a0de0@www.fastmail.com> In-Reply-To: References: <8e53426d-857e-4dd9-a9d0-b907c415abec@www.fastmail.com> <20210320223543.GJ79563@kduck.mit.edu> <7b679237-4201-4cff-aa8f-bff1b303dd83@www.fastmail.com> Date: Tue, 30 Mar 2021 09:40:56 -0700 From: "Christopher Wood" To: secdispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Secdispatch] Oblivious HTTP charter draft 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: Tue, 30 Mar 2021 16:41:25 -0000 +1 -- thanks for putting this together, Martin! On Wed, Mar 24, 2021, at 4:52 PM, Eric Rescorla wrote: > As do I. > > On Wed, Mar 24, 2021 at 4:52 PM David Schinazi wrote: > > This draft charter looks good to me, I'd support creation of this WG. > > > > David (no hats) > > > > On Sun, Mar 21, 2021 at 4:34 PM Martin Thomson wrote: > >> On Sun, Mar 21, 2021, at 09:58, Eric Rescorla wrote: > >> > I believe this just means "data format". > >> > >> Correct. I was just spelling out the crypto piece given how important it is. > >> > >> > > Why do we need new formats for encryption keys? Don't we already have a > >> > > bunch of those? Defining how to obtain keys is necessary, of course. > >> > > >> > What you need is actually more like a format for defining the complete > >> > parameter space that the server accepts (key, HPKE algorithm, etc.) > >> > Effectively what's in HPKEConfig: > >> > > >> > https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-encrypted-clienthello-confi > >> > >> This is also right. FWIW, the two documents currently share a common core and I'd like to keep it that way. I don't think that it makes sense to have one depend on the other from a logistical perspective, but making that small piece of code reusable is worthwhile. > >> > >> _______________________________________________ > >> Secdispatch mailing list > >> Secdispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/secdispatch > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch >
dr. Robin=C2=A0Marx
Postdoc researcher - Web protocols
Expertise centr= e for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 =
=C2=A0
w= ww.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""