From nobody Fri Nov 1 14:59:56 2019 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 403A212083A; Fri, 1 Nov 2019 14:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 TX4eAuHq79Ro; Fri, 1 Nov 2019 14:59:52 -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 56DBD12082F; Fri, 1 Nov 2019 14:59:52 -0700 (PDT) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA1Lxoh4020181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 17:59:51 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_6934B8F4-D23B-4D24-B018-73C87428BBDE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 1 Nov 2019 17:59:50 -0400 To: dispatch@ietf.org, secdispatch@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Secdispatch] HTTP Request Signing X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 21:59:54 -0000 --Apple-Mail=_6934B8F4-D23B-4D24-B018-73C87428BBDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would like to present and discuss HTTP Request signing at both the = DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of = different external groups and efforts: https://tools.ietf.org/html/draft-cavage-http-signatures = I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d like = to find out how to bring this forward to publication within the IETF. = I=E2=80=99m targeting both dispatch groups because this represents the = intersection of both areas, and I think we=E2=80=99d get different = perspectives from each side that we should consider.=20 There have been a number of other drafts that have approached HTTP = request signing as well (I=E2=80=99ve written two of them myself), but = none has caught on to date and none have made it to RFC. Lately, though, = I=E2=80=99ve been seeing a lot of renewed effort in different sectors, = and in particular the financial sector and cloud services, to have a = general purpose HTTP message signing capability. As such, I think it=E2=80= =99s time to push something forward.=20 I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDISPATCH = to request a presentation slot. Thank you, and I=E2=80=99ll see you all in Singapore! =E2=80=94 Justin= --Apple-Mail=_6934B8F4-D23B-4D24-B018-73C87428BBDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = would like to present and discuss HTTP Request signing at both the = DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of = different external groups and efforts:

https://tools.ietf.org/html/draft-cavage-http-signatures

I=E2=80=99ve = spoken with the authors of the draft and we=E2=80=99d like to find out = how to bring this forward to publication within the IETF. I=E2=80=99m = targeting both dispatch groups because this represents the intersection = of both areas, and I think we=E2=80=99d get different perspectives from = each side that we should consider. 

There have been a number of other = drafts that have approached HTTP request signing as well (I=E2=80=99ve = written two of them myself), but none has caught on to date and none = have made it to RFC. Lately, though, I=E2=80=99ve been seeing a lot of = renewed effort in different sectors, and in particular the financial = sector and cloud services, to have a general purpose HTTP message = signing capability. As such, I think it=E2=80=99s time to push something = forward. 

I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot.

Thank you, and I=E2=80=99ll see you all = in Singapore!
 =E2=80=94 = Justin
= --Apple-Mail=_6934B8F4-D23B-4D24-B018-73C87428BBDE-- From nobody Fri Nov 1 21:26:24 2019 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 7B38B120A80; Fri, 1 Nov 2019 21:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=mnot.net header.b=GBAFj3i2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Iwrj2gkR 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 RN35cOUZCUBx; Fri, 1 Nov 2019 21:26:10 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D54120937; Fri, 1 Nov 2019 21:26:09 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EC84021340; Sat, 2 Nov 2019 00:26:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 02 Nov 2019 00:26:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=E zV/w/ZfedmKAYeMxaLZ/VZVaKiqLR6NvBvpzGRbnqw=; b=GBAFj3i2G2Mjvtz8Q hVVMKksBoJ831Z6t+l7hvjXtdOsUI05K90684Rmzw/Xchj3bEbBwVP5vK3bhlNPr kqshx5UAxXUb4g5AHdlegJyxqDPO8fbc5nIqllpA4hNre4UdOoXbb4oBVNBawZeE fz4YGmi07VOH8EXb3FVvBn4p3onPZ1nm6ywKR+y4mjQpIGjLtk0DJVWrFYqADKqu mzOHGLt7AXrFHycTLog1MdbCeGeAwrgEPLXhps69SCQkytp8oP6PcSm6Msfix+TJ 3Tt9Mjf9/SZ24RdX8CP7KFGA3oogMW73/mVRQ7OA/06TfjEUEoPyCkY9lKiNHn5E 9EQpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm1; bh=EzV/w/ZfedmKAYeMxaLZ/VZVaKiqLR6NvBvpzGRbn qw=; b=Iwrj2gkRSXVy5CdDz/huoRGowhwNZqR8lCrIfTQyATo4n9JRq45D6yJcC /Ci3F0wemRrHoa76u7PN8eJWB8YQhTblG8nsY3UZ6T4v+eWpps0CcrFb/sAgCr3M KkPBjpomWIquvvUPJT8BZO9uTH12b9Lho0yh3BcxV7cf7yoUu0Qey6KuyGNC34LY aB9+UDuzqqrvn2kMqLGz6oPPAZZo5bc8bUGiy6VvetXl7TsqX9C/4RCYCRTMlf+W pQ3+hbY3IMInXrFG02JpBvvXha+QT3YMVwA8eLB40J5Us/cn5ttuB0WLt+4SVSE1 EUQ9TN6SNjLQIMINQtzwo9EP13F+w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtkedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh ephhhtthhptghomhhmuhhnihhtihgvshhrvghsphgvtghtihhvvghlhidrshhopdhhthht phhmvghsshgrghgvshhighhnihhnghgtrghprggsihhlihhthidrrghspdhivghtfhdroh hrghdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucfrrghr rghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id DF5848005B; Sat, 2 Nov 2019 00:26:05 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Mark Nottingham In-Reply-To: Date: Sat, 2 Nov 2019 15:26:01 +1100 Cc: dispatch@ietf.org, secdispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Justin Richer X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 02 Nov 2019 04:26:14 -0000 Hi Justin, It's worth noting that there's a Working Group forming BoF, wpack, being = held in Singapore about a draft with similar goals: = https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07 In particular, both this draft and Jeffrey's propose the Signature HTTP = header field, and seem to have at least partially overlapping use cases. If possible, it'd be good to avoid duplication of effort -- especially = in terms of evaluating security properties and "fit" into HTTP by the = security and HTTP communities, respectively. So, I'd suggest bringing it = up there instead. Cheers, =20 > On 2 Nov 2019, at 8:59 am, Justin Richer wrote: >=20 > I would like to present and discuss HTTP Request signing at both the = DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of = different external groups and efforts: >=20 > https://tools.ietf.org/html/draft-cavage-http-signatures >=20 > I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d = like to find out how to bring this forward to publication within the = IETF. I=E2=80=99m targeting both dispatch groups because this represents = the intersection of both areas, and I think we=E2=80=99d get different = perspectives from each side that we should consider.=20 >=20 > There have been a number of other drafts that have approached HTTP = request signing as well (I=E2=80=99ve written two of them myself), but = none has caught on to date and none have made it to RFC. Lately, though, = I=E2=80=99ve been seeing a lot of renewed effort in different sectors, = and in particular the financial sector and cloud services, to have a = general purpose HTTP message signing capability. As such, I think it=E2=80= =99s time to push something forward.=20 >=20 > I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot. >=20 > Thank you, and I=E2=80=99ll see you all in Singapore! > =E2=80=94 Justin > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Sat Nov 2 15:39:03 2019 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 3A8C4120020; Sat, 2 Nov 2019 15:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5rSe07WxTThn; Sat, 2 Nov 2019 15:38:59 -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 32A7F12003E; Sat, 2 Nov 2019 15:38:59 -0700 (PDT) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA2Mcu0I011820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 2 Nov 2019 18:38:57 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Sat, 2 Nov 2019 18:38:56 -0400 Cc: dispatch@ietf.org, secdispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> References: To: Mark Nottingham X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 02 Nov 2019 22:39:01 -0000 Thanks for the pointer to the BoF, I hadn=E2=80=99t seen that one. I am = familiar with the draft you linked though: The main difference is that = the draft in question is for a signed response, whereas the draft(s) = I=E2=80=99ve pointed at are for a signed request. Yes, they ought to be = aligned, but the WG in question seems to be much more focused on = packaging responses together than dealing with requests. If that new = group also wants to take on request signing, then by all means let=E2=80=99= s do it there. But it=E2=80=99s not as clean a match as it might seem on = the surface, I think. =E2=80=94 Justin > On Nov 2, 2019, at 12:26 AM, Mark Nottingham wrote: >=20 > Hi Justin, >=20 > It's worth noting that there's a Working Group forming BoF, wpack, = being held in Singapore about a draft with similar goals: > = https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07 >=20 > In particular, both this draft and Jeffrey's propose the Signature = HTTP header field, and seem to have at least partially overlapping use = cases. >=20 > If possible, it'd be good to avoid duplication of effort -- especially = in terms of evaluating security properties and "fit" into HTTP by the = security and HTTP communities, respectively. So, I'd suggest bringing it = up there instead. >=20 > Cheers, =20 >=20 >=20 >> On 2 Nov 2019, at 8:59 am, Justin Richer wrote: >>=20 >> I would like to present and discuss HTTP Request signing at both the = DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of = different external groups and efforts: >>=20 >> https://tools.ietf.org/html/draft-cavage-http-signatures >>=20 >> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d = like to find out how to bring this forward to publication within the = IETF. I=E2=80=99m targeting both dispatch groups because this represents = the intersection of both areas, and I think we=E2=80=99d get different = perspectives from each side that we should consider.=20 >>=20 >> There have been a number of other drafts that have approached HTTP = request signing as well (I=E2=80=99ve written two of them myself), but = none has caught on to date and none have made it to RFC. Lately, though, = I=E2=80=99ve been seeing a lot of renewed effort in different sectors, = and in particular the financial sector and cloud services, to have a = general purpose HTTP message signing capability. As such, I think it=E2=80= =99s time to push something forward.=20 >>=20 >> I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot. >>=20 >> Thank you, and I=E2=80=99ll see you all in Singapore! >> =E2=80=94 Justin >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Sat Nov 2 20:18:35 2019 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 587DF120096 for ; Sat, 2 Nov 2019 20:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 lJvqufHaVdOJ for ; Sat, 2 Nov 2019 20:18:28 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 9A6FA120046 for ; Sat, 2 Nov 2019 20:18:28 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id 15so14358246qkh.6 for ; Sat, 02 Nov 2019 20:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4nWYxApDoLqBFCEEkYDMhmNLPWLG6CoiGB51MDj1NYo=; b=Gu7Jgub+g1ZGwST5SgIqu39Yn2UoKxOeuu8RZlYCJpb0jMnHU0JygSOqVPDGsR0T5m LapOP94LBTwgU6LdCG3sig32AG+i9sFbFcmroojBZptOL/SGZslpQvXQZrqV/ZSx9AvO s6k/YkLiF5hoyL3QkYJ5icFxr884BZTmhZfBs= 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=4nWYxApDoLqBFCEEkYDMhmNLPWLG6CoiGB51MDj1NYo=; b=iQJQfFuGZwlF03nhes4CZpcGan4PO0i2xjSaruOzOyGmCGf2KSZJ+ygkCks9ACpgfz tYvBqcKDhsxqW8p/yytFWVKAD/8FPIiHg3Yuh9aQDHZvw+LI2qzv5KAxVuimj1tfF+ey V7eO2jACcxl+htiEDDsP3by3PDRuzfAA+wREBF/q6cdUrWBiEmySlNAYCksVhDRqnTmP BBZVQbs8ECanUmulAxPv3ZIo4sTHB3mhuP0hnwRO92uie9cG931uBu6vugYRwJSRMEi8 TY3nqInU5jN8vGqVHsr5J+UdXGqljweD3tKYBXOh5moIM/vBdjQGePnIx3QPFta1EcgO VrSg== X-Gm-Message-State: APjAAAVW3Cjm5q0MYkhsl84ZeRwGuVxyEB7Kj1fWZYppVhraKiLFHzUq h9Xd5eyGeW5/+lFj3GoEvzZwj/5piwwlRP6Ggob1wg== X-Google-Smtp-Source: APXvYqz3quswWeXhYY6OSwL1r3jBcPB3Vxa9/FEJiiL9Sk08khMm0P2gEgM4VoOpDGxV8MNgfOAz5TuNy+p891F9SHc= X-Received: by 2002:a37:5f81:: with SMTP id t123mr11741589qkb.447.1572751106887; Sat, 02 Nov 2019 20:18:26 -0700 (PDT) MIME-Version: 1.0 References: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> In-Reply-To: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> From: Jeffrey Yasskin Date: Sat, 2 Nov 2019 20:18:15 -0700 Message-ID: To: Justin Richer Cc: Mark Nottingham , dispatch@ietf.org, secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000000c8a98059668a739" Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 03 Nov 2019 03:18:30 -0000 --0000000000000c8a98059668a739 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's roughly what I was going to say. :) I'd like to avoid the scope creep of having WPACK take on request signing in addition to, effectively, response signing. It's *possible* that we could define an HTTP header in a general enough way that it would work for both purposes, and https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-4 attem= pts to do that, but the problem spaces seem to be different enough that we should have separate groups write down the requirements for each side's signatures before deciding that a single header will work. It's not even clear to me that WPACK is going to end up defining an HTTP header, even though my draft currently does so. I'll be sure to attend the request-signing sessions in case they establish that I'm wrong about this. Jeffrey On Sat, Nov 2, 2019 at 3:39 PM Justin Richer wrote: > Thanks for the pointer to the BoF, I hadn=E2=80=99t seen that one. I am f= amiliar > with the draft you linked though: The main difference is that the draft i= n > question is for a signed response, whereas the draft(s) I=E2=80=99ve poin= ted at are > for a signed request. Yes, they ought to be aligned, but the WG in questi= on > seems to be much more focused on packaging responses together than dealin= g > with requests. If that new group also wants to take on request signing, > then by all means let=E2=80=99s do it there. But it=E2=80=99s not as clea= n a match as it > might seem on the surface, I think. > > =E2=80=94 Justin > > > On Nov 2, 2019, at 12:26 AM, Mark Nottingham wrote: > > > > Hi Justin, > > > > It's worth noting that there's a Working Group forming BoF, wpack, bein= g > held in Singapore about a draft with similar goals: > > > https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07 > > > > In particular, both this draft and Jeffrey's propose the Signature HTTP > header field, and seem to have at least partially overlapping use cases. > > > > If possible, it'd be good to avoid duplication of effort -- especially > in terms of evaluating security properties and "fit" into HTTP by the > security and HTTP communities, respectively. So, I'd suggest bringing it = up > there instead. > > > > Cheers, > > > > > >> On 2 Nov 2019, at 8:59 am, Justin Richer wrote: > >> > >> I would like to present and discuss HTTP Request signing at both the > DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has > been floating around for years now and has been adopted by a number of > different external groups and efforts: > >> > >> https://tools.ietf.org/html/draft-cavage-http-signatures > >> > >> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d lik= e to find out how > to bring this forward to publication within the IETF. I=E2=80=99m targeti= ng both > dispatch groups because this represents the intersection of both areas, a= nd > I think we=E2=80=99d get different perspectives from each side that we sh= ould > consider. > >> > >> There have been a number of other drafts that have approached HTTP > request signing as well (I=E2=80=99ve written two of them myself), but no= ne has > caught on to date and none have made it to RFC. Lately, though, I=E2=80= =99ve been > seeing a lot of renewed effort in different sectors, and in particular th= e > financial sector and cloud services, to have a general purpose HTTP messa= ge > signing capability. As such, I think it=E2=80=99s time to push something = forward. > >> > >> I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDISPAT= CH to > request a presentation slot. > >> > >> Thank you, and I=E2=80=99ll see you all in Singapore! > >> =E2=80=94 Justin > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000000c8a98059668a739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's roughly what I was going to say. :) I'= d like to avoid the scope creep of having WPACK take on request signing in = addition to, effectively, response signing. It's *possible* that we cou= ld define an HTTP header in a general enough way that it would work for bot= h purposes, and=C2=A0https://tools.ietf.org/html/draft-cavage-http-s= ignatures-12#section-4=C2=A0attempts to do that, but the problem spaces= seem to be different enough that we should have separate groups write down= the requirements for each side's signatures before deciding that a sin= gle header will work. It's not even clear to me that WPACK is going to = end up defining an HTTP header, even though my draft currently does so.

I'll be sure to attend the request-signing sessio= ns in case they establish=C2=A0that I'm wrong about this.
Jeffrey

On Sat, Nov 2, 2019 at 3:39 PM Justin Richer <jricher@mit.edu> wrote:
Thanks for the pointer to the Bo= F, I hadn=E2=80=99t seen that one. I am familiar with the draft you linked = though: The main difference is that the draft in question is for a signed r= esponse, whereas the draft(s) I=E2=80=99ve pointed at are for a signed requ= est. Yes, they ought to be aligned, but the WG in question seems to be much= more focused on packaging responses together than dealing with requests. I= f that new group also wants to take on request signing, then by all means l= et=E2=80=99s do it there. But it=E2=80=99s not as clean a match as it might= seem on the surface, I think.

=C2=A0=E2=80=94 Justin

> On Nov 2, 2019, at 12:26 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
> Hi Justin,
>
> It's worth noting that there's a Working Group forming BoF, wp= ack, being held in Singapore about a draft with similar goals:
>=C2=A0 https://tools.ie= tf.org/html/draft-yasskin-http-origin-signed-responses-07
>
> In particular, both this draft and Jeffrey's propose the Signature= HTTP header field, and seem to have at least partially overlapping use cas= es.
>
> If possible, it'd be good to avoid duplication of effort -- especi= ally in terms of evaluating security properties and "fit" into HT= TP by the security and HTTP communities, respectively. So, I'd suggest = bringing it up there instead.
>
> Cheers,=C2=A0
>
>
>> On 2 Nov 2019, at 8:59 am, Justin Richer <jricher@mit.edu> wrote:
>>
>> I would like to present and discuss HTTP Request signing at both t= he DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of diff= erent external groups and efforts:
>>
>> https://tools.ietf.org/html/draft-c= avage-http-signatures
>>
>> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d= like to find out how to bring this forward to publication within the IETF.= I=E2=80=99m targeting both dispatch groups because this represents the int= ersection of both areas, and I think we=E2=80=99d get different perspective= s from each side that we should consider.
>>
>> There have been a number of other drafts that have approached HTTP= request signing as well (I=E2=80=99ve written two of them myself), but non= e has caught on to date and none have made it to RFC. Lately, though, I=E2= =80=99ve been seeing a lot of renewed effort in different sectors, and in p= articular the financial sector and cloud services, to have a general purpos= e HTTP message signing capability. As such, I think it=E2=80=99s time to pu= sh something forward.
>>
>> I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDI= SPATCH to request a presentation slot.
>>
>> Thank you, and I=E2=80=99ll see you all in Singapore!
>> =E2=80=94 Justin
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000000c8a98059668a739-- From nobody Sun Nov 3 14:28:34 2019 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 9C70B120043; Sun, 3 Nov 2019 14:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=W7HH+A3h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oyhuSap/ 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 L8n4QV_ieQIY; Sun, 3 Nov 2019 14:28:21 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648E612000F; Sun, 3 Nov 2019 14:28:21 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 52C60213CA; Sun, 3 Nov 2019 17:28:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 03 Nov 2019 17:28:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=n W0SkntqlbpA2HkAY1i1TK+OxCWg75rW0nGT9HT++Ko=; b=W7HH+A3hjqUDXjQqp lkAmLw4sqJ/LDbPJ6jOWgTXfuGYag1mT8PA2OqpZ7UYTC8a46LEZ0Z//JXNaxT9E qGNC52rwTkNdlsXoB46dMilz1SvYaOZwEzDWwVgEf9hTnQTzeCZzgqHHIOR47s66 vgskeMdmAcD4DZLnW7/bUVJtJoP8gYzTTJm1qGwPQ+PCNI0oxR6SOHlZDyYHX0iP VuAxTAWlhQ7iFaKPGhabs2rEpjkfOmUsn8WzG4aAPTSlHEIS1xVZESXiV61OlLor R0q+b23Szb0zZb5/HFtXiV4HxMU7OS9UpeLGLMOd/lULFqze127rhSCjI/Pn4S4t BC4OA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm1; bh=nW0SkntqlbpA2HkAY1i1TK+OxCWg75rW0nGT9HT++ Ko=; b=oyhuSap/DZxI2sefPgdezR6aSGr/A6J+qgDDvQLCFGpo+rP8C8BdTP4NX 2cm+nWN3R//YYVn/WIJ3ziCdWRmM+G4Py+mPuXqac9r7bmudbFheUwejn8CzHon/ EgJC8dkHATT/dtekbPW2DXchcP+nBswS0RE7XNm8UhOfQY55v6ta8PTEhbs6Akgk YQ1aCE6sTNDQ+oP5MRK3zs6f1HFWBNXGVfdkSEGMyhqq4GnAvdAOpQRRNOZ/4qF7 VM7+JPWFvMG8TM3dCVaHp0ts+JWar4VjTrtHbSMlBMareiK3SYvl9u3xpAfSAnR4 dJRkmR2jkPc3Dvbn+XPulqdiQqsvg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduuddgudeihecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehhthhtphgtohhmmhhunhhithhivghsrhgvshhpvggtthhivhgvlhihrdhsohdphhht thhpmhgvshhsrghgvghsihhgnhhinhhgtggrphgrsghilhhithihrdgrshdpihgvthhfrd horhhgpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecurfgr rhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrh fuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id DCDD980059; Sun, 3 Nov 2019 17:28:12 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Mark Nottingham In-Reply-To: Date: Mon, 4 Nov 2019 09:28:08 +1100 Cc: Justin Richer , dispatch@ietf.org, secdispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> To: Jeffrey Yasskin X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 03 Nov 2019 22:28:24 -0000 I understand -- I just want to make sure the discussions are = coordinated, not had in isolation. Cheers, > On 3 Nov 2019, at 2:18 pm, Jeffrey Yasskin = wrote: >=20 > That's roughly what I was going to say. :) I'd like to avoid the scope = creep of having WPACK take on request signing in addition to, = effectively, response signing. It's *possible* that we could define an = HTTP header in a general enough way that it would work for both = purposes, and = https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-4 = attempts to do that, but the problem spaces seem to be different enough = that we should have separate groups write down the requirements for each = side's signatures before deciding that a single header will work. It's = not even clear to me that WPACK is going to end up defining an HTTP = header, even though my draft currently does so. >=20 > I'll be sure to attend the request-signing sessions in case they = establish that I'm wrong about this. >=20 > Jeffrey >=20 > On Sat, Nov 2, 2019 at 3:39 PM Justin Richer wrote: > Thanks for the pointer to the BoF, I hadn=E2=80=99t seen that one. I = am familiar with the draft you linked though: The main difference is = that the draft in question is for a signed response, whereas the = draft(s) I=E2=80=99ve pointed at are for a signed request. Yes, they = ought to be aligned, but the WG in question seems to be much more = focused on packaging responses together than dealing with requests. If = that new group also wants to take on request signing, then by all means = let=E2=80=99s do it there. But it=E2=80=99s not as clean a match as it = might seem on the surface, I think. >=20 > =E2=80=94 Justin >=20 > > On Nov 2, 2019, at 12:26 AM, Mark Nottingham wrote: > >=20 > > Hi Justin, > >=20 > > It's worth noting that there's a Working Group forming BoF, wpack, = being held in Singapore about a draft with similar goals: > > = https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07 > >=20 > > In particular, both this draft and Jeffrey's propose the Signature = HTTP header field, and seem to have at least partially overlapping use = cases. > >=20 > > If possible, it'd be good to avoid duplication of effort -- = especially in terms of evaluating security properties and "fit" into = HTTP by the security and HTTP communities, respectively. So, I'd suggest = bringing it up there instead. > >=20 > > Cheers, =20 > >=20 > >=20 > >> On 2 Nov 2019, at 8:59 am, Justin Richer wrote: > >>=20 > >> I would like to present and discuss HTTP Request signing at both = the DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D = has been floating around for years now and has been adopted by a number = of different external groups and efforts: > >>=20 > >> https://tools.ietf.org/html/draft-cavage-http-signatures > >>=20 > >> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d = like to find out how to bring this forward to publication within the = IETF. I=E2=80=99m targeting both dispatch groups because this represents = the intersection of both areas, and I think we=E2=80=99d get different = perspectives from each side that we should consider.=20 > >>=20 > >> There have been a number of other drafts that have approached HTTP = request signing as well (I=E2=80=99ve written two of them myself), but = none has caught on to date and none have made it to RFC. Lately, though, = I=E2=80=99ve been seeing a lot of renewed effort in different sectors, = and in particular the financial sector and cloud services, to have a = general purpose HTTP message signing capability. As such, I think it=E2=80= =99s time to push something forward.=20 > >>=20 > >> I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot. > >>=20 > >> Thank you, and I=E2=80=99ll see you all in Singapore! > >> =E2=80=94 Justin > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >=20 > > -- > > Mark Nottingham https://www.mnot.net/ > >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Sun Nov 3 20:09:23 2019 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 BB6D912080D for ; Sun, 3 Nov 2019 20:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cloudflare.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 2Wh3qh7HWB_y for ; Sun, 3 Nov 2019 20:09:19 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 74A98120251 for ; Sun, 3 Nov 2019 20:09:19 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id 190so5606613vss.8 for ; Sun, 03 Nov 2019 20:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=TYaVZscr3tMEWiUoeC0p0ukno8VjwbYyTR7pAWYyV0o=; b=Jt9U3BIYdArrRYkbCl+9Fl6XWkBh+VtCVbStNmTuDTwmTPpAk7EcbU2X8Jn5VVcFoo HWikKkJAaIbm/IflHm5YNr2efEa12Gs/hGnMs6Aic28g0z5tF6sVJij7uc5AqLl/mjsJ oENZSU4ZbS1w/tazrtWnv6pxYFlnTZnmzCNQ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=TYaVZscr3tMEWiUoeC0p0ukno8VjwbYyTR7pAWYyV0o=; b=ND8tykgvbzL5XTf1aD16abYElmFf7X600Cps1YIFDK4exsTsJEFQsYMHW5FgfmxIni xYgfyNQPMsY2B/JIHAnG7EAoPixKf3mIhtXfs2eie43VARDz0uBBVwMltk7xBH45ICsI T7ixkou7Qxo2/vxcd2hwXw+5GDBXPUIHx5wJGbFEFv1pAnrjrLH0wptUvsk7fppihdpK JwHYAQk80wJdR7GAV26MB+sN/xJW7lpftKNzpZGKyL4jZOAzarJ5kYx3iCdUSMwY/3Nc zi8JLgPSvsVkvIqYE2GCNcu+xqKG5OUsV2W9P3PstlVze5wgYWvvzRTe3l6r1tyYc9zB ueYQ== X-Gm-Message-State: APjAAAWLha9xDq83Q+OgyThk9XmC9Vc3yZFa3IFBkySlNNFmIhs22o0I pHlYIC5xjpPnCVpNDtJczu01Ltyxpb/WvoPH4CcK+Q== X-Google-Smtp-Source: APXvYqwe5J/1K6hM7zt8ERnqjX6s3gaBwzY6AJKvBOcjAvDAPPmOVWEfaqZMRvuLFh6Wri5W7iyEBknzcTf9kRg6U0U= X-Received: by 2002:a67:de8d:: with SMTP id r13mr6507906vsk.172.1572840558162; Sun, 03 Nov 2019 20:09:18 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Sun, 3 Nov 2019 20:09:01 -0800 Message-ID: To: Kathleen Moriarty , Richard Barnes Cc: Alex Davidson , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2283805967d7a02" Archived-At: Subject: [Secdispatch] secdispatch agenda request: draft-privacy-pass-00 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, 04 Nov 2019 04:09:22 -0000 --000000000000c2283805967d7a02 Content-Type: text/plain; charset="UTF-8" Kathleen and Richard, Alex Davidson and I have a draft we'd like to discuss at Secdispatch. The draft outlines the Privacy Pass protocol currently in use at Cloudflare ( https://blog.cloudflare.com/supporting-the-latest-version-of-the-privacy-pass-protocol/ ). Here are the documents: https://datatracker.ietf.org/doc/draft-privacy-pass/ https://tools.ietf.org/html/draft-privacy-pass-00 This is a substantial piece of work, so it may require its own working group to tackle. Hopefully, SecDispatch will be able to provide some guidance around where this work can find a home. Nick --000000000000c2283805967d7a02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kathleen and Richard,

Alex D= avidson and I have a draft we'd like to discuss at Secdispatch. The dra= ft outlines the Privacy Pass protocol currently in use at Cloudflare (https://blog.cloudflare.com/supporting-the-latest-versi= on-of-the-privacy-pass-protocol/).

Here are th= e documents:
https://datatracker.ietf.org/doc/draft-privacy-pass/
https://tools.i= etf.org/html/draft-privacy-pass-00

This is= a substantial piece of work, so it may require=C2=A0its own working group = to tackle. Hopefully, SecDispatch will be able to provide some guidance aro= und where this work can find a home.

Nick

--000000000000c2283805967d7a02-- From nobody Mon Nov 4 05:44:46 2019 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 A0947120106; Mon, 4 Nov 2019 05:44:36 -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_DNSWL_NONE=-0.0001, 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 UCbxECciBEuB; Mon, 4 Nov 2019 05:44:34 -0800 (PST) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 52C13120154; Mon, 4 Nov 2019 05:44:34 -0800 (PST) Received: by mail-oi1-f179.google.com with SMTP id s71so14079907oih.11; Mon, 04 Nov 2019 05:44:34 -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=jtA5X1tmx5/aInP0/x9ZjyagOIrGZ/LUM8Su1f7iioA=; b=Erput7vEqzesJXaonQjgTAedzNX3q9mxq8fELD1iGtZ8sF0j095xUmN6iY1VuoMofc Kh2081KF6avBaYKT810xZ5ygIIRwtDcHyBacSip275bCP+ku0DKuIFCSCqmubL1YXAO+ smXypwukgx11dacQU3GCi/sZRVifq+Z3tZ/M5MFXyPyPL8kupDXwPlHQwi0qAfLB9rbu GoEb39JPjgkHpzi7RTxrqHK0Q2cZkpTg8C2ZtN3Wf18LTJattR743pfgg2BSAKkb7NED 4txSf7JcXsEJ4R/pBWN4eosiRrfwbV/8MfzvR1C4beLOwUtandjakaph2/A4J1P9IWsx DgOw== X-Gm-Message-State: APjAAAVfDd3/35dnUVcOBQ7CtrGGoGDg+VayTUaSlKsbBi6k8sU4AlGq Oh/zid1pCz2gpGJtoq6+Sd6sCLaMwQDYw2RVXuA= X-Google-Smtp-Source: APXvYqzQVneB0N+x2tI/nLYr3PqqWcRRwvpHGYr+0PL23oqwAUlLkk/xJDf3pDQv6mIReLcagM3XHTuhBUDMQmNIKBs= X-Received: by 2002:a54:4499:: with SMTP id v25mr234932oiv.17.1572875073560; Mon, 04 Nov 2019 05:44:33 -0800 (PST) MIME-Version: 1.0 References: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> In-Reply-To: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> From: Phillip Hallam-Baker Date: Mon, 4 Nov 2019 08:44:22 -0500 Message-ID: To: Justin Richer Cc: Mark Nottingham , dispatch@ietf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000009259f059685841f" Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 04 Nov 2019 13:44:37 -0000 --00000000000009259f059685841f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 2, 2019 at 6:39 PM Justin Richer wrote: > Thanks for the pointer to the BoF, I hadn=E2=80=99t seen that one. I am f= amiliar > with the draft you linked though: The main difference is that the draft i= n > question is for a signed response, whereas the draft(s) I=E2=80=99ve poin= ted at are > for a signed request. Yes, they ought to be aligned, but the WG in questi= on > seems to be much more focused on packaging responses together than dealin= g > with requests. If that new group also wants to take on request signing, > then by all means let=E2=80=99s do it there. But it=E2=80=99s not as clea= n a match as it > might seem on the surface, I think. > I think it is actually very different, not least because it is not yet clear that WPACK is even proposing a new format or not. As it happens, I developed a ZIP archive format while back-testing the DARE append only log file spec: http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html If we were going to redo ZIP at this point it should be to use modern cryptographic techniques. The signature should be a Merkle tree for a start (see CT). And if you are going to sign/verify your archive with a single operation, you should be able to encrypt/decrypt with one operation as well= . I have looked into signing HTTP headers many times beginning with Shen in 1993. I don't think it is actually very useful because of the way HTTP is structured. If routing information had been separate from content metadata... I don't yet have running code to support it, but my plan for authenticating Mesh Service requests and responses is to wrap them in a cryptographic envelope (I am using DARE but you could do the same thing in PKCS#7/CMS). The envelope is always authenticated but the mode of the authentication can be a signature, a MAC/AEM via a mutually authenticated key exchange or a MAC/AEM under a ticket. At this stage, the only part of HTTP I am actually using for my 'Web Service' is the stem section of the URI which provides me with additional ports. There is also a BOF on MATHMESH in Singapore. DARE is a part of the Mesh. --00000000000009259f059685841f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 2, 2019 at 6:39 PM Justin Richer <jricher@mit.edu> wrote:
Than= ks for the pointer to the BoF, I hadn=E2=80=99t seen that one. I am familia= r with the draft you linked though: The main difference is that the draft i= n question is for a signed response, whereas the draft(s) I=E2=80=99ve poin= ted at are for a signed request. Yes, they ought to be aligned, but the WG = in question seems to be much more focused on packaging responses together t= han dealing with requests. If that new group also wants to take on request = signing, then by all means let=E2=80=99s do it there. But it=E2=80=99s not = as clean a match as it might seem on the surface, I think.
=

= I think it is actually very different, not least because it is not yet clea= r that WPACK is even proposing a new format or not. As it happens, I develo= ped a ZIP archive format while back-testing the DARE append only log file s= pec:

=
http://mathmesh.com/= Documents/draft-hallambaker-mesh-dare.html

If we were going to redo ZIP= at this point it should be to use modern cryptographic techniques. The sig= nature should be a Merkle tree for a start (see CT). And if you are going t= o sign/verify your archive with a single operation, you should be able to e= ncrypt/decrypt with one operation as well.

I have looked into signing HTT= P headers many times beginning with Shen in 1993. I don't think it is a= ctually very useful because of the way HTTP is structured. If routing infor= mation had been separate from content metadata...

I don't yet have running code to support it, b= ut my plan for authenticating Mesh Service requests and responses is to wra= p them in a cryptographic envelope (I am using DARE but you could do the sa= me thing in PKCS#7/CMS).

= The envelope is always authenticated but the mode of the authentication can= be a signature, a MAC/AEM via a mutually authenticated key exchange or a M= AC/AEM under a ticket.

At this stage, the only part of HTTP I am= actually using for my 'Web Service' is the stem section of the URI= which provides me with additional ports.=C2=A0

There is also a BOF on MATHMESH in Singapore. DARE i= s a part of the Mesh.

--00000000000009259f059685841f-- From nobody Mon Nov 4 10:20:24 2019 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 51025120115 for ; Mon, 4 Nov 2019 10:20:23 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 u1q3QTdu6EK1 for ; Mon, 4 Nov 2019 10:20:19 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9A17712011F for ; Mon, 4 Nov 2019 10:20:19 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 5A44D3741098 for ; Mon, 4 Nov 2019 18:20:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pLj4G7s8q-M0 for ; Mon, 4 Nov 2019 13:20:18 -0500 (EST) Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id E09F737408CB for ; Mon, 4 Nov 2019 13:20:17 -0500 (EST) To: secdispatch@ietf.org References: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> From: "Dr. Pala" Message-ID: <400abd10-3bbc-2288-b357-f36ad721cebf@openca.org> Date: Mon, 4 Nov 2019 11:20:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CB8D6AC057F463EC38642290" Content-Language: en-US Archived-At: Subject: [Secdispatch] Updating/Replacing RFC 2660 ? (was Re: [dispatch] HTTP Request Signing) 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, 04 Nov 2019 18:20:24 -0000 This is a multi-part message in MIME format. --------------CB8D6AC057F463EC38642290 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jeffrey, Justin, Mark, all, I have not had the time to read the proposals, but are you familiar with RFC 2660 ? Would that provide the authentication you are talking about for both requests and responses ? Is the proposal to update / replace the RFC or do you see it as something completely different ? Cheers, Max On 11/2/19 9:18 PM, Jeffrey Yasskin wrote: > That's roughly what I was going to say. :) I'd like to avoid the scope > creep of having WPACK take on request signing in addition to, > effectively, response signing. It's *possible* that we could define an > HTTP header in a general enough way that it would work for both > purposes, and > https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-4 attempts > to do that, but the problem spaces seem to be different enough that we > should have separate groups write down the requirements for each > side's signatures before deciding that a single header will work. It's > not even clear to me that WPACK is going to end up defining an HTTP > header, even though my draft currently does so. > > I'll be sure to attend the request-signing sessions in case they > establish that I'm wrong about this. > > Jeffrey > > On Sat, Nov 2, 2019 at 3:39 PM Justin Richer > wrote: > > Thanks for the pointer to the BoF, I hadn’t seen that one. I am > familiar with the draft you linked though: The main difference is > that the draft in question is for a signed response, whereas the > draft(s) I’ve pointed at are for a signed request. Yes, they ought > to be aligned, but the WG in question seems to be much more > focused on packaging responses together than dealing with > requests. If that new group also wants to take on request signing, > then by all means let’s do it there. But it’s not as clean a match > as it might seem on the surface, I think. > >  — Justin > > > On Nov 2, 2019, at 12:26 AM, Mark Nottingham > wrote: > > > > Hi Justin, > > > > It's worth noting that there's a Working Group forming BoF, > wpack, being held in Singapore about a draft with similar goals: > > > https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07 > > > > In particular, both this draft and Jeffrey's propose the > Signature HTTP header field, and seem to have at least partially > overlapping use cases. > > > > If possible, it'd be good to avoid duplication of effort -- > especially in terms of evaluating security properties and "fit" > into HTTP by the security and HTTP communities, respectively. So, > I'd suggest bringing it up there instead. > > > > Cheers, > > > > > >> On 2 Nov 2019, at 8:59 am, Justin Richer > wrote: > >> > >> I would like to present and discuss HTTP Request signing at > both the DISPATCH and SECDISPATCH meetings at IETF106 in > Singapore. This I-D has been floating around for years now and has > been adopted by a number of different external groups and efforts: > >> > >> https://tools.ietf.org/html/draft-cavage-http-signatures > >> > >> I’ve spoken with the authors of the draft and we’d like to find > out how to bring this forward to publication within the IETF. I’m > targeting both dispatch groups because this represents the > intersection of both areas, and I think we’d get different > perspectives from each side that we should consider. > >> > >> There have been a number of other drafts that have approached > HTTP request signing as well (I’ve written two of them myself), > but none has caught on to date and none have made it to RFC. > Lately, though, I’ve been seeing a lot of renewed effort in > different sectors, and in particular the financial sector and > cloud services, to have a general purpose HTTP message signing > capability. As such, I think it’s time to push something forward. > >> > >> I’ve reached out to the chairs for both DISPATCH and > SECDISPATCH to request a presentation slot. > >> > >> Thank you, and I’ll see you all in Singapore! > >> — Justin > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------CB8D6AC057F463EC38642290 Content-Type: multipart/related; boundary="------------40CFB8B33FE25CBBC0858719" --------------40CFB8B33FE25CBBC0858719 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Jeffrey, Justin, Mark, all,

I have not had the time to read the proposals, but are you familiar with RFC 2660 ?

Would that provide the authentication you are talking about for both requests and responses ?

Is the proposal to update / replace the RFC or do you see it as something completely different ?

Cheers,
Max

On 11/2/19 9:18 PM, Jeffrey Yasskin wrote:
That's roughly what I was going to say. :) I'd like to avoid the scope creep of having WPACK take on request signing in addition to, effectively, response signing. It's *possible* that we could define an HTTP header in a general enough way that it would work for both purposes, and https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-4 attempts to do that, but the problem spaces seem to be different enough that we should have separate groups write down the requirements for each side's signatures before deciding that a single header will work. It's not even clear to me that WPACK is going to end up defining an HTTP header, even though my draft currently does so.

I'll be sure to attend the request-signing sessions in case they establish that I'm wrong about this.

Jeffrey

On Sat, Nov 2, 2019 at 3:39 PM Justin Richer <jricher@mit.edu> wrote:
Thanks for the pointer to the BoF, I hadn’t seen that one. I am familiar with the draft you linked though: The main difference is that the draft in question is for a signed response, whereas the draft(s) I’ve pointed at are for a signed request. Yes, they ought to be aligned, but the WG in question seems to be much more focused on packaging responses together than dealing with requests. If that new group also wants to take on request signing, then by all means let’s do it there. But it’s not as clean a match as it might seem on the surface, I think.

 — Justin

> On Nov 2, 2019, at 12:26 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
> Hi Justin,
>
> It's worth noting that there's a Working Group forming BoF, wpack, being held in Singapore about a draft with similar goals:
>  https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07
>
> In particular, both this draft and Jeffrey's propose the Signature HTTP header field, and seem to have at least partially overlapping use cases.
>
> If possible, it'd be good to avoid duplication of effort -- especially in terms of evaluating security properties and "fit" into HTTP by the security and HTTP communities, respectively. So, I'd suggest bringing it up there instead.
>
> Cheers, 
>
>
>> On 2 Nov 2019, at 8:59 am, Justin Richer <jricher@mit.edu> wrote:
>>
>> I would like to present and discuss HTTP Request signing at both the DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has been floating around for years now and has been adopted by a number of different external groups and efforts:
>>
>> https://tools.ietf.org/html/draft-cavage-http-signatures
>>
>> I’ve spoken with the authors of the draft and we’d like to find out how to bring this forward to publication within the IETF. I’m targeting both dispatch groups because this represents the intersection of both areas, and I think we’d get different perspectives from each side that we should consider.
>>
>> There have been a number of other drafts that have approached HTTP request signing as well (I’ve written two of them myself), but none has caught on to date and none have made it to RFC. Lately, though, I’ve been seeing a lot of renewed effort in different sectors, and in particular the financial sector and cloud services, to have a general purpose HTTP message signing capability. As such, I think it’s time to push something forward.
>>
>> I’ve reached out to the chairs for both DISPATCH and SECDISPATCH to request a presentation slot.
>>
>> Thank you, and I’ll see you all in Singapore!
>> — Justin
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> --
> Mark Nottingham   https://www.mnot.net/
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------40CFB8B33FE25CBBC0858719 Content-Type: image/png; name="ahmbpbpejgebnmek.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ahmbpbpejgebnmek.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------40CFB8B33FE25CBBC0858719-- --------------CB8D6AC057F463EC38642290-- From nobody Mon Nov 4 10:33:49 2019 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 98CA11200FE for ; Mon, 4 Nov 2019 10:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCRPDVwrfCAe for ; Mon, 4 Nov 2019 10:33:44 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 6F52A12091D for ; Mon, 4 Nov 2019 10:33:43 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id v8so12981802lfa.12 for ; Mon, 04 Nov 2019 10:33:43 -0800 (PST) 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=Qlz9PbOhJzcTY1MPYLC/NVtgyosKY2suxArYDYw7Xg4=; b=xIr65xJN6rl7gjrNn2RxfR+ocVTHBGE+xUM0WgvHK3dK5GTFuaUwra8cVHnfvkHJXI /WG8MbGQkGyWHBbS0R14XlYzH0nI6TfiV2R49bkqwikqDOAxunhtBaomsUE4x7oEnKHn XDXR3z0L642zzg8ELaQgsz84b9bry3ZFvRevGcgfu9Quz5bojCVEkokOf4SQHt1Wp0zh 5cX8EfgYhsxrRflPFFY07cM5ajOkga/lfnmm9mYKDT61eHCh9KEhAQk50f4C9zyb1UPZ 3ZjK3UEurNeTwCfjRKtwxIwW7pL2LcQsgD1Ily8KwBxz376GZr92Gy+/jhr0d+Cp4mRg BPmg== 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=Qlz9PbOhJzcTY1MPYLC/NVtgyosKY2suxArYDYw7Xg4=; b=nNu/W+/SZ7QOIJdULZssJ9oFLv2c3z1egMw0Tf9p/i2SGXxV2lnUvWAul2ikI2eRLO Qhf4lUdVaoJEdHf1ZMy4OLgNNhh5SmBVW7HsTaMgCHqID1Jh7tgaIp9xcP3EUvRS7fyM ArioD0ak6OwVBIQeJyYvnVQ1m6txNyPRK22V9wq8Ah6sBfwEsj9UUT6rLUVtMHILxYwf auG/jZ1Uk0GXqDIIaaWKfcQdDdWSivzFsSjGNG3f14m/E0pDLGaU4ykRcziD1uGTBiQQ VJf5pz+gZVNM5IyDUik/XrwTKaoMwrJp5vcXOida2pGocFVQD7aYQW37ohD5l6zAky+Q y/QQ== X-Gm-Message-State: APjAAAW3UWOtAMieVxWhk5drsJrP8UDQRlwJdWaw/bPnk2S9iRrV4zk9 O1Gl0qaPUjXaNMpgLnrlUFPlioZTQ20PAXgOu4bgmKfq X-Google-Smtp-Source: APXvYqyrvVwFf50cXMvhRTo/kzch9+6rq5Or6EVdUPsG5gXGktcesGEF+jTZyLpJfivy4S8Uyo/r7gl4pD1gAVNkqf8= X-Received: by 2002:ac2:4248:: with SMTP id m8mr17545677lfl.94.1572892421540; Mon, 04 Nov 2019 10:33:41 -0800 (PST) MIME-Version: 1.0 References: <2AC5BD50-53E3-41CE-A2C3-C25D310A89ED@mit.edu> <400abd10-3bbc-2288-b357-f36ad721cebf@openca.org> In-Reply-To: <400abd10-3bbc-2288-b357-f36ad721cebf@openca.org> From: Eric Rescorla Date: Mon, 4 Nov 2019 10:33:04 -0800 Message-ID: To: "Dr. Pala" Cc: IETF SecDispatch Content-Type: multipart/related; boundary="0000000000000f100b0596898e61" Archived-At: Subject: Re: [Secdispatch] Updating/Replacing RFC 2660 ? (was Re: [dispatch] HTTP Request Signing) 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, 04 Nov 2019 18:33:47 -0000 --0000000000000f100b0596898e61 Content-Type: multipart/alternative; boundary="0000000000000f100a0596898e60" --0000000000000f100a0596898e60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking as one of the authors of 2660, if we want to attack these problems, I don't think it is really a suitable starting point, though perhaps there are ideas we could steal. -Ekr On Mon, Nov 4, 2019 at 10:20 AM Dr. Pala wrote: > Hi Jeffrey, Justin, Mark, all, > > I have not had the time to read the proposals, but are you familiar with > RFC 2660 ? > > Would that provide the authentication you are talking about for both > requests and responses ? > > Is the proposal to update / replace the RFC or do you see it as something > completely different ? > > Cheers, > Max > > On 11/2/19 9:18 PM, Jeffrey Yasskin wrote: > > That's roughly what I was going to say. :) I'd like to avoid the scope > creep of having WPACK take on request signing in addition to, effectively= , > response signing. It's *possible* that we could define an HTTP header in = a > general enough way that it would work for both purposes, and > https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-4 att= empts > to do that, but the problem spaces seem to be different enough that we > should have separate groups write down the requirements for each side's > signatures before deciding that a single header will work. It's not even > clear to me that WPACK is going to end up defining an HTTP header, even > though my draft currently does so. > > I'll be sure to attend the request-signing sessions in case they > establish that I'm wrong about this. > > Jeffrey > > On Sat, Nov 2, 2019 at 3:39 PM Justin Richer wrote: > >> Thanks for the pointer to the BoF, I hadn=E2=80=99t seen that one. I am = familiar >> with the draft you linked though: The main difference is that the draft = in >> question is for a signed response, whereas the draft(s) I=E2=80=99ve poi= nted at are >> for a signed request. Yes, they ought to be aligned, but the WG in quest= ion >> seems to be much more focused on packaging responses together than deali= ng >> with requests. If that new group also wants to take on request signing, >> then by all means let=E2=80=99s do it there. But it=E2=80=99s not as cle= an a match as it >> might seem on the surface, I think. >> >> =E2=80=94 Justin >> >> > On Nov 2, 2019, at 12:26 AM, Mark Nottingham wrote: >> > >> > Hi Justin, >> > >> > It's worth noting that there's a Working Group forming BoF, wpack, >> being held in Singapore about a draft with similar goals: >> > >> https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-0= 7 >> > >> > In particular, both this draft and Jeffrey's propose the Signature HTT= P >> header field, and seem to have at least partially overlapping use cases. >> > >> > If possible, it'd be good to avoid duplication of effort -- especially >> in terms of evaluating security properties and "fit" into HTTP by the >> security and HTTP communities, respectively. So, I'd suggest bringing it= up >> there instead. >> > >> > Cheers, >> > >> > >> >> On 2 Nov 2019, at 8:59 am, Justin Richer wrote: >> >> >> >> I would like to present and discuss HTTP Request signing at both the >> DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has >> been floating around for years now and has been adopted by a number of >> different external groups and efforts: >> >> >> >> https://tools.ietf.org/html/draft-cavage-http-signatures >> >> >> >> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d li= ke to find out >> how to bring this forward to publication within the IETF. I=E2=80=99m ta= rgeting >> both dispatch groups because this represents the intersection of both >> areas, and I think we=E2=80=99d get different perspectives from each sid= e that we >> should consider. >> >> >> >> There have been a number of other drafts that have approached HTTP >> request signing as well (I=E2=80=99ve written two of them myself), but n= one has >> caught on to date and none have made it to RFC. Lately, though, I=E2=80= =99ve been >> seeing a lot of renewed effort in different sectors, and in particular t= he >> financial sector and cloud services, to have a general purpose HTTP mess= age >> signing capability. As such, I think it=E2=80=99s time to push something= forward. >> >> >> >> I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDISPA= TCH to >> request a presentation slot. >> >> >> >> Thank you, and I=E2=80=99ll see you all in Singapore! >> >> =E2=80=94 Justin >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> > >> > -- >> > Mark Nottingham https://www.mnot.net/ >> > >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > Secdispatch mailing listSecdispatch@ietf.orghttps://www.ietf.org/mailman/= listinfo/secdispatch > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000000f100a0596898e60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as one of the authors of 2660, if we want to= attack these problems, I don't think it is really a suitable starting = point, though perhaps there are ideas we could steal.

-Ekr


On Mon, Nov 4, 2019 at 10:20 AM Dr. Pala &= lt;madwolf@openca.org> wrote:<= br>
=20 =20 =20

Hi Jeffrey, Justin, Mark, all,

I have not had the time to read the proposals, but are you familiar with RFC 2660 ?

Would that provide the authentication you are talking about for both requests and responses ?

Is the proposal to update / replace the RFC or do you see it as something completely different ?

Cheers,
Max

On 11/2/19 9:18 PM, Jeffrey Yasskin wrote:
=20
That's roughly what I was going to say. :) I'd like to avoid the scope creep of having WPACK take on request signing in addition to, effectively, response signing. It's *possible= * that we could define an HTTP header in a general enough way that it would work for both purposes, and=C2=A0https://tools.ietf.org/html/draft-cavage-http-signatures-12#section-= 4=C2=A0attempts to do that, but the problem spaces seem to be different enough that we should have separate groups write down the requirements for each side's signatures before deciding that = a single header will work. It's not even clear to me that WPACK is going to end up defining an HTTP header, even though my draft currently does so.

I'll be sure to attend the request-signing sessions in cas= e they establish=C2=A0that I'm wrong about this.

Jeffrey

On Sat, Nov 2, 2019 at 3:39 PM Justin Richer <jricher@mit.edu> wrote:
Thanks for the = pointer to the BoF, I hadn=E2=80=99t seen that one. I am familiar with the draft you linked though: The main difference is that the draft in question is for a signed response, whereas the draft(s) I=E2=80=99ve pointed at are for a signed request. Yes,= they ought to be aligned, but the WG in question seems to be much more focused on packaging responses together than dealing with requests. If that new group also wants to take on request signing, then by all means let=E2=80=99s do it there. B= ut it=E2=80=99s not as clean a match as it might seem on the surfa= ce, I think.

=C2=A0=E2=80=94 Justin

> On Nov 2, 2019, at 12:26 AM, Mark Nottingham <mnot@mnot.net> wrote: >
> Hi Justin,
>
> It's worth noting that there's a Working Group for= ming BoF, wpack, being held in Singapore about a draft with similar goals:
>=C2=A0 http= s://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-07 >
> In particular, both this draft and Jeffrey's propose the Signature HTTP header field, and seem to have at least partially overlapping use cases.
>
> If possible, it'd be good to avoid duplication of effort -- especially in terms of evaluating security properties and "fit" into HTTP by the security and HT= TP communities, respectively. So, I'd suggest bringing it up there instead.
>
> Cheers,=C2=A0
>
>
>> On 2 Nov 2019, at 8:59 am, Justin Richer <jricher@mit.edu> wrote= :
>>
>> I would like to present and discuss HTTP Request signing at both the DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has been floating around for years now and has been adopted by a number of different external groups and efforts:
>>
>> https://tools.ietf.org/= html/draft-cavage-http-signatures
>>
>> I=E2=80=99ve spoken with the authors of the draft and = we=E2=80=99d like to find out how to bring this forward to publication within the IETF. I=E2=80=99m targeting both dispatch groups bec= ause this represents the intersection of both areas, and I think we=E2=80=99d get different perspectives from each side that we should consider.
>>
>> There have been a number of other drafts that have approached HTTP request signing as well (I=E2=80=99ve written t= wo of them myself), but none has caught on to date and none have made it to RFC. Lately, though, I=E2=80=99ve been seeing a lot = of renewed effort in different sectors, and in particular the financial sector and cloud services, to have a general purpose HTTP message signing capability. As such, I think it=E2=80=99s time to push something forward.
>>
>> I=E2=80=99ve reached out to the chairs for both DISPAT= CH and SECDISPATCH to request a presentation slot.
>>
>> Thank you, and I=E2=80=99ll see you all in Singapore!<= br> >> =E2=80=94 Justin
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/list= info/dispatch
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>

_______________________________________________
dispatch mailing list
dispatch= @ietf.org
https://www.ietf.org/mailman/listinfo/dis= patch

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.=
org
https://www.ietf.org/mailman/listinfo/secdispatch
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000000f100a0596898e60-- --0000000000000f100b0596898e61 Content-Type: image/png; name="ahmbpbpejgebnmek.png" Content-Disposition: inline; filename="ahmbpbpejgebnmek.png" Content-Transfer-Encoding: base64 Content-ID: <16e37b03be9fb12a4dd1> X-Attachment-Id: 16e37b03be9fb12a4dd1 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --0000000000000f100b0596898e61-- From nobody Mon Nov 4 12:03:05 2019 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 E84F312006B; Mon, 4 Nov 2019 12:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 K0NcKLD9oTKA; Mon, 4 Nov 2019 12:03:01 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 0AAA1120052; Mon, 4 Nov 2019 12:03:01 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id y127so13219153lfc.0; Mon, 04 Nov 2019 12:03:00 -0800 (PST) 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=yQQ4dbUoHkiq69GcEk+aBQottjn0ebD5aX4sAMqNaS4=; b=JNlfG0SxUQnlQRrzSMSv7Tswo2Hzc2UIAUkJ0sc72+4Xsrz4rD1sOejd4QcnUwLft4 gbOuOoSB4eu2mu9bGXguZfcsYEyYa7FG/k2B5YdDgmOplZc0RE7F148vf9S9/CZIIpKB juxuCrArS3UF+IswAk73yG7zuVLZEzf/eje9ou6OhGW2RcaRk5AGkkEIyQ1LMX3ZJuTt ost/VIXOPwRZxcRFsnef74Eg0EJapfMQyiR+bzkjSEHlGh6YRDz25aetqwzhW2dy0Qh0 vuCOPdiutbmIBOOLCpELn+NodF9fY3zWxoq6VvquRqx1O3sKG3ON4Qsaw8gFzjmBTRGI 0x9Q== 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=yQQ4dbUoHkiq69GcEk+aBQottjn0ebD5aX4sAMqNaS4=; b=ZIP5kR6AmfT3D/6S5TT/8r9Pb6JIMl0TT301Qf0PMJ56SFxyKmn2iKVmSEfSy/nPRd KTyoIYl3Rta2xB46QEIgbV5Kud2M7QBatoTULSLFmlU3NOM03KZntK39VU0XPKX4zvYm 2VHCh4Q3L/ZHOMA9tpRfnzNlTXNP9ugJ5HDHVg/BMK5F7hMhN033EZl/IXTU7PT0BTN9 YPY2ctRoNZU6s11K8wHKw2Q5d0SrsPzmtU3bXjI9hP3UXGE3GHDvF6KZH7FdJ3k7p0Og mwieGX6TljjSPOjoBFtms3HxokHe4NG89koejljvLF/NDzlrrou0LR+k0xNEvPBL03lp zx4w== X-Gm-Message-State: APjAAAVvlLQtipK6JrsWdCKHc2eRVNjr+gHzIaryzoXp0U6RrIVL4CMr E6nkL/FWCeg56jIugD+llva56llRIrOHkkz24B0= X-Google-Smtp-Source: APXvYqws482bGzOV3phxcGuZqKRlzOh6ztdCvWVhJ9BPKmzUdvsECSMYHCRX/sy2hGSh4UktAonBjQOcEglfKcUOAU0= X-Received: by 2002:a19:6f0e:: with SMTP id k14mr18064004lfc.34.1572897779312; Mon, 04 Nov 2019 12:02:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mary Barnes Date: Mon, 4 Nov 2019 14:02:47 -0600 Message-ID: To: Justin Richer Cc: DISPATCH , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000067733c05968acd53" Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 04 Nov 2019 20:03:04 -0000 --00000000000067733c05968acd53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Personally, I'd rather not have the presentation twice, recognizing of course, that not everyone would be able to attend one or the other. But, we will have recordings and as is oft stated, ultimately decisions happen on mailing lists. And, I appreciate and agree with Jeffrey not wanting feature creep in WPACK. One objective of DISPATCH has been to ensure that work that is chartered is discrete enough to finish in a timely manner. You mention other communities that are interested in this. Will they be participating or have they participated in IETF? It's hard for chairs to judge consensus to work on something when the communities interested in the work are not participating in IETF. Mailing list participation is sufficient. DISPATCH agenda is pretty full right now, so this would have to fall into AOB at this juncture if ADs and my WG co-chair agree that we should discuss in DISPATCH. And, perhaps whether it gets a few minutes in SECdispatch might be informed on how it goes in DISPATCH, if we have a chance to discuss it, since you need the agreement that this is a problem IETF should solve from both areas. Regards, Mary DISPATCH WG co-chair On Fri, Nov 1, 2019 at 5:00 PM Justin Richer wrote: > I would like to present and discuss HTTP Request signing at both the > DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has > been floating around for years now and has been adopted by a number of > different external groups and efforts: > > https://tools.ietf.org/html/draft-cavage-http-signatures > > I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d like t= o find out how to > bring this forward to publication within the IETF. I=E2=80=99m targeting = both > dispatch groups because this represents the intersection of both areas, a= nd > I think we=E2=80=99d get different perspectives from each side that we sh= ould > consider. > > There have been a number of other drafts that have approached HTTP reques= t > signing as well (I=E2=80=99ve written two of them myself), but none has c= aught on > to date and none have made it to RFC. Lately, though, I=E2=80=99ve been s= eeing a > lot of renewed effort in different sectors, and in particular the financi= al > sector and cloud services, to have a general purpose HTTP message signing > capability. As such, I think it=E2=80=99s time to push something forward. > > I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDISPATCH = to > request a presentation slot. > > Thank you, and I=E2=80=99ll see you all in Singapore! > =E2=80=94 Justin > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000067733c05968acd53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Personally, I'd rather not have the presentation twice= , recognizing of course, that not everyone would be able to attend one or t= he other. But, we will have recordings and as is oft stated, ultimately dec= isions happen on mailing lists.=C2=A0 And, I appreciate and agree with Jeff= rey not wanting feature creep in WPACK.=C2=A0 One objective of DISPATCH has= been to ensure that work that is chartered is discrete enough to finish in= a timely manner.=C2=A0 =C2=A0

You mention other communi= ties that are interested in this.=C2=A0 Will they be participating or have = they participated in IETF?=C2=A0 =C2=A0 It's hard for chairs to judge c= onsensus to work on something when the communities interested in the work a= re not participating in IETF.=C2=A0 Mailing list participation is sufficien= t.=C2=A0=C2=A0

DISPATCH agenda is pretty full right now,= so this would have to fall into AOB at this juncture if ADs and my WG co-c= hair agree that we should discuss in DISPATCH.=C2=A0 And, perhaps whether i= t gets a few minutes in SECdispatch might be informed on how it goes in DIS= PATCH, if we have a chance to discuss it, since you need the agreement that= this is a problem IETF should solve from both areas.

<= div>Regards,
Mary
DISPATCH WG co-chair


On Fri, Nov 1, 2019 at 5:00 PM Justin Richer <jricher@mit.edu> wrote:
I would like to pr= esent and discuss HTTP Request signing at both the DISPATCH and SECDISPATCH= meetings at IETF106 in Singapore. This I-D has been floating around for ye= ars now and has been adopted by a number of different external groups and e= fforts:


I=E2=80=99ve spoken with = the authors of the draft and we=E2=80=99d like to find out how to bring thi= s forward to publication within the IETF. I=E2=80=99m targeting both dispat= ch groups because this represents the intersection of both areas, and I thi= nk we=E2=80=99d get different perspectives from each side that we should co= nsider.=C2=A0

There have been a number of other dr= afts that have approached HTTP request signing as well (I=E2=80=99ve writte= n two of them myself), but none has caught on to date and none have made it= to RFC. Lately, though, I=E2=80=99ve been seeing a lot of renewed effort i= n different sectors, and in particular the financial sector and cloud servi= ces, to have a general purpose HTTP message signing capability. As such, I = think it=E2=80=99s time to push something forward.=C2=A0

I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDISP= ATCH to request a presentation slot.

Thank you, an= d I=E2=80=99ll see you all in Singapore!
=C2=A0=E2=80=94 Justin
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000067733c05968acd53-- From nobody Tue Nov 5 08:56:13 2019 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 D4FA612022C; Tue, 5 Nov 2019 08:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 uG3uoUyHgHhu; Tue, 5 Nov 2019 08:55:57 -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 93E5E120142; Tue, 5 Nov 2019 08:55:57 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA5GtsPB030527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Nov 2019 11:55:55 -0500 From: Justin Richer Message-Id: <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_963E0474-49E8-4133-8051-6DF13C7B688D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 Nov 2019 11:55:54 -0500 In-Reply-To: Cc: DISPATCH , secdispatch@ietf.org To: Mary Barnes References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 05 Nov 2019 16:56:03 -0000 --Apple-Mail=_963E0474-49E8-4133-8051-6DF13C7B688D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A number of the people involved with implementing the drafts that I=E2=80=99= d like to present are involved in IETF in different places, but none for = pushing this draft to date. If this work finds a home, I think we=E2=80=99= d be able to get a lot of that external community to participate in = whatever list ends up hosting the work.=20 I=E2=80=99m fine with presenting at only one of DISPATCH or SECDISPATCH = instead of both, but since this sits squarely at the intersection of the = two communities it might make sense for me to just introduce the concept = (~1 min) at whatever meeting I=E2=80=99m not giving a full presentation = at.=20 =E2=80=94 Justin > On Nov 4, 2019, at 3:02 PM, Mary Barnes = wrote: >=20 > Personally, I'd rather not have the presentation twice, recognizing of = course, that not everyone would be able to attend one or the other. But, = we will have recordings and as is oft stated, ultimately decisions = happen on mailing lists. And, I appreciate and agree with Jeffrey not = wanting feature creep in WPACK. One objective of DISPATCH has been to = ensure that work that is chartered is discrete enough to finish in a = timely manner. =20 >=20 > You mention other communities that are interested in this. Will they = be participating or have they participated in IETF? It's hard for = chairs to judge consensus to work on something when the communities = interested in the work are not participating in IETF. Mailing list = participation is sufficient. =20 >=20 > DISPATCH agenda is pretty full right now, so this would have to fall = into AOB at this juncture if ADs and my WG co-chair agree that we should = discuss in DISPATCH. And, perhaps whether it gets a few minutes in = SECdispatch might be informed on how it goes in DISPATCH, if we have a = chance to discuss it, since you need the agreement that this is a = problem IETF should solve from both areas. >=20 > Regards, > Mary > DISPATCH WG co-chair >=20 >=20 > On Fri, Nov 1, 2019 at 5:00 PM Justin Richer > wrote: > I would like to present and discuss HTTP Request signing at both the = DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of = different external groups and efforts: >=20 > https://tools.ietf.org/html/draft-cavage-http-signatures = >=20 > I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d = like to find out how to bring this forward to publication within the = IETF. I=E2=80=99m targeting both dispatch groups because this represents = the intersection of both areas, and I think we=E2=80=99d get different = perspectives from each side that we should consider.=20 >=20 > There have been a number of other drafts that have approached HTTP = request signing as well (I=E2=80=99ve written two of them myself), but = none has caught on to date and none have made it to RFC. Lately, though, = I=E2=80=99ve been seeing a lot of renewed effort in different sectors, = and in particular the financial sector and cloud services, to have a = general purpose HTTP message signing capability. As such, I think it=E2=80= =99s time to push something forward.=20 >=20 > I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot. >=20 > Thank you, and I=E2=80=99ll see you all in Singapore! > =E2=80=94 Justin > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_963E0474-49E8-4133-8051-6DF13C7B688D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = number of the people involved with implementing the drafts that I=E2=80=99= d like to present are involved in IETF in different places, but none for = pushing this draft to date. If this work finds a home, I think we=E2=80=99= d be able to get a lot of that external community to participate in = whatever list ends up hosting the work. 

I=E2=80=99m fine with presenting at = only one of DISPATCH or SECDISPATCH instead of both, but since this sits = squarely at the intersection of the two communities it might make sense = for me to just introduce the concept (~1 min) at whatever meeting I=E2=80=99= m not giving a full presentation at. 

 =E2=80=94 Justin


On = Nov 4, 2019, at 3:02 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Personally, I'd rather not have = the presentation twice, recognizing of course, that not everyone would = be able to attend one or the other. But, we will have recordings and as = is oft stated, ultimately decisions happen on mailing lists.  And, = I appreciate and agree with Jeffrey not wanting feature creep in = WPACK.  One objective of DISPATCH has been to ensure that work that = is chartered is discrete enough to finish in a timely manner.  =  

You mention = other communities that are interested in this.  Will they be = participating or have they participated in IETF?    It's hard = for chairs to judge consensus to work on something when the communities = interested in the work are not participating in IETF.  Mailing list = participation is sufficient.  

DISPATCH agenda is pretty full right = now, so this would have to fall into AOB at this juncture if ADs and my = WG co-chair agree that we should discuss in DISPATCH.  And, perhaps = whether it gets a few minutes in SECdispatch might be informed on how it = goes in DISPATCH, if we have a chance to discuss it, since you need the = agreement that this is a problem IETF should solve from both = areas.

Regards,
Mary
DISPATCH WG co-chair


On Fri, Nov = 1, 2019 at 5:00 PM Justin Richer <jricher@mit.edu> wrote:
I would like to = present and discuss HTTP Request signing at both the DISPATCH and = SECDISPATCH meetings at IETF106 in Singapore. This I-D has been floating = around for years now and has been adopted by a number of different = external groups and efforts:

https://tools.ietf.org/html/draft-cavage-http-signatures

I=E2=80=99ve = spoken with the authors of the draft and we=E2=80=99d like to find out = how to bring this forward to publication within the IETF. I=E2=80=99m = targeting both dispatch groups because this represents the intersection = of both areas, and I think we=E2=80=99d get different perspectives from = each side that we should consider. 

There have been a number of other = drafts that have approached HTTP request signing as well (I=E2=80=99ve = written two of them myself), but none has caught on to date and none = have made it to RFC. Lately, though, I=E2=80=99ve been seeing a lot of = renewed effort in different sectors, and in particular the financial = sector and cloud services, to have a general purpose HTTP message = signing capability. As such, I think it=E2=80=99s time to push something = forward. 

I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot.

Thank you, and I=E2=80=99ll see you all = in Singapore!
 =E2=80=94 = Justin
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_963E0474-49E8-4133-8051-6DF13C7B688D-- From nobody Tue Nov 5 08:59:58 2019 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 872B11200C3; Tue, 5 Nov 2019 08:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dUu0j4b7uZdi; Tue, 5 Nov 2019 08:59:53 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 6576E12001A; Tue, 5 Nov 2019 08:59:53 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id d5so6193051otp.4; Tue, 05 Nov 2019 08:59:53 -0800 (PST) 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=q/lyxPHHDnq0KjQHvOabgH4P24NT8XbqTXbIexihDkg=; b=OJr4qiz3Km6UtY2h9rMi9nv4J603ANkdZOt2AUYWEHo4evc5QKDnmizMN+PE6yQzzx lLxjxB7LQQQfWQ6hse0tyhxNtQPdkIyVLd6XS1g93xJgbcN6/uN+bbofqYN6aDpzjv8a Y54sAsad9p9cIGwXrtJnFJolD+gryTUK1FVfkhjXSCUhXA4z9EhoXHSFgOzX3FtHVPXa A/EAfJEdzraUbXM0vdt5SMajUKU5TMfXzU4gJoglY6Zj97N+azmeTCrZYeNCyf1Cbp++ 92c+p/bI19aqh+VS1oHEmwAJhZAjse1dffgvYe0Pk9iilQrwVP3MJXm9tkY0OYuf5YAW zrnQ== 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=q/lyxPHHDnq0KjQHvOabgH4P24NT8XbqTXbIexihDkg=; b=qYvFcD6UqrVHftPe05wHcPTGGeoB5pe+O1HB/GhS4/61+DZ4VKtFp8fKzkZ0tPQs9O r553nOjl+7kcyo+wWBWcFMILhlRFOaWW5DYp24IJr5p4EnBQcQKiU7kz+ne4KStiaIUt NqQDsFaZP4rfEZafrX7yucH51Qr+cISRCYgHtiy7vQtwTEJH0D+SLPyetjPFeAsuOEli s4FKiKix/lH9C8uXwkwLNnVeg8UOB9g3JXJ3dQ7mXC1VDBVSYVrIvg+CBgz9huHHqstq BJrtGxs3YQRNrQi6V+yulYSpLW1YwbGS+o4iW6rk8qxsS0WAuD2JeMcFOZh7wvVuLUUG ON+g== X-Gm-Message-State: APjAAAX2sl6x3p2sSXSdJfG7bDhpDonqfZiJB1KDAm/qGpGeQYrc9U8j dD/m8s59zW0fLn+2xhRTF14Qr1DEERoOgD2Gh44= X-Google-Smtp-Source: APXvYqzvSU19SHxlufPL5lFK8qIRAVJra3Aj32YrfeSDMTdWlIpjf3vdsImZE/opeYRe97L9LyeGAnRIZifHOBMkxGA= X-Received: by 2002:a05:6830:210e:: with SMTP id i14mr9209640otc.250.1572973192436; Tue, 05 Nov 2019 08:59:52 -0800 (PST) MIME-Version: 1.0 References: <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> In-Reply-To: <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> From: Kathleen Moriarty Date: Tue, 5 Nov 2019 11:59:15 -0500 Message-ID: To: Justin Richer Cc: Mary Barnes , DISPATCH , IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000060612b05969c5c13" Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 05 Nov 2019 16:59:57 -0000 --00000000000060612b05969c5c13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have the time at SecDispatch, so should I just add it considering DISPATCH has a full agenda? Best regards, Kathleen On Tue, Nov 5, 2019 at 11:56 AM Justin Richer wrote: > A number of the people involved with implementing the drafts that I=E2=80= =99d like > to present are involved in IETF in different places, but none for pushing > this draft to date. If this work finds a home, I think we=E2=80=99d be ab= le to get > a lot of that external community to participate in whatever list ends up > hosting the work. > > I=E2=80=99m fine with presenting at only one of DISPATCH or SECDISPATCH i= nstead of > both, but since this sits squarely at the intersection of the two > communities it might make sense for me to just introduce the concept (~1 > min) at whatever meeting I=E2=80=99m not giving a full presentation at. > > =E2=80=94 Justin > > > On Nov 4, 2019, at 3:02 PM, Mary Barnes > wrote: > > Personally, I'd rather not have the presentation twice, recognizing of > course, that not everyone would be able to attend one or the other. But, = we > will have recordings and as is oft stated, ultimately decisions happen on > mailing lists. And, I appreciate and agree with Jeffrey not wanting > feature creep in WPACK. One objective of DISPATCH has been to ensure tha= t > work that is chartered is discrete enough to finish in a timely manner. > > You mention other communities that are interested in this. Will they be > participating or have they participated in IETF? It's hard for chairs = to > judge consensus to work on something when the communities interested in t= he > work are not participating in IETF. Mailing list participation is > sufficient. > > DISPATCH agenda is pretty full right now, so this would have to fall into > AOB at this juncture if ADs and my WG co-chair agree that we should discu= ss > in DISPATCH. And, perhaps whether it gets a few minutes in SECdispatch > might be informed on how it goes in DISPATCH, if we have a chance to > discuss it, since you need the agreement that this is a problem IETF shou= ld > solve from both areas. > > Regards, > Mary > DISPATCH WG co-chair > > > On Fri, Nov 1, 2019 at 5:00 PM Justin Richer wrote: > >> I would like to present and discuss HTTP Request signing at both the >> DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has >> been floating around for years now and has been adopted by a number of >> different external groups and efforts: >> >> https://tools.ietf.org/html/draft-cavage-http-signatures >> >> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d like = to find out how >> to bring this forward to publication within the IETF. I=E2=80=99m target= ing both >> dispatch groups because this represents the intersection of both areas, = and >> I think we=E2=80=99d get different perspectives from each side that we s= hould >> consider. >> >> There have been a number of other drafts that have approached HTTP >> request signing as well (I=E2=80=99ve written two of them myself), but n= one has >> caught on to date and none have made it to RFC. Lately, though, I=E2=80= =99ve been >> seeing a lot of renewed effort in different sectors, and in particular t= he >> financial sector and cloud services, to have a general purpose HTTP mess= age >> signing capability. As such, I think it=E2=80=99s time to push something= forward. >> >> I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDISPATCH= to >> request a presentation slot. >> >> Thank you, and I=E2=80=99ll see you all in Singapore! >> =E2=80=94 Justin >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --=20 Best regards, Kathleen --00000000000060612b05969c5c13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have the time at SecDispatch, so should I just add it c= onsidering=C2=A0DISPATCH has a full agenda?

Best regards= ,
Kathleen

On Tue, Nov 5, 2019 at 11:56 AM Justin Richer <= ;jricher@mit.edu> wrote:
A number of the people involved with implementing the dra= fts that I=E2=80=99d like to present are involved in IETF in different plac= es, but none for pushing this draft to date. If this work finds a home, I t= hink we=E2=80=99d be able to get a lot of that external community to partic= ipate in whatever list ends up hosting the work.=C2=A0

I= =E2=80=99m fine with presenting at only one of DISPATCH or SECDISPATCH inst= ead of both, but since this sits squarely at the intersection of the two co= mmunities it might make sense for me to just introduce the concept (~1 min)= at whatever meeting I=E2=80=99m not giving a full presentation at.=C2=A0

=C2=A0=E2=80=94 Justin


<= div>
On Nov 4, 2019, at 3:02 PM, Mary Barnes = <mary.ie= tf.barnes@gmail.com> wrote:

Personall= y, I'd rather not have the presentation twice, recognizing of course, t= hat not everyone would be able to attend one or the other. But, we will hav= e recordings and as is oft stated, ultimately decisions happen on mailing l= ists.=C2=A0 And, I appreciate and agree with Jeffrey not wanting feature cr= eep in WPACK.=C2=A0 One objective of DISPATCH has been to ensure that work = that is chartered is discrete enough to finish in a timely manner.=C2=A0 = =C2=A0

You mention other communities that are interested= in this.=C2=A0 Will they be participating or have they participated in IET= F?=C2=A0 =C2=A0 It's hard for chairs to judge consensus to work on some= thing when the communities interested in the work are not participating in = IETF.=C2=A0 Mailing list participation is sufficient.=C2=A0=C2=A0

<= /div>
DISPATCH agenda is pretty full right now, so this would have to f= all into AOB at this juncture if ADs and my WG co-chair agree that we shoul= d discuss in DISPATCH.=C2=A0 And, perhaps whether it gets a few minutes in = SECdispatch might be informed on how it goes in DISPATCH, if we have a chan= ce to discuss it, since you need the agreement that this is a problem IETF = should solve from both areas.

Regards,
M= ary
DISPATCH WG co-chair


On Fri, Nov 1,= 2019 at 5:00 PM Justin Richer <jricher@mit.edu> wrote:
I would like to present and discuss HTTP R= equest signing at both the DISPATCH and SECDISPATCH meetings at IETF106 in = Singapore. This I-D has been floating around for years now and has been ado= pted by a number of different external groups and efforts:

https://tools.ietf.org/html/draft-cavage-http-signatures=

I=E2=80=99ve spoken with the authors of the draft= and we=E2=80=99d like to find out how to bring this forward to publication= within the IETF. I=E2=80=99m targeting both dispatch groups because this r= epresents the intersection of both areas, and I think we=E2=80=99d get diff= erent perspectives from each side that we should consider.=C2=A0
=
There have been a number of other drafts that have approache= d HTTP request signing as well (I=E2=80=99ve written two of them myself), b= ut none has caught on to date and none have made it to RFC. Lately, though,= I=E2=80=99ve been seeing a lot of renewed effort in different sectors, and= in particular the financial sector and cloud services, to have a general p= urpose HTTP message signing capability. As such, I think it=E2=80=99s time = to push something forward.=C2=A0

I=E2=80=99ve reac= hed out to the chairs for both DISPATCH and SECDISPATCH to request a presen= tation slot.

Thank you, and I=E2=80=99ll see you a= ll in Singapore!
=C2=A0=E2=80=94 Justin
______________= _________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

____________________________= ___________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch


--

Best regards,
Kathleen
--00000000000060612b05969c5c13-- From nobody Tue Nov 5 09:06:54 2019 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 66D761200D8; Tue, 5 Nov 2019 09:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 B4GjyHZtrqmu; Tue, 5 Nov 2019 09:06:46 -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 A9C001200C4; Tue, 5 Nov 2019 09:06:45 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA5H6gHA002214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Nov 2019 12:06:42 -0500 From: Justin Richer Message-Id: <711F14DE-A33D-4A49-870C-2627766C6EDF@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_A276ADCA-0B49-4C30-B1E9-A2F922480EFF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 Nov 2019 12:06:41 -0500 In-Reply-To: Cc: Mary Barnes , DISPATCH , IETF SecDispatch To: Kathleen Moriarty References: <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 05 Nov 2019 17:06:48 -0000 --Apple-Mail=_A276ADCA-0B49-4C30-B1E9-A2F922480EFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That sounds great to me, I will plan to present at SECDISPATCH. If the = chairs of DISPATCH would be willing to give me a quick moment to just = point people to this other work during the meeting, in case they = aren=E2=80=99t paying attention to this list. Considering that DISPATCH = is first it=E2=80=99d mostly be pointing people to the SECDISPATCH = meeting for the discussion if they=E2=80=99re interested. =E2=80=94 Justin > On Nov 5, 2019, at 11:59 AM, Kathleen Moriarty = wrote: >=20 > We have the time at SecDispatch, so should I just add it considering = DISPATCH has a full agenda? >=20 > Best regards, > Kathleen >=20 > On Tue, Nov 5, 2019 at 11:56 AM Justin Richer > wrote: > A number of the people involved with implementing the drafts that = I=E2=80=99d like to present are involved in IETF in different places, = but none for pushing this draft to date. If this work finds a home, I = think we=E2=80=99d be able to get a lot of that external community to = participate in whatever list ends up hosting the work.=20 >=20 > I=E2=80=99m fine with presenting at only one of DISPATCH or = SECDISPATCH instead of both, but since this sits squarely at the = intersection of the two communities it might make sense for me to just = introduce the concept (~1 min) at whatever meeting I=E2=80=99m not = giving a full presentation at.=20 >=20 > =E2=80=94 Justin >=20 >=20 >> On Nov 4, 2019, at 3:02 PM, Mary Barnes > wrote: >>=20 >> Personally, I'd rather not have the presentation twice, recognizing = of course, that not everyone would be able to attend one or the other. = But, we will have recordings and as is oft stated, ultimately decisions = happen on mailing lists. And, I appreciate and agree with Jeffrey not = wanting feature creep in WPACK. One objective of DISPATCH has been to = ensure that work that is chartered is discrete enough to finish in a = timely manner. =20 >>=20 >> You mention other communities that are interested in this. Will they = be participating or have they participated in IETF? It's hard for = chairs to judge consensus to work on something when the communities = interested in the work are not participating in IETF. Mailing list = participation is sufficient. =20 >>=20 >> DISPATCH agenda is pretty full right now, so this would have to fall = into AOB at this juncture if ADs and my WG co-chair agree that we should = discuss in DISPATCH. And, perhaps whether it gets a few minutes in = SECdispatch might be informed on how it goes in DISPATCH, if we have a = chance to discuss it, since you need the agreement that this is a = problem IETF should solve from both areas. >>=20 >> Regards, >> Mary >> DISPATCH WG co-chair >>=20 >>=20 >> On Fri, Nov 1, 2019 at 5:00 PM Justin Richer > wrote: >> I would like to present and discuss HTTP Request signing at both the = DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of = different external groups and efforts: >>=20 >> https://tools.ietf.org/html/draft-cavage-http-signatures = >>=20 >> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d = like to find out how to bring this forward to publication within the = IETF. I=E2=80=99m targeting both dispatch groups because this represents = the intersection of both areas, and I think we=E2=80=99d get different = perspectives from each side that we should consider.=20 >>=20 >> There have been a number of other drafts that have approached HTTP = request signing as well (I=E2=80=99ve written two of them myself), but = none has caught on to date and none have made it to RFC. Lately, though, = I=E2=80=99ve been seeing a lot of renewed effort in different sectors, = and in particular the financial sector and cloud services, to have a = general purpose HTTP message signing capability. As such, I think it=E2=80= =99s time to push something forward.=20 >>=20 >> I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot. >>=20 >> Thank you, and I=E2=80=99ll see you all in Singapore! >> =E2=80=94 Justin >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch = >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_A276ADCA-0B49-4C30-B1E9-A2F922480EFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That = sounds great to me, I will plan to present at SECDISPATCH. If the chairs = of DISPATCH would be willing to give me a quick moment to just point = people to this other work during the meeting, in case they aren=E2=80=99t = paying attention to this list. Considering that DISPATCH is first it=E2=80= =99d mostly be pointing people to the SECDISPATCH meeting for the = discussion if they=E2=80=99re interested.

 =E2=80=94 Justin

On Nov 5, 2019, at 11:59 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

We have the time at SecDispatch, = so should I just add it considering DISPATCH has a full agenda?

Best regards,
Kathleen

On Tue, Nov = 5, 2019 at 11:56 AM Justin Richer <jricher@mit.edu> wrote:
A number of the people involved with = implementing the drafts that I=E2=80=99d like to present are involved in = IETF in different places, but none for pushing this draft to date. If = this work finds a home, I think we=E2=80=99d be able to get a lot of = that external community to participate in whatever list ends up hosting = the work. 

I=E2=80= =99m fine with presenting at only one of DISPATCH or SECDISPATCH instead = of both, but since this sits squarely at the intersection of the two = communities it might make sense for me to just introduce the concept (~1 = min) at whatever meeting I=E2=80=99m not giving a full presentation = at. 

 =E2=80=94 Justin


On Nov = 4, 2019, at 3:02 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Personally, I'd = rather not have the presentation twice, recognizing of course, that not = everyone would be able to attend one or the other. But, we will have = recordings and as is oft stated, ultimately decisions happen on mailing = lists.  And, I appreciate and agree with Jeffrey not wanting = feature creep in WPACK.  One objective of DISPATCH has been to = ensure that work that is chartered is discrete enough to finish in a = timely manner.   

You mention other communities that are interested in = this.  Will they be participating or have they participated in = IETF?    It's hard for chairs to judge consensus to work on = something when the communities interested in the work are not = participating in IETF.  Mailing list participation is = sufficient.  

DISPATCH agenda is pretty full right now, so this would have = to fall into AOB at this juncture if ADs and my WG co-chair agree that = we should discuss in DISPATCH.  And, perhaps whether it gets a few = minutes in SECdispatch might be informed on how it goes in DISPATCH, if = we have a chance to discuss it, since you need the agreement that this = is a problem IETF should solve from both areas.

Regards,
Mary
DISPATCH WG co-chair


On Fri, Nov = 1, 2019 at 5:00 PM Justin Richer <jricher@mit.edu> wrote:
I would like to = present and discuss HTTP Request signing at both the DISPATCH and = SECDISPATCH meetings at IETF106 in Singapore. This I-D has been floating = around for years now and has been adopted by a number of different = external groups and efforts:

https://tools.ietf.org/html/draft-cavage-http-signatures

I=E2=80=99ve = spoken with the authors of the draft and we=E2=80=99d like to find out = how to bring this forward to publication within the IETF. I=E2=80=99m = targeting both dispatch groups because this represents the intersection = of both areas, and I think we=E2=80=99d get different perspectives from = each side that we should consider. 

There have been a number of other = drafts that have approached HTTP request signing as well (I=E2=80=99ve = written two of them myself), but none has caught on to date and none = have made it to RFC. Lately, though, I=E2=80=99ve been seeing a lot of = renewed effort in different sectors, and in particular the financial = sector and cloud services, to have a general purpose HTTP message = signing capability. As such, I think it=E2=80=99s time to push something = forward. 

I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot.

Thank you, and I=E2=80=99ll see you all = in Singapore!
 =E2=80=94 = Justin
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_____________________________________________= __
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch


--

Best regards,
Kathleen

= --Apple-Mail=_A276ADCA-0B49-4C30-B1E9-A2F922480EFF-- From nobody Tue Nov 5 11:43:18 2019 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 EDC48120AE9; Tue, 5 Nov 2019 11:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 afmNvmOUVrUg; Tue, 5 Nov 2019 11:43:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5E916120AB5; Tue, 5 Nov 2019 11:43:10 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xA5Jh5bI088661 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 5 Nov 2019 13:43:07 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1572982988; bh=68db0cZo867PbSAwMiTTcmRl4TekzR2+H/3ilrUY/Hk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GZRWVfr0RrNPqAtEBN6COySzEyo2h8BHYYoygS1yG+nqdu6BwYZIp4V62G8n4o+yG Uxp1GMGRBQTI5P1DLdmrkCPJ7Ex2cTWjzrQDQ7BeKDG7NIdBoj1M56Dl+ulmB/OoGU vz4rRArwHMUjriDeGCH51fGmH+2m5nqWR/PSRL+o= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Kathleen Moriarty , Justin Richer Cc: DISPATCH , IETF SecDispatch References: <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> From: Adam Roach Message-ID: Date: Tue, 5 Nov 2019 13:43:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7048C49F4FD1DE109B9F8519" Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 05 Nov 2019 19:43:12 -0000 This is a multi-part message in MIME format. --------------7048C49F4FD1DE109B9F8519 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Given that DISPATCH meets in the first Monday morning slot, I think this plan makes the most sense. Justin (or the DISPATCH chairs) can give a very short description of the purpose of the proposed mechanism, and let interested parties know that the discussion will take place in SECDISPATCH. /a On 11/5/19 10:59 AM, Kathleen Moriarty wrote: > We have the time at SecDispatch, so should I just add it > considering DISPATCH has a full agenda? > > Best regards, > Kathleen > > On Tue, Nov 5, 2019 at 11:56 AM Justin Richer > wrote: > > A number of the people involved with implementing the drafts that > I’d like to present are involved in IETF in different places, but > none for pushing this draft to date. If this work finds a home, I > think we’d be able to get a lot of that external community to > participate in whatever list ends up hosting the work. > > I’m fine with presenting at only one of DISPATCH or SECDISPATCH > instead of both, but since this sits squarely at the intersection > of the two communities it might make sense for me to just > introduce the concept (~1 min) at whatever meeting I’m not giving > a full presentation at. > >  — Justin > > >> On Nov 4, 2019, at 3:02 PM, Mary Barnes >> > >> wrote: >> >> Personally, I'd rather not have the presentation twice, >> recognizing of course, that not everyone would be able to attend >> one or the other. But, we will have recordings and as is oft >> stated, ultimately decisions happen on mailing lists.  And, I >> appreciate and agree with Jeffrey not wanting feature creep in >> WPACK.  One objective of DISPATCH has been to ensure that work >> that is chartered is discrete enough to finish in a timely manner. >> >> You mention other communities that are interested in this.  Will >> they be participating or have they participated in IETF?    It's >> hard for chairs to judge consensus to work on something when the >> communities interested in the work are not participating in >> IETF.  Mailing list participation is sufficient. >> >> DISPATCH agenda is pretty full right now, so this would have to >> fall into AOB at this juncture if ADs and my WG co-chair agree >> that we should discuss in DISPATCH.  And, perhaps whether it gets >> a few minutes in SECdispatch might be informed on how it goes in >> DISPATCH, if we have a chance to discuss it, since you need the >> agreement that this is a problem IETF should solve from both areas. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> >> >> On Fri, Nov 1, 2019 at 5:00 PM Justin Richer > > wrote: >> >> I would like to present and discuss HTTP Request signing at >> both the DISPATCH and SECDISPATCH meetings at IETF106 in >> Singapore. This I-D has been floating around for years now >> and has been adopted by a number of different external groups >> and efforts: >> >> https://tools.ietf.org/html/draft-cavage-http-signatures >> >> I’ve spoken with the authors of the draft and we’d like to >> find out how to bring this forward to publication within the >> IETF. I’m targeting both dispatch groups because this >> represents the intersection of both areas, and I think we’d >> get different perspectives from each side that we should >> consider. >> >> There have been a number of other drafts that have approached >> HTTP request signing as well (I’ve written two of them >> myself), but none has caught on to date and none have made it >> to RFC. Lately, though, I’ve been seeing a lot of renewed >> effort in different sectors, and in particular the financial >> sector and cloud services, to have a general purpose HTTP >> message signing capability. As such, I think it’s time to >> push something forward. >> >> I’ve reached out to the chairs for both DISPATCH and >> SECDISPATCH to request a presentation slot. >> >> Thank you, and I’ll see you all in Singapore! >>  — Justin >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------7048C49F4FD1DE109B9F8519 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Given that DISPATCH meets in the first Monday morning slot, I think this plan makes the most sense. Justin (or the DISPATCH chairs) can give a very short description of the purpose of the proposed mechanism, and let interested parties know that the discussion will take place in SECDISPATCH.

/a

On 11/5/19 10:59 AM, Kathleen Moriarty wrote:
We have the time at SecDispatch, so should I just add it considering DISPATCH has a full agenda?

Best regards,
Kathleen

On Tue, Nov 5, 2019 at 11:56 AM Justin Richer <jricher@mit.edu> wrote:
A number of the people involved with implementing the drafts that I’d like to present are involved in IETF in different places, but none for pushing this draft to date. If this work finds a home, I think we’d be able to get a lot of that external community to participate in whatever list ends up hosting the work. 

I’m fine with presenting at only one of DISPATCH or SECDISPATCH instead of both, but since this sits squarely at the intersection of the two communities it might make sense for me to just introduce the concept (~1 min) at whatever meeting I’m not giving a full presentation at. 

 — Justin


On Nov 4, 2019, at 3:02 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Personally, I'd rather not have the presentation twice, recognizing of course, that not everyone would be able to attend one or the other. But, we will have recordings and as is oft stated, ultimately decisions happen on mailing lists.  And, I appreciate and agree with Jeffrey not wanting feature creep in WPACK.  One objective of DISPATCH has been to ensure that work that is chartered is discrete enough to finish in a timely manner.   

You mention other communities that are interested in this.  Will they be participating or have they participated in IETF?    It's hard for chairs to judge consensus to work on something when the communities interested in the work are not participating in IETF.  Mailing list participation is sufficient.  

DISPATCH agenda is pretty full right now, so this would have to fall into AOB at this juncture if ADs and my WG co-chair agree that we should discuss in DISPATCH.  And, perhaps whether it gets a few minutes in SECdispatch might be informed on how it goes in DISPATCH, if we have a chance to discuss it, since you need the agreement that this is a problem IETF should solve from both areas.

Regards,
Mary
DISPATCH WG co-chair


On Fri, Nov 1, 2019 at 5:00 PM Justin Richer <jricher@mit.edu> wrote:
I would like to present and discuss HTTP Request signing at both the DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has been floating around for years now and has been adopted by a number of different external groups and efforts:


I’ve spoken with the authors of the draft and we’d like to find out how to bring this forward to publication within the IETF. I’m targeting both dispatch groups because this represents the intersection of both areas, and I think we’d get different perspectives from each side that we should consider. 

There have been a number of other drafts that have approached HTTP request signing as well (I’ve written two of them myself), but none has caught on to date and none have made it to RFC. Lately, though, I’ve been seeing a lot of renewed effort in different sectors, and in particular the financial sector and cloud services, to have a general purpose HTTP message signing capability. As such, I think it’s time to push something forward. 

I’ve reached out to the chairs for both DISPATCH and SECDISPATCH to request a presentation slot.

Thank you, and I’ll see you all in Singapore!
 — Justin
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch


--

Best regards,
Kathleen

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--------------7048C49F4FD1DE109B9F8519-- From nobody Tue Nov 5 11:46:36 2019 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 A85561208AB; Tue, 5 Nov 2019 11:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zSKAKrZRZeve; Tue, 5 Nov 2019 11:46:32 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 F24371200F4; Tue, 5 Nov 2019 11:46:31 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id t4so7232100otr.1; Tue, 05 Nov 2019 11:46:31 -0800 (PST) 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=bgHWsI7fNrkOKyVIIFWWy2YB3IB/ZL3vpDSSARiGuoU=; b=H/+Q24SIA8JSSckojV32ZshrRSjshtJ6thGaJG/ddV0pURKOKAVgTMKsLINuRrm3gE 1PL9AeVfSD6fF4gpr1aKA4rk8n/DZoTC1J18lEAzGnvq0w2R56zBpi2nhoNmpzS0ghxA S1fVM5hmLHlWZUzIy9LUv58oVmb0YQ/wN9HtsJQxX0uozfxzADt3OZ4n6I8c6bv+YdNY ym8B7x8FbTfvkWN3GtNJPH1vSf+sgcrupv5NXsLg7eJGcN/mHXggD1ID1kPlhZegf9vQ nuoYWDcOzChtSycZu0vYw/hG5b3K0KfT4HwLMK8V2bdRHSySIp55g45viWc28nh2clMF xTPQ== 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=bgHWsI7fNrkOKyVIIFWWy2YB3IB/ZL3vpDSSARiGuoU=; b=YI14aVz5z8VG7rlQXxQlVwasdEKi2NYQGnn2iziTMwER+LFOGBZyDSlpg5A3y8PYRG oCfrQd4Z63lxMU+N0uh4yRhUqhMPTcq5mnEL954LOPa6eOJ51BGDITZyPBrK85fazEW4 ZxNGBUTSaPrEXC9BV2VPbhGyF3t9KAtMf7Kbe0ZczDC3wUDuzxpKRon+FOo614bRZGB7 w31T/evh59BlRaXLXvCnTIlhEGVSO+1JNMt7axshCKMJj0/EToraesm57ZWYVkTteamI bKZ0AjgQkLc5yzbu8mUH0mSKASoSv8i7RLCyw6S4dtrpokm0rnpgh0L7mMe2tRPCEBgq 0QTw== X-Gm-Message-State: APjAAAXdbwQAMV2Mf5qdsL8FfhdIx+sx9Qm1XojZAPbfsgVkQVaj5jbS PiNTX6+ZLLujr510mnc9oLFaBjullo+IXJHX/F8= X-Google-Smtp-Source: APXvYqwDP23Tn2Zdpdo1r+gEbIh2L0asG4vWabF75sz7xvtw8FH7Bkhzc5vnTOV6y9uJXV6vGLH/DDeaxTlcQv3UC0E= X-Received: by 2002:a9d:6a10:: with SMTP id g16mr3924387otn.224.1572983191160; Tue, 05 Nov 2019 11:46:31 -0800 (PST) MIME-Version: 1.0 References: <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> In-Reply-To: From: Kathleen Moriarty Date: Tue, 5 Nov 2019 14:45:54 -0500 Message-ID: To: Adam Roach Cc: Justin Richer , DISPATCH , IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000058cc4a05969eb06e" Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 05 Nov 2019 19:46:35 -0000 --00000000000058cc4a05969eb06e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, it's on the posted agenda. Best regards, Kathleen On Tue, Nov 5, 2019 at 2:43 PM Adam Roach wrote: > Given that DISPATCH meets in the first Monday morning slot, I think this > plan makes the most sense. Justin (or the DISPATCH chairs) can give a ver= y > short description of the purpose of the proposed mechanism, and let > interested parties know that the discussion will take place in SECDISPATC= H. > > /a > > On 11/5/19 10:59 AM, Kathleen Moriarty wrote: > > We have the time at SecDispatch, so should I just add it > considering DISPATCH has a full agenda? > > Best regards, > Kathleen > > On Tue, Nov 5, 2019 at 11:56 AM Justin Richer wrote: > >> A number of the people involved with implementing the drafts that I=E2= =80=99d >> like to present are involved in IETF in different places, but none for >> pushing this draft to date. If this work finds a home, I think we=E2=80= =99d be able >> to get a lot of that external community to participate in whatever list >> ends up hosting the work. >> >> I=E2=80=99m fine with presenting at only one of DISPATCH or SECDISPATCH = instead >> of both, but since this sits squarely at the intersection of the two >> communities it might make sense for me to just introduce the concept (~1 >> min) at whatever meeting I=E2=80=99m not giving a full presentation at. >> >> =E2=80=94 Justin >> >> >> On Nov 4, 2019, at 3:02 PM, Mary Barnes >> wrote: >> >> Personally, I'd rather not have the presentation twice, recognizing of >> course, that not everyone would be able to attend one or the other. But,= we >> will have recordings and as is oft stated, ultimately decisions happen o= n >> mailing lists. And, I appreciate and agree with Jeffrey not wanting >> feature creep in WPACK. One objective of DISPATCH has been to ensure th= at >> work that is chartered is discrete enough to finish in a timely manner. >> >> You mention other communities that are interested in this. Will they be >> participating or have they participated in IETF? It's hard for chairs= to >> judge consensus to work on something when the communities interested in = the >> work are not participating in IETF. Mailing list participation is >> sufficient. >> >> DISPATCH agenda is pretty full right now, so this would have to fall int= o >> AOB at this juncture if ADs and my WG co-chair agree that we should disc= uss >> in DISPATCH. And, perhaps whether it gets a few minutes in SECdispatch >> might be informed on how it goes in DISPATCH, if we have a chance to >> discuss it, since you need the agreement that this is a problem IETF sho= uld >> solve from both areas. >> >> Regards, >> Mary >> DISPATCH WG co-chair >> >> >> On Fri, Nov 1, 2019 at 5:00 PM Justin Richer wrote: >> >>> I would like to present and discuss HTTP Request signing at both the >>> DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has >>> been floating around for years now and has been adopted by a number of >>> different external groups and efforts: >>> >>> https://tools.ietf.org/html/draft-cavage-http-signatures >>> >>> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d like= to find out how >>> to bring this forward to publication within the IETF. I=E2=80=99m targe= ting both >>> dispatch groups because this represents the intersection of both areas,= and >>> I think we=E2=80=99d get different perspectives from each side that we = should >>> consider. >>> >>> There have been a number of other drafts that have approached HTTP >>> request signing as well (I=E2=80=99ve written two of them myself), but = none has >>> caught on to date and none have made it to RFC. Lately, though, I=E2=80= =99ve been >>> seeing a lot of renewed effort in different sectors, and in particular = the >>> financial sector and cloud services, to have a general purpose HTTP mes= sage >>> signing capability. As such, I think it=E2=80=99s time to push somethin= g forward. >>> >>> I=E2=80=99ve reached out to the chairs for both DISPATCH and SECDISPATC= H to >>> request a presentation slot. >>> >>> Thank you, and I=E2=80=99ll see you all in Singapore! >>> =E2=80=94 Justin >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > > > -- > > Best regards, > Kathleen > > _______________________________________________ > dispatch mailing listdispatch@ietf.orghttps://www.ietf.org/mailman/listin= fo/dispatch > > > --=20 Best regards, Kathleen --00000000000058cc4a05969eb06e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, it's on the posted agenda.

Best= regards,
Kathleen

On Tue, Nov 5, 2019 at 2:43 PM Adam Roach= <adam@nostrum.com> wrote:
=20 =20 =20
Given that DISPATCH meets in the first Monday morning slot, I think this plan makes the most sense. Justin (or the DISPATCH chairs) can give a very short description of the purpose of the proposed mechanism, and let interested parties know that the discussion will take place in SECDISPATCH.

/a

On 11/5/19 10:59 AM, Kathleen Moriarty wrote:
=20
We have the time at SecDispatch, so should I just add it considering=C2=A0DISPATCH has a full agenda?

Best regards,
Kathleen

On Tue, Nov 5, 2019 at 11:56 AM Justin Richer <jricher@mit.edu> wrote:
A number of the people involved with implementing the drafts that I=E2=80=99d like to present are involved in IETF in different places, but none for pushing this draft to date. If this work finds a home, I think we=E2=80=99d be able to get a lot of that external commun= ity to participate in whatever list ends up hosting the work.=C2=A0

I=E2=80=99m fine with presenting at only one of DISPATCH o= r SECDISPATCH instead of both, but since this sits squarely at the intersection of the two communities it might make sense for me to just introduce the concept (~1 min) at whatever meeting I=E2=80=99m not giving a full presentation a= t.=C2=A0

=C2=A0=E2=80=94 Justin


On Nov 4, 2019, at 3:02 PM, Mary Barnes <mary.ietf.barnes@= gmail.com> wrote:

Personally, I'd rather not have = the presentation twice, recognizing of course, that not everyone would be able to attend one or the other. But, we will have recordings and as is oft stated, ultimately decisions happen on mailing lists.=C2=A0 And, I appreciate and agree wi= th Jeffrey not wanting feature creep in WPACK.=C2=A0 O= ne objective of DISPATCH has been to ensure that work that is chartered is discrete enough to finish in a timely manner.=C2=A0 =C2=A0

You mention other communities that are interested in this.=C2=A0 Will they be participating or have they participated in IETF?=C2=A0 =C2=A0 It's hard for chairs to ju= dge consensus to work on something when the communities interested in the work are not participating in IETF.=C2=A0 Mailing list participation is sufficient.=C2=A0=C2=A0

DISPATCH agenda is pretty full right now, so this would have to fall into AOB at this juncture if ADs and my WG co-chair agree that we should discuss in DISPATCH.=C2=A0 And, perhaps whether it gets a few minutes in SECdispatch might be informed on how it goes in DISPATCH, if we have a chance to discuss it, since you need the agreement that this is a problem IETF should solve from both areas.

Regards,
Mary
DISPATCH WG co-chair


On Fri, Nov 1= , 2019 at 5:00 PM Justin Richer <jricher@mit.edu> wrote:
I would like to present and discuss HTTP Request signing at both the DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has been floating around for years now and has been adopted by a number of different external groups and efforts:


I=E2=80=99ve spoken with the authors of th= e draft and we=E2=80=99d like to find out how t= o bring this forward to publication within the IETF. I=E2=80=99m targeting both dispatch groups because this represents the intersection of both areas, and I think we=E2=80=99d get different perspectives from = each side that we should consider.=C2=A0

There have been a number of other drafts that have approached HTTP request signing as well (I=E2=80=99ve written two of = them myself), but none has caught on to date and none have made it to RFC. Lately, though, I=E2=80=99ve been seeing a lot of ren= ewed effort in different sectors, and in particular the financial sector and cloud services, to have a general purpose HTTP message signing capability. As such, I think it=E2=80=99s time to push something forward.=C2=A0

I=E2=80=99ve reached out to the chairs for= both DISPATCH and SECDISPATCH to request a presentation slot.

Thank you, and I=E2=80=99ll see you all in Singapore!
=C2=A0=E2=80=94 Justin
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman= /listinfo/dispatch

_______________________________________________
Secdispatch mailing list
Secdisp= atch@ietf.org
https://www.ietf.org/mailman/listinfo/sec= dispatch


--

Best regards,
Kathleen

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch




--

Best regards,
Kathleen
--00000000000058cc4a05969eb06e-- From nobody Wed Nov 6 08:36:16 2019 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 CC1F112011C; Wed, 6 Nov 2019 08:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 4AiKJTsxxUV0; Wed, 6 Nov 2019 08:36:12 -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 416B81200BA; Wed, 6 Nov 2019 08:36:12 -0800 (PST) Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA6Ga6g1007269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Nov 2019 11:36:07 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7893C7F-553D-4262-BFB9-35476B9BB1F3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 6 Nov 2019 11:36:06 -0500 In-Reply-To: Cc: Adam Roach , DISPATCH , IETF SecDispatch To: Kathleen Moriarty References: <279B9C8D-0614-482C-8839-FE10455331B6@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Secdispatch] [dispatch] HTTP Request Signing 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, 06 Nov 2019 16:36:15 -0000 --Apple-Mail=_C7893C7F-553D-4262-BFB9-35476B9BB1F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you, everyone, and I=E2=80=99ll see you in Singapore! =E2=80=94 Justin > On Nov 5, 2019, at 2:45 PM, Kathleen Moriarty = wrote: >=20 > OK, it's on the posted agenda. >=20 > Best regards, > Kathleen >=20 > On Tue, Nov 5, 2019 at 2:43 PM Adam Roach > wrote: > Given that DISPATCH meets in the first Monday morning slot, I think = this plan makes the most sense. Justin (or the DISPATCH chairs) can give = a very short description of the purpose of the proposed mechanism, and = let interested parties know that the discussion will take place in = SECDISPATCH. >=20 > /a >=20 > On 11/5/19 10:59 AM, Kathleen Moriarty wrote: >> We have the time at SecDispatch, so should I just add it considering = DISPATCH has a full agenda? >>=20 >> Best regards, >> Kathleen >>=20 >> On Tue, Nov 5, 2019 at 11:56 AM Justin Richer > wrote: >> A number of the people involved with implementing the drafts that = I=E2=80=99d like to present are involved in IETF in different places, = but none for pushing this draft to date. If this work finds a home, I = think we=E2=80=99d be able to get a lot of that external community to = participate in whatever list ends up hosting the work.=20 >>=20 >> I=E2=80=99m fine with presenting at only one of DISPATCH or = SECDISPATCH instead of both, but since this sits squarely at the = intersection of the two communities it might make sense for me to just = introduce the concept (~1 min) at whatever meeting I=E2=80=99m not = giving a full presentation at.=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Nov 4, 2019, at 3:02 PM, Mary Barnes > wrote: >>>=20 >>> Personally, I'd rather not have the presentation twice, recognizing = of course, that not everyone would be able to attend one or the other. = But, we will have recordings and as is oft stated, ultimately decisions = happen on mailing lists. And, I appreciate and agree with Jeffrey not = wanting feature creep in WPACK. One objective of DISPATCH has been to = ensure that work that is chartered is discrete enough to finish in a = timely manner. =20 >>>=20 >>> You mention other communities that are interested in this. Will = they be participating or have they participated in IETF? It's hard = for chairs to judge consensus to work on something when the communities = interested in the work are not participating in IETF. Mailing list = participation is sufficient. =20 >>>=20 >>> DISPATCH agenda is pretty full right now, so this would have to fall = into AOB at this juncture if ADs and my WG co-chair agree that we should = discuss in DISPATCH. And, perhaps whether = it gets a few minutes in SECdispatch might be informed on how it goes in = DISPATCH, if we have a chance to discuss it, since you need the = agreement that this is a problem IETF should solve from both areas. >>>=20 >>> Regards, >>> Mary >>> DISPATCH WG co-chair >>>=20 >>>=20 >>> On Fri, Nov 1, 2019 at 5:00 PM Justin Richer > wrote: >>> I would like to present and discuss HTTP Request signing at both the = DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has = been floating around for years now and has been adopted by a number of = different external groups and efforts: >>>=20 >>> https://tools.ietf.org/html/draft-cavage-http-signatures = >>>=20 >>> I=E2=80=99ve spoken with the authors of the draft and we=E2=80=99d = like to find out how to bring this forward to publication within the = IETF. I=E2=80=99m targeting both dispatch groups because this represents = the intersection of both areas, and I think we=E2=80=99d get different = perspectives from each side that we should consider.=20 >>>=20 >>> There have been a number of other drafts that have approached HTTP = request signing as well (I=E2=80=99ve written two of them myself), but = none has caught on to date and none have made it to RFC. Lately, though, = I=E2=80=99ve been seeing a lot of renewed effort in different sectors, = and in particular the financial sector and cloud services, to have a = general purpose HTTP message signing capability. As such, I think it=E2=80= =99s time to push something forward.=20 >>>=20 >>> I=E2=80=99ve reached out to the chairs for both DISPATCH and = SECDISPATCH to request a presentation slot. >>>=20 >>> Thank you, and I=E2=80=99ll see you all in Singapore! >>> =E2=80=94 Justin >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch = >>=20 >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch = >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_C7893C7F-553D-4262-BFB9-35476B9BB1F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you, everyone, and I=E2=80=99ll see you in Singapore!

 =E2=80=94 Justin

On Nov 5, 2019, at 2:45 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

OK, it's on the posted = agenda.

Best = regards,
Kathleen

On Tue, Nov = 5, 2019 at 2:43 PM Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
Given that DISPATCH meets in the first Monday morning slot, I think this plan makes the most sense. Justin (or the DISPATCH chairs) can give a very short description of the purpose of the proposed mechanism, and let interested parties know that the discussion will take place in = SECDISPATCH.

/a

On 11/5/19 10:59 AM, Kathleen Moriarty wrote:
=20
We have the time at SecDispatch, so = should I just add it considering DISPATCH has a full agenda?

Best regards,
Kathleen

On Tue, Nov 5, 2019 at = 11:56 AM Justin Richer <jricher@mit.edu> wrote:
=
A number of the people involved with implementing the drafts that I=E2=80=99d like = to present are involved in IETF in different places, but none for pushing this draft to date. If this work finds a home, I think we=E2=80=99d be able to get a lot of that external = community to participate in whatever list ends up hosting the = work. 

I=E2=80=99m fine with presenting at only one = of DISPATCH or SECDISPATCH instead of both, but since this sits squarely at the intersection of the two communities it might make sense for me to just introduce the concept (~1 min) at whatever meeting I=E2=80=99m not giving a full = presentation at. 

 =E2=80=94 Justin


On Nov 4, 2019, at 3:02 PM, Mary = Barnes <mary.ietf.barnes@gmail.com> wrote:

Personally, I'd rather = not have the presentation twice, recognizing of course, that not everyone would be able to attend one or the other. But, we will have recordings and as is oft stated, ultimately decisions happen on mailing lists.  And, I appreciate and agree = with Jeffrey not wanting feature creep in = WPACK.  One objective of DISPATCH has been to ensure that work that is chartered is discrete enough to finish in a timely manner.   

You mention other communities = that are interested in this.  Will they be participating or have they participated in IETF?    It's hard for chairs to = judge consensus to work on something when the communities interested in the work are not participating in IETF.  Mailing list participation is sufficient.  

DISPATCH agenda is pretty full = right now, so this would have to fall into AOB at this juncture if ADs and my WG co-chair agree that we should discuss in DISPATCH.  = And, perhaps whether it gets a few minutes in SECdispatch might be informed on how it goes in DISPATCH, if we have a chance to discuss it, since you need the agreement that this is a problem IETF should solve from both areas.

Regards,
Mary
DISPATCH WG co-chair


On Fri, = Nov 1, 2019 at 5:00 PM Justin Richer <jricher@mit.edu> wrote:
I would like to present and = discuss HTTP Request signing at both the DISPATCH and SECDISPATCH meetings at IETF106 in Singapore. This I-D has been floating around for years now and has been adopted by a number of different external groups and efforts:

https://tools.ietf.org/html/draft-cavage-http-signatures

I=E2=80=99ve spoken with the = authors of the draft and we=E2=80=99d like to find out = how to bring this forward to publication within the IETF. I=E2=80=99m targeting both = dispatch groups because this represents the intersection of both areas, and I think we=E2=80=99d get different perspectives = from each side that we should consider. 

There have been a number of = other drafts that have approached HTTP request signing as well (I=E2=80=99ve written two = of them myself), but none has caught on to date and none have made it to RFC. Lately, though, I=E2=80=99ve been seeing a lot of = renewed effort in different sectors, and in particular the financial sector and cloud services, to have a general purpose HTTP message signing capability. As such, I think it=E2=80=99s time to push something forward. 

I=E2=80=99ve reached out to = the chairs for both DISPATCH and SECDISPATCH to request a presentation slot.

Thank you, and I=E2=80=99ll = see you all in Singapore!
 =E2=80=94 Justin
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch


--

Best regards,
Kathleen

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch




--

Best regards,
Kathleen

= --Apple-Mail=_C7893C7F-553D-4262-BFB9-35476B9BB1F3-- From nobody Wed Nov 13 13:11:26 2019 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 3F8FB120046 for ; Wed, 13 Nov 2019 13:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 hrA8blAZ04Ut for ; Wed, 13 Nov 2019 13:11:22 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 B1A2712003E for ; Wed, 13 Nov 2019 13:11:22 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id d5so2936312otp.4 for ; Wed, 13 Nov 2019 13:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UgmuZAMSNae2w3+lfbt1XrPViwMMQ6U+tzKt2KlSae8=; b=mf7L5MbVIu3ElM/PqbAIAxHjmzX4TsXWuRS+IDvbJ3XDLw6JAk/WfrsaEYo62X3DQN eCGaaHdHiAesh+Z9Z2dP4ayjsFvGpJobqkR7h0d3w/RloJAy/GWopOFGd8UXWSpK5u29 zv0SYjPCcZRuwZvyob7IVKf8s1NFvJvf0EX9BRQKQrQiz0TKJql0/PJmkqDkdAAxqE/w poqMYdVwRU7THqqwRokF0uCdR4WAco2wPMRFkwKFUg5canFM7gYgR755iTpKE3p2r626 sC4VxxwUzHPktXG1hFqg7S0YF8PYGdtvIudR3cirrh7r45vVWkbBQ4pR3O8Hnivy5axa kpMQ== 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=UgmuZAMSNae2w3+lfbt1XrPViwMMQ6U+tzKt2KlSae8=; b=JtQpQ4XumKjD7yOwjSGzcTP5Igze/w7OOvOivOl6704dX2rMaU8LDlrDyV0YrxytQ/ ersw9XnUaijE8TYcvKJtTm8hAWrGrpWWgav6rDVfYwByQRk6QtS/wIWF8rRfrY/3TEz6 6qzkisPDylJVM6hM1hxqfrd9G3jGebHIpiPCaOx8Cto4HwlT1Xw7XwshNjFOr+TcDNcG aYj0IvKUfMLHcF2+wGM+ddK5dP0Lc+DUluIsc7K5movQEnZsyHVKsTcPOy5RizUU2ZNq juRsVyw0e+rvsvjqsV0zbeYs9JxqNbyyTGV9hxCBlP+nOMl07dnijXwKD8Z2KhO0LwRy KuUw== X-Gm-Message-State: APjAAAXUzRVMqkTX/zMmpukdpa28ZxXk3de9HSmdKcxEK0fAK1QtuPkg CPvsAQ8hhn2eRfkgPN0rYrwfyt2M54fn678UwMvLI1hN X-Google-Smtp-Source: APXvYqy4ThFZ0GdrP1E/ElhqV+8vFB7Ex3dqP9vhuO5Y5TVZEksiryW4IHConlDSAwICf8pd9NTh2UWAbdrwbMxloMg= X-Received: by 2002:a05:6830:121a:: with SMTP id r26mr5158088otp.114.1573679481701; Wed, 13 Nov 2019 13:11:21 -0800 (PST) MIME-Version: 1.0 From: Kathleen Moriarty Date: Wed, 13 Nov 2019 16:10:45 -0500 Message-ID: To: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000007f49b9059740ce2e" Archived-At: Subject: [Secdispatch] Presenter Slides 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, 13 Nov 2019 21:11:24 -0000 --0000000000007f49b9059740ce2e Content-Type: text/plain; charset="UTF-8" Hello, If you are planning to present, please send me your slides or a note to let me know that you will not be using slides. I will not be present at the meeting, so I'd like to make sure I have these well in advance in order to avoid any time difference snafus. Thank you! -- Best regards, Kathleen --0000000000007f49b9059740ce2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

If you are planning to present, = please send me your slides or a note to let me know that you will not be us= ing slides.=C2=A0 I will not be present at the meeting, so I'd like to = make sure I have these well in advance in order to avoid any time differenc= e snafus.

Thank you!

--

Best regards,
Kathleen
--0000000000007f49b9059740ce2e-- From nobody Wed Nov 13 19:43:16 2019 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 7F6C41200B1 for ; Wed, 13 Nov 2019 19:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 236IVVhAoj51 for ; Wed, 13 Nov 2019 19:43:12 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 3EE0912006B for ; Wed, 13 Nov 2019 19:43:12 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id 190so2921651vss.8 for ; Wed, 13 Nov 2019 19:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zxq6qsHRDti+Ozb850fji1UujECf1NY5EOH6Ouc6uTQ=; b=U38QhafhSFzfQeKUwRPTyAQe9xEghyi2Byzq5PGiyJg40nUyb2YgPDJCqqAvkOt4mK aaRJP1Yut3yrYxMrlz1l0HGmcQj2HejcV+IUS0gW3Z7XFIb1RJ/cDbjajOSOffMKu6Hi gfrt24Mn53IiThBztIv193xtYqiX2qScyVlkQ= 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=zxq6qsHRDti+Ozb850fji1UujECf1NY5EOH6Ouc6uTQ=; b=i13h96/mS8qd+Ha4S/z7On/Uc3aUJYLpUcEqIlfKlTOTS7uyqF1arwILCJEgyGDCzu Zq6yiKTZ3+Gg+c7iN18IDEbcoJoQZviqaq8+bLOXfBrSmYXhXOofOncaam8pci0Qs97t 4ZBcgvNJe8GqhxdUpNkLEINFCIuLKn5CTVZiY7nQPJyKXwsyFB6JjXlhS2VbwcyQmtyg +bwpqVgMU2l9RvL21tvnJIwxyaCsGCgWXXekYdU5fGsiKHcXSSbH52PEL/YiKZl4U5NS yfHoNAA2xBXMMhJEP31y0UemlaCuLBFRGapEdne/eRewu92Bg/ZXhC+3k5Q15wrs7xVC L9QA== X-Gm-Message-State: APjAAAUP4QcQaPayLhNAaBTr1DU84m/ba2AN9kb05kC6uFUE9Pcioypf GkGaqutqaWDQn6O9EYeXNXgSnXg8BQLv9wxwY+6xug== X-Google-Smtp-Source: APXvYqx4DD/JjmDmgqEXip4tvUwrnZE4JOmeG/Uq1sUUrhFA3AdwE31fZ9z7rDRV0YmnTX1Ur5OV7xgEEWbOOL/zK2I= X-Received: by 2002:a67:5d02:: with SMTP id r2mr4232554vsb.212.1573702990887; Wed, 13 Nov 2019 19:43:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Thu, 14 Nov 2019 11:42:54 +0800 Message-ID: To: Kathleen Moriarty , Richard Barnes Cc: Alex Davidson , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000c136130597464709" Archived-At: Subject: Re: [Secdispatch] secdispatch agenda request: draft-privacy-pass-00 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, 14 Nov 2019 03:43:15 -0000 --000000000000c136130597464709 Content-Type: text/plain; charset="UTF-8" Hello Chairs, I didn't see any time allotted for this discussion on the agenda. Can you please confirm whether we will be able to do our presentation? Best, Nick On Mon, Nov 4, 2019 at 12:09 PM Nick Sullivan wrote: > Kathleen and Richard, > > Alex Davidson and I have a draft we'd like to discuss at Secdispatch. The > draft outlines the Privacy Pass protocol currently in use at Cloudflare ( > https://blog.cloudflare.com/supporting-the-latest-version-of-the-privacy-pass-protocol/ > ). > > Here are the documents: > https://datatracker.ietf.org/doc/draft-privacy-pass/ > https://tools.ietf.org/html/draft-privacy-pass-00 > > This is a substantial piece of work, so it may require its own working > group to tackle. Hopefully, SecDispatch will be able to provide some > guidance around where this work can find a home. > > Nick > > --000000000000c136130597464709 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Chairs,

I didn't see any time= allotted for this discussion on the agenda. Can you please confirm whether= we will be able to do our presentation?

Best,
Nick


On Mon, Nov 4, 2019 at 12:09 PM Nick Sulliv= an <nick@cloudflare.com> w= rote:
Kathleen and Richard,

Alex Davidson = and I have a draft we'd like to discuss at Secdispatch. The draft outli= nes the Privacy Pass protocol currently in use at Cloudflare (https://blog.cloudflare.com/supporting-the-la= test-version-of-the-privacy-pass-protocol/).

H= ere are the documents:
https://datatracker.ietf.org/doc/draft-= privacy-pass/

This is a substantial piece of work,= so it may require=C2=A0its own working group to tackle. Hopefully, SecDisp= atch will be able to provide some guidance around where this work can find = a home.

Nick

--000000000000c136130597464709-- From nobody Thu Nov 14 03:22:51 2019 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 65E4D1200E9 for ; Thu, 14 Nov 2019 03:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 7_zV9OTwiuhp for ; Thu, 14 Nov 2019 03:22:47 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 C625F120046 for ; Thu, 14 Nov 2019 03:22:46 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id m125so4610056qkd.8 for ; Thu, 14 Nov 2019 03:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=xi4MuezFDq51SG2YiOr9pag6YuPFwc0iYukxu945qbs=; b=ng3FRnBV0g01mjvy9i1zU3AydSFre88uVdWjh+gLTpODQ+zknD4mRPmu4rK8XYtqSd vXESBD/Xo0OXtbYp546cLEB+cCoVgfuAjgstaBM/bNvPGgyh613/VhFWPG0AlJ5uIUp4 DeMDrL/n/LzQychMyFVb0Kor2tky5u6SRITyCLOLjj/WGmdoDmhP/tjSb4A/H48OnKmG RXlWzG6DLhC7AJlN3hY1JyHgmIa7fM0Nl0wiJ19CXXxe5+hIky1Gfc7oDIL5TvG3x8Zb /oBCruDkA7SczZUWT7cyHfyjziUp62U3kCbJr38Se6Md/Mrr6J6xOhXX53FP2BYYvrXF MZUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=xi4MuezFDq51SG2YiOr9pag6YuPFwc0iYukxu945qbs=; b=mRu6eWfKOCjeAX32MNzkzb8yAMMT9GiuRX8x+sP6YBCXTGGw4s0//1NfbI0Rfr7iIo 9h14Ucp+YbDy/4yi6qIn3/b0Yq7kZ80OUpOsX3h0QEe95komz/hLaOPEwQcQrBeHD3OU G8aSRpiVuWDNVot7ZRrebheHyyJAucLfNbypZCuaLuka0t6b2Jw2EVf+XGp0mc/UCyzd gKYm/1cPGBNLQjq4GcTMuhE8V8LnMqMCLVDk4gSqvHLBWwQYIyjOApXrdMixo8W+9LV+ fU+fs1L02PV8AYPFEsIqsMmUDdDnNHZ+lWm/Fq75m7oSN4OHd5PlzZMUDSSvcIV48puK k4SQ== X-Gm-Message-State: APjAAAVcKlII4gSkpDbHYKm1h/7S5wuqck+qVjVhr//0CC4KeT9RRQVL N8hUXn/Hx1NoMqW8vdcHiSRkON4wJwU= X-Google-Smtp-Source: APXvYqyvtlm/zALjZcqZklKGLc7iijS06D4RrLdGdryCJtphS1gndrAyk3LL1gibV/giEE3PD4AWfg== X-Received: by 2002:a37:f915:: with SMTP id l21mr6276159qkj.209.1573730564493; Thu, 14 Nov 2019 03:22:44 -0800 (PST) Received: from [192.168.1.4] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id a4sm2350393qko.57.2019.11.14.03.22.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Nov 2019 03:22:43 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9FCA5438-5E54-4163-A048-06F51787D872 Content-Transfer-Encoding: 7bit From: Kathleen Moriarty Mime-Version: 1.0 (1.0) Date: Thu, 14 Nov 2019 06:22:42 -0500 Message-Id: <71E7F9BF-4794-4FAF-9EDA-F28BFE1D9A55@gmail.com> References: Cc: Richard Barnes , Alex Davidson , secdispatch@ietf.org In-Reply-To: To: Nick Sullivan X-Mailer: iPhone Mail (17A878) Archived-At: Subject: Re: [Secdispatch] secdispatch agenda request: draft-privacy-pass-00 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, 14 Nov 2019 11:22:49 -0000 --Apple-Mail-9FCA5438-5E54-4163-A048-06F51787D872 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nick, Somehow, I missed your message. Sorry about that! There is time in the age= nda, so I=E2=80=99ll add it. Please get your slides to me as soon as possib= le. I won=E2=80=99t be attending and will have a significant time differenc= e . Thank you, Kathleen=20 Sent from my mobile device > On Nov 13, 2019, at 10:43 PM, Nick Sullivan wrote: >=20 > =EF=BB=BF > Hello Chairs, >=20 > I didn't see any time allotted for this discussion on the agenda. Can you p= lease confirm whether we will be able to do our presentation? >=20 > Best, > Nick >=20 >=20 >> On Mon, Nov 4, 2019 at 12:09 PM Nick Sullivan wrote= : >> Kathleen and Richard, >>=20 >> Alex Davidson and I have a draft we'd like to discuss at Secdispatch. The= draft outlines the Privacy Pass protocol currently in use at Cloudflare (ht= tps://blog.cloudflare.com/supporting-the-latest-version-of-the-privacy-pass-= protocol/). >>=20 >> Here are the documents: >> https://datatracker.ietf.org/doc/draft-privacy-pass/ >> https://tools.ietf.org/html/draft-privacy-pass-00 >>=20 >> This is a substantial piece of work, so it may require its own working gr= oup to tackle. Hopefully, SecDispatch will be able to provide some guidance a= round where this work can find a home. >>=20 >> Nick >>=20 --Apple-Mail-9FCA5438-5E54-4163-A048-06F51787D872 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nick,

Somehow, I miss= ed your message.  Sorry about that!  There is time in the agenda, s= o I=E2=80=99ll add it.  Please get your slides to me as soon as possibl= e.  I won=E2=80=99t be attending and will have a significant time diffe= rence .

Thank you,
Kathleen 


Sent from my mobile device

On Nov 13, 2019, at 10:43 PM, Nick Sullivan &= lt;nick@cloudflare.com> wrote:

=EF=BB=BF
Hello Chairs,

<= /div>
I didn't see any time allotted for this discussion on the agenda. C= an you please confirm whether we will be able to do our presentation?
<= div>
Best,
Nick


On Mon, Nov 4, 20= 19 at 12:09 PM Nick Sullivan <nick= @cloudflare.com> wrote:
Kathleen and Richard,

Alex Davidson and I have a draft we'd like to discuss at Secdispatch. T= he draft outlines the Privacy Pass protocol currently in use at Cloudflare (= https://blog.cloudflare.com/suppor= ting-the-latest-version-of-the-privacy-pass-protocol/).

Here are the documents:
https://datatracker.ietf.org/do= c/draft-privacy-pass/

This is a substantial piece of w= ork, so it may require its own working group to tackle. Hopefully, SecD= ispatch will be able to provide some guidance around where this work can fin= d a home.

Nick

= --Apple-Mail-9FCA5438-5E54-4163-A048-06F51787D872-- From nobody Thu Nov 14 07:38:56 2019 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 733ED12082C for ; Thu, 14 Nov 2019 07:38:54 -0800 (PST) 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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 yiP12m0a2ayo for ; Thu, 14 Nov 2019 07:38:52 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0: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 07B6D120129 for ; Thu, 14 Nov 2019 07:38:52 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id s71so5605987oih.11 for ; Thu, 14 Nov 2019 07:38:51 -0800 (PST) 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=IG4Wsjhb9TiQee1/hFxUq1W96Dx7+40Jh54cHIpkxEo=; b=bOxQE3qoWol35cMG7QxSTF2Rjmv2XixNxHTmEiLegJOlS4rsrebA4+dbxv3uXraWpF EBt4FFltAPu6KIEvJY97gGxbTr00IC7xfQa1NkpSJsmNpiJ+YnFEAhYEFBJisbgxe0gJ j8C+RYzstGT+Y+hQWB9OR69WcXgJoDdBxgvMcaqe6r958YM4mBgSCGI5qLJUWV62W4Uy nNGDTJgWOh/R1NF0f8ed8v7y1vdae9xIz5cJ8csSMp25bpyl0RSbVAUSQi1W36Ncw9w8 clAsyEO9IfbgslvCzjh/eAH4xwAXvxVYEX0JfWtTdRfKyxfYi3WMCvsUZgGaQs48kjRO Ix5g== 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=IG4Wsjhb9TiQee1/hFxUq1W96Dx7+40Jh54cHIpkxEo=; b=ZlegHQ9yW5hoLcP9LJ9s45O14qt3kDEJv833hDL9pThIXQthVq5d6qKuOcts+lYtGi vjfeFRUEeh1LvmNy/fO9USERFxEABsv4juEZ+w7o43Yd/g1951ct9oUE9F8HbFHh7OCq u3GAS3PfQPrV2e68bkHoItz1TvGj8NCKNvTlrObtE3BXqx69OeNlb98Buk1a71Ha0by+ QuWw+GMDt5KogZ+bMFoWDfmJuOoXzIchH5DEBR5RvvHTTCCMhAxpHZNGsdzv8rF3OF0T aDCJF0i0+vhpKjFf+gjXuKjzJXha5YGTTBiVsx262UH4kMpL4fX9or0Way0OnPuaNseD 6UKQ== X-Gm-Message-State: APjAAAUdd6S0//pxapwPS45/JuQnpSfbvHzqSUOMSlvNhlhZ9S/vsp7D v1qpPSxSV87bKMkKB7+b5S5ursrY2vIAC/Y62Uc= X-Google-Smtp-Source: APXvYqzfUf337j+pLCTk5heUHq0iWvDzv+5RELfyGCZ0Cml19s2JpG38799wYepAiirffqH6d2O6JMx5e75lPvh1F/o= X-Received: by 2002:a05:6808:498:: with SMTP id z24mr4068574oid.114.1573745931400; Thu, 14 Nov 2019 07:38:51 -0800 (PST) MIME-Version: 1.0 References: <71E7F9BF-4794-4FAF-9EDA-F28BFE1D9A55@gmail.com> In-Reply-To: <71E7F9BF-4794-4FAF-9EDA-F28BFE1D9A55@gmail.com> From: Kathleen Moriarty Date: Thu, 14 Nov 2019 10:38:15 -0500 Message-ID: To: Nick Sullivan Cc: Richard Barnes , Alex Davidson , IETF SecDispatch , Nancy Winget Content-Type: multipart/alternative; boundary="0000000000003539140597504702" Archived-At: Subject: Re: [Secdispatch] secdispatch agenda request: draft-privacy-pass-00 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, 14 Nov 2019 15:38:54 -0000 --0000000000003539140597504702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nick and Alex, I just reworked the agenda and squeezed you in. You'll have 10 minutes with discussion as we had a lot of requests for this meeting. Nancy has been added to this thread as she'll be in my seat at this meeting= . Best regards, Kathleen On Thu, Nov 14, 2019 at 6:22 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Nick, > > Somehow, I missed your message. Sorry about that! There is time in the > agenda, so I=E2=80=99ll add it. Please get your slides to me as soon as = possible. > I won=E2=80=99t be attending and will have a significant time difference = . > > Thank you, > Kathleen > > > Sent from my mobile device > > On Nov 13, 2019, at 10:43 PM, Nick Sullivan wrote: > > =EF=BB=BF > Hello Chairs, > > I didn't see any time allotted for this discussion on the agenda. Can you > please confirm whether we will be able to do our presentation? > > Best, > Nick > > > On Mon, Nov 4, 2019 at 12:09 PM Nick Sullivan wrote= : > >> Kathleen and Richard, >> >> Alex Davidson and I have a draft we'd like to discuss at Secdispatch. Th= e >> draft outlines the Privacy Pass protocol currently in use at Cloudflare = ( >> https://blog.cloudflare.com/supporting-the-latest-version-of-the-privacy= -pass-protocol/ >> ). >> >> Here are the documents: >> https://datatracker.ietf.org/doc/draft-privacy-pass/ >> https://tools.ietf.org/html/draft-privacy-pass-00 >> >> This is a substantial piece of work, so it may require its own working >> group to tackle. Hopefully, SecDispatch will be able to provide some >> guidance around where this work can find a home. >> >> Nick >> >> --=20 Best regards, Kathleen --0000000000003539140597504702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nick and Alex,

I just reworked the a= genda and squeezed you in.=C2=A0 You'll have 10 minutes with discussion= as we had a lot of requests for this meeting.

Nan= cy has been added to this thread as she'll be in my seat at this meetin= g.

Best regards,
Kathleen

=

On Thu, Nov 14, 2019 at 6:22 AM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&g= t; wrote:
Hi Nick,

Somehow, I missed your message.=C2= =A0 Sorry about that!=C2=A0 There is time in the agenda, so I=E2=80=99ll ad= d it.=C2=A0 Please get your slides to me as soon as possible.=C2=A0 I won= =E2=80=99t be attending and will have a significant time difference .
=

Thank you,
Kathleen=C2=A0


<= div dir=3D"ltr">Sent from my mobile device

On Nov 13, 2019, at 10:43 PM, Nick Sullivan <nick@cloudflare.com&g= t; wrote:

=EF=BB=BF
Hello Chairs,

I didn't= see any time allotted for this discussion on the agenda. Can you please co= nfirm whether we will be able to do our presentation?

<= div>Best,
Nick


On Mon, Nov 4, 2019 at 12:09 P= M Nick Sullivan <nick@cloudflare.com> wrote:
Kathleen and Richard,
=
Alex Davidson and I have a draft we'd like to discuss at= Secdispatch. The draft outlines the Privacy Pass protocol currently in use= at Cloudflare (https://blog.clo= udflare.com/supporting-the-latest-version-of-the-privacy-pass-protocol/= ).

Here are the documents:
https://da= tatracker.ietf.org/doc/draft-privacy-pass/

This is= a substantial piece of work, so it may require=C2=A0its own working group = to tackle. Hopefully, SecDispatch will be able to provide some guidance aro= und where this work can find a home.

Nick


--
=
Best regards,
Kathleen
--0000000000003539140597504702-- From nobody Thu Nov 14 14:34:22 2019 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 61A4C12004F for ; Thu, 14 Nov 2019 14:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 Mq7CQ08M_TBX for ; Thu, 14 Nov 2019 14:34:18 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 5FBD7120026 for ; Thu, 14 Nov 2019 14:34:18 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id k24so1898450vko.7 for ; Thu, 14 Nov 2019 14:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iWcSe7ERZHE2zfEa+htSgRiIZYRFpEIWF5sDGDWz4vo=; b=V8z8pZEBO4Oy6M6QooRm6TcOGJsVnl7n1eoMaY5uBpZjtiG24uCPxn200Em2kwkem2 bRphw9sRSrvqNo37QHgbXcQN2uz+vUyLuupt0/OCukKgkddZH3yPknvvMduScu1a7eVm RbOxie7k5kUVrtQZFbES6ValIniVLbKr9i7jc= 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=iWcSe7ERZHE2zfEa+htSgRiIZYRFpEIWF5sDGDWz4vo=; b=LfO3F6NExKKv735dytweIvkk03hJ+N+/YKE1gobR69X1W0BvCtoTvt+uYSNIaLZWdB rn04guLBdZumUAGe2a+2LjOdbQD0C//8Fppvz+N8unqzcBYsqMGxB74ekro0WikQR2NY AVsLr2QeaA+aapRuYLrMr0cEVdOvUJkdxoiTTrBfA4fKnSCRrlEvXe2t7xPbTG0qqlGy LuzQIsqSP3MBKX+Tny7CnKr1Ddkh2j41v3w0wWo3HrNdryEhnyDxxEHFn4GXdPfAliCA tnA+O2h3p5jruwxuoH3VcKqPH5wuMasGd9p1dCcC5ghez5qLqzKnH9qnThdnsJTEI+9N gdWQ== X-Gm-Message-State: APjAAAVgbp2NRG8+5PyTWIaJ4loNIZ5Ff2zyBafodfV+K+kd5hrP2cxa yXZcLKKpFGpkn0qhI/8CoukvWrmtTtXeiiufcI6LnA== X-Google-Smtp-Source: APXvYqxTigXOygCMA6Ko+G0rs3dx4tJZjSPRuhzPzNwgb5mQDCOoMxWEHxhkr7SpRSIaf4iDD3LCYPBU6zvZ18O5kdU= X-Received: by 2002:a1f:2cd:: with SMTP id 196mr6748263vkc.23.1573770857000; Thu, 14 Nov 2019 14:34:17 -0800 (PST) MIME-Version: 1.0 References: <71E7F9BF-4794-4FAF-9EDA-F28BFE1D9A55@gmail.com> In-Reply-To: From: Nick Sullivan Date: Fri, 15 Nov 2019 06:34:00 +0800 Message-ID: To: Kathleen Moriarty Cc: Richard Barnes , Alex Davidson , IETF SecDispatch , Nancy Winget Content-Type: multipart/alternative; boundary="000000000000e3faee05975614f0" Archived-At: Subject: Re: [Secdispatch] secdispatch agenda request: draft-privacy-pass-00 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, 14 Nov 2019 22:34:20 -0000 --000000000000e3faee05975614f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Kathleen, We appreciate this and are looking forward to the in-person discussion. Best, Nick On Thu, Nov 14, 2019 at 11:38 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Nick and Alex, > > I just reworked the agenda and squeezed you in. You'll have 10 minutes > with discussion as we had a lot of requests for this meeting. > > Nancy has been added to this thread as she'll be in my seat at this > meeting. > > Best regards, > Kathleen > > > On Thu, Nov 14, 2019 at 6:22 AM Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hi Nick, >> >> Somehow, I missed your message. Sorry about that! There is time in the >> agenda, so I=E2=80=99ll add it. Please get your slides to me as soon as= possible. >> I won=E2=80=99t be attending and will have a significant time difference= . >> >> Thank you, >> Kathleen >> >> >> Sent from my mobile device >> >> On Nov 13, 2019, at 10:43 PM, Nick Sullivan wrote: >> >> =EF=BB=BF >> Hello Chairs, >> >> I didn't see any time allotted for this discussion on the agenda. Can yo= u >> please confirm whether we will be able to do our presentation? >> >> Best, >> Nick >> >> >> On Mon, Nov 4, 2019 at 12:09 PM Nick Sullivan >> wrote: >> >>> Kathleen and Richard, >>> >>> Alex Davidson and I have a draft we'd like to discuss at Secdispatch. >>> The draft outlines the Privacy Pass protocol currently in use at Cloudf= lare >>> ( >>> https://blog.cloudflare.com/supporting-the-latest-version-of-the-privac= y-pass-protocol/ >>> ). >>> >>> Here are the documents: >>> https://datatracker.ietf.org/doc/draft-privacy-pass/ >>> https://tools.ietf.org/html/draft-privacy-pass-00 >>> >>> This is a substantial piece of work, so it may require its own working >>> group to tackle. Hopefully, SecDispatch will be able to provide some >>> guidance around where this work can find a home. >>> >>> Nick >>> >>> > > -- > > Best regards, > Kathleen > --000000000000e3faee05975614f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Kathleen,

We appreciate this and= are looking forward to the in-person discussion.

= Best,
Nick

On Thu, Nov 14, 2019 at 11:38 PM Kathleen Moriart= y <kathleen.moriarty= .ietf@gmail.com> wrote:
Hi Nick and Alex,

I just= reworked the agenda and squeezed you in.=C2=A0 You'll have 10 minutes = with discussion as we had a lot of requests for this meeting.
Nancy has been added to this thread as she'll be in my seat= at this meeting.

Best regards,
Kathleen=


On Thu, Nov 14, 2019 at 6:22 AM Kathleen Moriarty <= kathl= een.moriarty.ietf@gmail.com> wrote:
Hi Nick,

So= mehow, I missed your message.=C2=A0 Sorry about that!=C2=A0 There is time i= n the agenda, so I=E2=80=99ll add it.=C2=A0 Please get your slides to me as= soon as possible.=C2=A0 I won=E2=80=99t be attending and will have a signi= ficant time difference .

Thank you,
Kath= leen=C2=A0


Sent from my mobile device

On Nov 13, 2019, at 10:43= PM, Nick Sullivan <nick@cloudflare.com> wrote:

=EF=BB=BF
Hello Chairs,
I didn't see any time allotted for this discussion on= the agenda. Can you please confirm whether we will be able to do our prese= ntation?

Best,
Nick

=

= On Mon, Nov 4, 2019 at 12:09 PM Nick Sullivan <nick@cloudflare.com> wrote:
Ka= thleen and Richard,

Alex Davidson and I have a dra= ft we'd like to discuss at Secdispatch. The draft outlines the Privacy = Pass protocol currently in use at Cloudflare (https://blog.cloudflare.com/supporting-the-latest-version-of-= the-privacy-pass-protocol/).

Here are the docu= ments:
https://datatracker.ietf.org/doc/draft-privacy-pass/
https://tools.ietf.org/html/draft-privacy-pass-00

This is a substantial piece of work, so it may requi= re=C2=A0its own working group to tackle. Hopefully, SecDispatch will be abl= e to provide some guidance around where this work can find a home.

Nick


--

Best regards,
Kathleen
--000000000000e3faee05975614f0-- From nobody Mon Nov 18 19:55:46 2019 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 8E494120013 for ; Mon, 18 Nov 2019 19:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.137 X-Spam-Level: **** X-Spam-Status: No, score=4.137 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 WaRezv__-a8C for ; Mon, 18 Nov 2019 19:55:40 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4A59A12004C for ; Mon, 18 Nov 2019 19:55:40 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 2167137413B5 for ; Tue, 19 Nov 2019 03:55:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4lO2Rb9mybc3 for ; Mon, 18 Nov 2019 22:55:39 -0500 (EST) Received: from Maxs-MacBook-Pro-2.local (unknown [101.100.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id A9B293740808 for ; Mon, 18 Nov 2019 22:55:38 -0500 (EST) To: secdispatch@ietf.org From: "Dr. Pala" Message-ID: Date: Tue, 19 Nov 2019 11:55:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B9D1E7E849BD0B28353ABFBA" Content-Language: en-US Archived-At: Subject: [Secdispatch] Some Experiments: TLS, PQ and Key Exchanges 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, 19 Nov 2019 03:55:45 -0000 This is a multi-part message in MIME format. --------------B9D1E7E849BD0B28353ABFBA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi SecDispatch, I just wanted to share with you some interesting results for "large" keys vs. computational intense algos and TLS that was recently published in two different blog posts - one from Amazon and one from Cloudflare: * https://aws.amazon.com/blogs/security/post-quantum-tls-now-supported-in-aws-kms/ * https://blog.cloudflare.com/the-tls-post-quantum-experiment/ definitely worth reading :D Maybe the situation for TLS and large keys in certificates might not be as bad of an issue as initially thought... :) ... ??? Does anybody has any comment ? Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------B9D1E7E849BD0B28353ABFBA Content-Type: multipart/related; boundary="------------81E713A96D7705F04A3AE5B6" --------------81E713A96D7705F04A3AE5B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi SecDispatch,

I just wanted to share with you some interesting results for "large" keys vs. computational intense algos and TLS that was recently published in two different blog posts - one from Amazon and one from Cloudflare:

definitely worth reading :D Maybe the situation for TLS and large keys in certificates might not be as bad of an issue as initially thought... :) ... ???

Does anybody has any comment ?

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------81E713A96D7705F04A3AE5B6 Content-Type: image/png; name="magfbljcfknhmpmm.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="magfbljcfknhmpmm.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------81E713A96D7705F04A3AE5B6-- --------------B9D1E7E849BD0B28353ABFBA-- From nobody Mon Nov 18 20:37:52 2019 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 A28DA12008A for ; Mon, 18 Nov 2019 20:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=km3FGcGH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CZgg6aYA 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 6boWB4clewii for ; Mon, 18 Nov 2019 20:37:47 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F2C12006F for ; Mon, 18 Nov 2019 20:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19155; q=dns/txt; s=iport; t=1574138266; x=1575347866; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=su885bJsfT6xZKZwaAHJri3+3hck1Hr/ob1dUP4l5JM=; b=km3FGcGHlVOmwDpi9xtsEfGN+1+xCKC9GlDR9wzr5FArE5qNOgJHfQpn 3v5irT3+x733hDkRKAvbdaPk5SrUMwSm3vEJLy+x3kFMRNY4tt62tvxB1 e9n6kEX1T2DwEY8okfK+yTM0dXIFq67hWLXsfHJgN1Nx4s6ns8x1mSZ0o 0=; X-Files: image001.png : 3146 IronPort-PHdr: =?us-ascii?q?9a23=3AMpezXh/tETAiCv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaGAEjjJfjjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANEAAvcdNd/4oNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BHC9QBWxYIAQLKoQqg0YDinMUOoIQkx6EYoJSA1QCBwEBAQk?= =?us-ascii?q?BAgEBJQgCAQGEQAIXggwkOBMCAwsBAQQBAQECAQUEbYU3DIVRAQEBAQECBQE?= =?us-ascii?q?MEQIIARIBATgPAgEIEQQBAQYBAQEVDQICAgUQAQ4MHQgCBAERAQYCBg0HgwG?= =?us-ascii?q?CRgMuAQIMpVcCgTiIYHWBMoJ+AQEFgTQBg0kYghAHAwaBNowVGIFAP4ERRoJ?= =?us-ascii?q?MPoJiAgGBYhUWgmMygiyQE4VHgRKNVYJmhwYKgiqGAgGBF45QmhGNE4E1iDi?= =?us-ascii?q?RUAIEAgQFAg4BAQWBaSKBWHAVgnMBM1ARFJEag3OFFIU/dAELgRyMU1sBAQ?= X-IronPort-AV: E=Sophos;i="5.68,322,1569283200"; d="png'150?scan'150,208,217,150";a="670467948" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2019 04:37:45 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xAJ4bjIq005653 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Nov 2019 04:37:45 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 22:37:44 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 22:37:43 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 23:37:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MUAGadJHqHM8t8W9mf/MNpclUVVhjTd91S1Dg5gR1ID4NMLzTchP0umxIxU5ZLetHtfmCXRIV+QvaJl1hw+nOnrzBULjPY4YLlE2UNlagJ/puOFhn7+MPLJgHw1qdC+oSDxZkEh6cZnNEpIubBThi1bEqK5FCB0bEtwgxSRaILSjzSlH2GJkthOnb7sa5hsP8WjxZKuWn4JSJ/Fx1ZUgM2EUPFrGG9J9I8PkJDgz4y71UzRQlp3P81vf4gNzkMNXRQVqpOp53p46n+nuYR9hNwjXL52eQZt/FfEClwbA5vjPOCj4rpY6v3aRUMJr1xw7oXM4Z623o4jQn1j6xDpS6Q== 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=epwBUN7nSfO8LgC/bqHq3WwFAQvY3usioqEEeof+B8I=; b=lATOi5z08YNFzS+AJdiHy7T8llef2f3P7AtUI9vTljIQ8GVaV53E1h3zxh9Lpw1+0w+Jt0UZOzk7WX6onTK7135EcOCDFfH8sHxmzAZ57Ok/59WXSl3BXtsZYZReDdZtT69/v5Cuu0TTOG03FiPMmezpA6Z3M1buT1+gJcGNsHqxwvR6KzuzsWYCFzIEzWxsHnpcrdsb8gMJfWBm8kMWEVERwdZi7dkZbM1eibemri4qFMkNTzZmJserulEICjDYCMLAOCAleOyKrScIj0sqZEsAptwxUGzc32oXOZa/LTeeAxRsDjSi/rPOjlDLXyOEPyQpRzOfk3XdrHRuxUEnwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=epwBUN7nSfO8LgC/bqHq3WwFAQvY3usioqEEeof+B8I=; b=CZgg6aYAMsnDo9LJaikNLD64dAdDtb9OHWcVvpu6e8owl/2hlJFE6uLC3dF8TFMsFXVUlxFS27eN+DgjwyD/aXC3L8dzEXA+vaEfCug0BzTWaaRcvEO40lsoUHVoTFwTrdkDDnYVigsgay+45CujImKzySPngy19PUVbQ9JZpxA= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2706.namprd11.prod.outlook.com (52.135.245.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.28; Tue, 19 Nov 2019 04:37:42 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2451.031; Tue, 19 Nov 2019 04:37:42 +0000 From: "Panos Kampanakis (pkampana)" To: "Dr. Pala" , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Some Experiments: TLS, PQ and Key Exchanges Thread-Index: AQHVno1IyPKMny1hpUKMti+Y6vGIdKeR5viw Date: Tue, 19 Nov 2019 04:37:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 562fd33a-d975-463a-cea0-08d76caa3780 x-ms-traffictypediagnostic: BN7PR11MB2706: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(376002)(136003)(396003)(199004)(189003)(316002)(55016002)(7736002)(606006)(6306002)(54896002)(9686003)(236005)(33656002)(6436002)(6246003)(86362001)(733005)(14454004)(6116002)(229853002)(478600001)(2501003)(71190400001)(71200400001)(76116006)(966005)(25786009)(110136005)(186003)(74316002)(8936002)(76176011)(7696005)(99286004)(81166006)(256004)(8676002)(790700001)(81156014)(14444005)(476003)(66616009)(64756008)(66446008)(66946007)(66556008)(66476007)(5660300002)(52536014)(46003)(2906002)(486006)(6506007)(53546011)(446003)(102836004)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2706; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0lxGD4PdTuO81VK4Sz2HTfV+IzRinzjtLHK7jEgOopeMC3wxjEcLQjuqkSC5yvy8JBttGx5jxthUOzuYmRWVkvJz2IX+W/Jdtgq5mH3Iispt74k8AFbTTlB0ZXcnlwHVyCPvl8TabFwfqAqN03jSz5dkfk1sVu38sLztCB+unw4WV0JuCWAjfkcnttKJmVMdDTCrm6MDRay2ZKWTUTZqoNvzfu49PndaFrSq0Fx52aYVr8iuYMCkaiOYHZJT1olyimrgi60PWbgweypN7KZX77tF7l9n/u9nlPpEHBDMzyd2auTgT4kAMmHqVacxWOLyL6kVz0XTtCYINDoejNhmCq3SrXb4wkk7zP65m7c4jp32P/VaCAavd8G1bw6Ppu2yZIeATVrxu/OQns7DE6F1S5IaVNWz8MKdbNrK4WmrQQeaOWAP8kkgBEA7zsARh454gWciCHjXKzi6b70EnF1NnFYxtSToS6up1aJxCcnAsYM= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 562fd33a-d975-463a-cea0-08d76caa3780 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 04:37:42.5674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0xWpGkRr0E/XAMwbL/fJHCK1Fg4AV9rYGvPXXls0l0lsaVJqmKb+O7TffWN7xN90KhkvIl8eUhuOXzsNGCsmgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2706 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Secdispatch] Some Experiments: TLS, PQ and Key Exchanges 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, 19 Nov 2019 04:37:52 -0000 --_004_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_ Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_" --_000_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpBIGxpdHRsZSBjbG9zZXIgdG8gd2hhdCB5b3UgYXJlIHJlZmVycmluZyB0byBNYXgsIGluIFNl Y3Rpb24gNCBvZiBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE5LzEyNzYucGRmIHdlIHNoYXJl IG91ciBwcmVsaW1pbmFyeSBleHBlcmltZW50YWwgcmVzdWx0cyB3aXRoIFBRIHNpZ25hdHVyZSBj ZXJ0cyBpbiBUTFMgMS4zLiBXZSBmb3VuZCB0aGF0IHR3byBOSVNUIHNpZ25hdHVyZSBjYW5kaWRh dGVzIHNlZW0gdGhlIGJlc3QuIEFsbCBvdGhlcnMgaW50cm9kdWNlZCBleHRyYSByb3VuZC10cmlw cyBiZWNhdXNlIG9mIHRoZSBjaGFpbiBzaXplIG5vdCBmaXR0aW5nIGluIHRoZSBUQ1AgY29uZ2Vz dGlvbiB3aW5kb3cgYW5kIHdvdWxkIG5vdCBiZSBzYXRpc2ZhY3RvcnkgZm9yIGxhdGVuY3ktc2Vu c2l0aXZlIGFwcGxpY2F0aW9ucy4NCg0KVGhlcmUgaXMgbW9yZSBkZXRhaWxlZCB3b3JrIHRoYXQg d2UgaGF2ZSBub3QgcHVibGlzaGVkIHlldCwgd2hpY2ggaW5jbHVkZXMgbXVjaCBtb3JlIGRldGFp bCB0aGFuIHRoZSBhYm92ZSBwYXBlciBhbmQgcHJvcG9zZXMgc29tZSBtb3JlIHNvbHV0aW9ucy4g V2lsbCBzaGFyZSBpdCBpbiBkdWUgdGltZS4NCg0KUmdzLA0KUGFub3MNCg0KDQpGcm9tOiBTZWNk aXNwYXRjaCA8c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERyLiBQ YWxhDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDE4LCAyMDE5IDEwOjU2IFBNDQpUbzogc2VjZGlz cGF0Y2hAaWV0Zi5vcmcNClN1YmplY3Q6IFtTZWNkaXNwYXRjaF0gU29tZSBFeHBlcmltZW50czog VExTLCBQUSBhbmQgS2V5IEV4Y2hhbmdlcw0KDQoNCkhpIFNlY0Rpc3BhdGNoLA0KDQpJIGp1c3Qg d2FudGVkIHRvIHNoYXJlIHdpdGggeW91IHNvbWUgaW50ZXJlc3RpbmcgcmVzdWx0cyBmb3IgImxh cmdlIiBrZXlzIHZzLiBjb21wdXRhdGlvbmFsIGludGVuc2UgYWxnb3MgYW5kIFRMUyB0aGF0IHdh cyByZWNlbnRseSBwdWJsaXNoZWQgaW4gdHdvIGRpZmZlcmVudCBibG9nIHBvc3RzIC0gb25lIGZy b20gQW1hem9uIGFuZCBvbmUgZnJvbSBDbG91ZGZsYXJlOg0KDQogICogICBodHRwczovL2F3cy5h bWF6b24uY29tL2Jsb2dzL3NlY3VyaXR5L3Bvc3QtcXVhbnR1bS10bHMtbm93LXN1cHBvcnRlZC1p bi1hd3Mta21zLw0KICAqICAgaHR0cHM6Ly9ibG9nLmNsb3VkZmxhcmUuY29tL3RoZS10bHMtcG9z dC1xdWFudHVtLWV4cGVyaW1lbnQvDQpkZWZpbml0ZWx5IHdvcnRoIHJlYWRpbmcgOkQgTWF5YmUg dGhlIHNpdHVhdGlvbiBmb3IgVExTIGFuZCBsYXJnZSBrZXlzIGluIGNlcnRpZmljYXRlcyBtaWdo dCBub3QgYmUgYXMgYmFkIG9mIGFuIGlzc3VlIGFzIGluaXRpYWxseSB0aG91Z2h0Li4uIDopIC4u LiA/Pz8NCg0KRG9lcyBhbnlib2R5IGhhcyBhbnkgY29tbWVudCA/DQoNCkNoZWVycywNCk1heA0K DQotLQ0KQmVzdCBSZWdhcmRzLA0KTWFzc2ltaWxpYW5vIFBhbGEsIFBoLkQuDQpPcGVuQ0EgTGFi cyBEaXJlY3Rvcg0KW09wZW5DQSBMb2dvXQ0K --_000_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlv bjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6NjI3MDU1NTgyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MTcyNzUxNTgxNjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+QSBsaXR0bGUgY2xvc2VyIHRvIHdoYXQgeW91IGFyZSByZWZlcnJp bmcgdG8gTWF4LCBpbiBTZWN0aW9uIDQgb2YNCjxhIGhyZWY9Imh0dHBzOi8vZXByaW50LmlhY3Iu b3JnLzIwMTkvMTI3Ni5wZGYiPmh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTkvMTI3Ni5wZGY8 L2E+IHdlIHNoYXJlIG91ciBwcmVsaW1pbmFyeSBleHBlcmltZW50YWwgcmVzdWx0cyB3aXRoIFBR IHNpZ25hdHVyZSBjZXJ0cyBpbiBUTFMgMS4zLiBXZSBmb3VuZCB0aGF0IHR3byBOSVNUIHNpZ25h dHVyZSBjYW5kaWRhdGVzIHNlZW0gdGhlIGJlc3QuIEFsbCBvdGhlcnMgaW50cm9kdWNlZCBleHRy YQ0KIHJvdW5kLXRyaXBzIGJlY2F1c2Ugb2YgdGhlIGNoYWluIHNpemUgbm90IGZpdHRpbmcgaW4g dGhlIFRDUCBjb25nZXN0aW9uIHdpbmRvdyBhbmQgd291bGQgbm90IGJlIHNhdGlzZmFjdG9yeSBm b3IgbGF0ZW5jeS1zZW5zaXRpdmUgYXBwbGljYXRpb25zLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBtb3JlIGRldGFpbGVkIHdvcmsgdGhhdCB3ZSBoYXZl IG5vdCBwdWJsaXNoZWQgeWV0LCB3aGljaCBpbmNsdWRlcyBtdWNoIG1vcmUgZGV0YWlsIHRoYW4g dGhlIGFib3ZlIHBhcGVyIGFuZCBwcm9wb3NlcyBzb21lIG1vcmUgc29sdXRpb25zLiBXaWxsIHNo YXJlIGl0IGluIGR1ZSB0aW1lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5SZ3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBhbm9zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNlY2Rpc3Bh dGNoICZsdDtzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YN CjwvYj5Eci4gUGFsYTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDE4LCAyMDE5 IDEwOjU2IFBNPGJyPg0KPGI+VG86PC9iPiBzZWNkaXNwYXRjaEBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBbU2VjZGlzcGF0Y2hdIFNvbWUgRXhwZXJpbWVudHM6IFRMUywgUFEgYW5kIEtl eSBFeGNoYW5nZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkhpIFNlY0Rpc3BhdGNoLDxvOnA+PC9v OnA+PC9wPg0KPHA+SSBqdXN0IHdhbnRlZCB0byBzaGFyZSB3aXRoIHlvdSBzb21lIGludGVyZXN0 aW5nIHJlc3VsdHMgZm9yICZxdW90O2xhcmdlJnF1b3Q7IGtleXMgdnMuIGNvbXB1dGF0aW9uYWwg aW50ZW5zZSBhbGdvcyBhbmQgVExTIHRoYXQgd2FzIHJlY2VudGx5IHB1Ymxpc2hlZCBpbiB0d28g ZGlmZmVyZW50IGJsb2cgcG9zdHMgLSBvbmUgZnJvbSBBbWF6b24gYW5kIG9uZSBmcm9tIENsb3Vk ZmxhcmU6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxhIGhyZWY9Imh0dHBzOi8vYXdzLmFt YXpvbi5jb20vYmxvZ3Mvc2VjdXJpdHkvcG9zdC1xdWFudHVtLXRscy1ub3ctc3VwcG9ydGVkLWlu LWF3cy1rbXMiIHRpdGxlPSJodHRwczovL2F3cy5hbWF6b24uY29tL2Jsb2dzL3NlY3VyaXR5L3Bv c3QtcXVhbnR1bS10bHMtbm93LXN1cHBvcnRlZC1pbi1hd3Mta21zIj48c3BhbiBzdHlsZT0iY29s b3I6Izk1NEY3MiI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9ibG9ncy9zZWN1cml0eS9wb3N0LXF1 YW50dW0tdGxzLW5vdy1zdXBwb3J0ZWQtaW4tYXdzLWttczwvc3Bhbj48L2E+LzxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxh IGhyZWY9Imh0dHBzOi8vYmxvZy5jbG91ZGZsYXJlLmNvbS90aGUtdGxzLXBvc3QtcXVhbnR1bS1l eHBlcmltZW50Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9ibG9nLmNsb3Vk ZmxhcmUuY29tL3RoZS10bHMtcG9zdC1xdWFudHVtLWV4cGVyaW1lbnQ8L3NwYW4+PC9hPi88bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ ZGVmaW5pdGVseSB3b3J0aCByZWFkaW5nIDpEIE1heWJlIHRoZSBzaXR1YXRpb24gZm9yIFRMUyBh bmQgbGFyZ2Uga2V5cyBpbiBjZXJ0aWZpY2F0ZXMgbWlnaHQgbm90IGJlIGFzIGJhZCBvZiBhbiBp c3N1ZSBhcyBpbml0aWFsbHkgdGhvdWdodC4uLiA6KSAuLi4gPz8/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5Eb2VzIGFueWJvZHkgaGFzIGFueSBjb21tZW50ID88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkNoZWVycyw8YnI+DQpNYXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjcuNXB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QmVzdCBSZWdhcmRzLCA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOjMuNzVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1hc3NpbWlsaWFu byBQYWxhLCBQaC5ELjxicj4NCk9wZW5DQSBMYWJzIERpcmVjdG9yPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjU0IiBzdHlsZT0id2lkdGg6 MS4wNDE2aW47aGVpZ2h0Oi41NjI1aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmltYWdl MDAxLnBuZ0AwMUQ1OUU2OS4yMjZEMjJCMCIgYWx0PSJPcGVuQ0EgTG9nbyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_-- --_004_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3146; creation-date="Tue, 19 Nov 2019 04:37:42 GMT"; modification-date="Tue, 19 Nov 2019 04:37:42 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --_004_BN7PR11MB2547C248843270686E52C335C94C0BN7PR11MB2547namp_-- From nobody Tue Nov 19 05:10:59 2019 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 E44A11208FE for ; Tue, 19 Nov 2019 05:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 2wpMaJzhqdEY for ; Tue, 19 Nov 2019 05:10:58 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id F2D9D1208BB for ; Tue, 19 Nov 2019 05:10:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id C1C5937413DF; Tue, 19 Nov 2019 13:10:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VWSssSLWe0bC; Tue, 19 Nov 2019 08:10:56 -0500 (EST) Received: from Maxs-MacBook-Pro-2.local (unknown [101.100.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 1B71037408D6; Tue, 19 Nov 2019 08:10:55 -0500 (EST) To: secdispatch@ietf.org, Nick Sullivan , Tim Hollebeek From: "Dr. Pala" Message-ID: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> Date: Tue, 19 Nov 2019 21:10:54 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3B831676579B708DADB1F256" Content-Language: en-US Archived-At: Subject: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) 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, 19 Nov 2019 13:10:59 -0000 This is a multi-part message in MIME format. --------------3B831676579B708DADB1F256 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Nick, all, at the end of the second presentation on lowering the costs of revocation, if I am not mistaken, your question/comment (Nick) was about the fact that Cloudflare hosts / serve most of the cached OCSP responses and that the system does not have issues. I am not sure if this comment is pertinent to what we are trying to solve here... let me elaborate a bit more. The work we have been doing around the proposed topic of work is aimed at /_lowering the cost of *generating* and *distributing* these large volumes of signed data_/ when there is actually no need for that. By optimizing the protocol to provide range responses (or other methods, if we decide to go with a different approaches), we can reduce the number of signatures needed from a CA and their distribution - very expensive operations. In other words, the proposal is /_not aimed at fixing any caching issues_/ because, as you noticed in your comment, that works just fine. The proposal at hand, instead, is about fixing a problem that CAs are facing today - high costs of deploying and running such systems. On the other hand, your comment made me think about the caching service you mentioned and its associated costs. Is it a service for which your company charge CAs ? If so, would you be able to share what are currently the costs incurred by CAs to leverage your service ? (I totally understand if you are not willing to - after all, this is usually the secret sauce :D) Last but not least, I also would like to point out that optimizing the revocation can also help open-source communities, small companies, universities, non-profit, etc. by enabling them to deploy cost-efficient systems that can provide good quality of service using less resources (computational, storage, network). Please let me know, Cheers, Max P.S.: If we could combine this idea with OCSP over DNS, we could really provide access to revocation technology for everybody, not just who can afford the price. Unfortunately we know how that discussion went, and I still think it is a very evident mistake not doing it  (I am still working on this in my spare time - I think it is of enormous value for emerging countries to have access to cheap secure technologies and, in my opinion, IETF is dropping / has dropped the ball on this for not-so-honorable reasons, I suspect...). I hope We can fix it in the open-source community. -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------3B831676579B708DADB1F256 Content-Type: multipart/related; boundary="------------91E77FBC149B8A5E19846E6A" --------------91E77FBC149B8A5E19846E6A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Nick, all,

at the end of the second presentation on lowering the costs of revocation, if I am not mistaken, your question/comment (Nick) was about the fact that Cloudflare hosts / serve most of the cached OCSP responses and that the system does not have issues.

I am not sure if this comment is pertinent to what we are trying to solve here... let me elaborate a bit more.

The work we have been doing around the proposed topic of work is aimed at lowering the cost of generating and distributing these large volumes of signed data when there is actually no need for that. By optimizing the protocol to provide range responses (or other methods, if we decide to go with a different approaches), we can reduce the number of signatures needed from a CA and their distribution - very expensive operations.

In other words, the proposal is not aimed at fixing any caching issues because, as you noticed in your comment, that works just fine. The proposal at hand, instead, is about fixing a problem that CAs are facing today - high costs of deploying and running such systems.

On the other hand, your comment made me think about the caching service you mentioned and its associated costs.

Is it a service for which your company charge CAs ? If so, would you be able to share what are currently the costs incurred by CAs to leverage your service ? (I totally understand if you are not willing to - after all, this is usually the secret sauce :D)

Last but not least, I also would like to point out that optimizing the revocation can also help open-source communities, small companies, universities, non-profit, etc. by enabling them to deploy cost-efficient systems that can provide good quality of service using less resources (computational, storage, network).

Please let me know,

Cheers,
Max

P.S.: If we could combine this idea with OCSP over DNS, we could really provide access to revocation technology for everybody, not just who can afford the price. Unfortunately we know how that discussion went, and I still think it is a very evident mistake not doing it  (I am still working on this in my spare time - I think it is of enormous value for emerging countries to have access to cheap secure technologies and, in my opinion, IETF is dropping / has dropped the ball on this for not-so-honorable reasons, I suspect...). I hope We can fix it in the open-source community.

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------91E77FBC149B8A5E19846E6A Content-Type: image/png; name="dhmacjdifkefaoin.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dhmacjdifkefaoin.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------91E77FBC149B8A5E19846E6A-- --------------3B831676579B708DADB1F256-- From nobody Tue Nov 19 06:18:08 2019 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 92FEB12092B for ; Tue, 19 Nov 2019 06:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.841 X-Spam-Level: ** X-Spam-Status: No, score=2.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 KLJiIaRsVfpB for ; Tue, 19 Nov 2019 06:18:05 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id A8317120921 for ; Tue, 19 Nov 2019 06:18:05 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 567C137413B5; Tue, 19 Nov 2019 14:18:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id THMjUY5K-0Vn; Tue, 19 Nov 2019 09:18:04 -0500 (EST) Received: from Maxs-MacBook-Pro-2.local (unknown [101.100.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 0670037408D6; Tue, 19 Nov 2019 09:18:03 -0500 (EST) To: secdispatch@ietf.org, Eric Rescorla From: "Dr. Pala" Message-ID: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> Date: Tue, 19 Nov 2019 22:18:02 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------66B72031CA31C3C5A74B1276" Content-Language: en-US Archived-At: Subject: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( 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, 19 Nov 2019 14:18:07 -0000 This is a multi-part message in MIME format. --------------66B72031CA31C3C5A74B1276 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Eric, all, I am sorry I had quite a hard time to understand the questions/comments=20 today, however, I would like to properly address the raised concerns/poin= ts. *Clients / Software Updates Comment:* I wanted to understand your questions/comments about the need to update clients and that would never happen. Could you please elaborate on this point ? It is my understanding that we do have to update our crypto libraries when we want to support a new algorithm, and that is what we are talking about. Any time we add a new algorithm, the software needs to be updated - but I do not see why this is a problem specific for this solution. ALL of the approaches will need software updates (exactly as we did for TLS 1.3). Personally, I think that Composite Crypto is also interesting from this point of view since updating the crypto layer will enable its use without the need to change protocols or application behavior. From an application-development point of view, IMHO, it is a very intriguing approach. *SHA-1 Transition:* One of your comments, if I am not mistaken, was about comparing one of the possible solutions to the problem (Composite Crypto) with the SHA-1 transitioning period - how, in your opinion, is that transition process related to the specifics of the proposal ? Again, I am sorry I could not understand the questions clearly (normal=20 language barrier issues :D), but I hope I can address your concerns on=20 the list. Thanks again, Cheers, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------66B72031CA31C3C5A74B1276 Content-Type: multipart/related; boundary="------------D06704EAF15A4D888B58E0E9" --------------D06704EAF15A4D888B58E0E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Eric, all,

I am sorry I had quite a hard time to understand the questions/comments today, however, I would like to properly address the raised concerns/points.

Clients / Software Updates Comment:

I wanted to understand your questions/comments about the need to update clients and that would never happen.

Could you please elaborate on this point ?

It is my understanding that we do have to update our crypto libraries when we want to support a new algorithm, and that is what we are talking about. Any time we add a new algorithm, the software needs to be updated - but I do not see why this is a problem specific for this solution. ALL of the approaches will need software updates (exactly as we did for TLS 1.3).

Personally, I think that Composite Crypto is also interesting from this point of view since updating the crypto layer will enable its use without the need to change protocols or application behavior. From an application-development point of view, IMHO, it is a very intriguing approach.

SHA-1 Transition:

One of your comments, if I am not mistaken, was about comparing one of the possible solutions to the problem (Composite Crypto) with the SHA-1 transitioning period - how, in your opinion, is that transition process related to the specifics of the proposal ?

Again, I am sorry I could not understand the questions clearly (normal language barrier issues :D), but I hope I can address your concerns on the list.

Thanks again,

Cheers,
Max


--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------D06704EAF15A4D888B58E0E9 Content-Type: image/png; name="eemlkaeepgealfoc.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="eemlkaeepgealfoc.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------D06704EAF15A4D888B58E0E9-- --------------66B72031CA31C3C5A74B1276-- From nobody Tue Nov 19 13:49:02 2019 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 35DCF1208E1 for ; Tue, 19 Nov 2019 13:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD4NiONOEXiP for ; Tue, 19 Nov 2019 13:48:57 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 41F051208F0 for ; Tue, 19 Nov 2019 13:48:57 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id k15so25096187lja.3 for ; Tue, 19 Nov 2019 13:48:57 -0800 (PST) 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=AR/zF3MjdEN8pi+UjbSlDX66sZINppfnlc5o9+h/xyE=; b=U2c80qNU4rwDjoHmWKIsfPG9+qFWgpzujlW7MdDZ9W+avx04MG8CmdZh4Qwp9KWdRx VYekZBrpIu9hHm4yo7FJgIOOlltotixAQ22qNbYIKSyFPUkunZjgUTJYzb/ePR+0QDzJ 7cGly4okZugnMCpEt/8uhbg7NrBkXzYDo3ALgMKdSZZiNnZUWHyq1dbEcUTEfMYWGB/I CRUlWuWWHdapY3QTDgEobn0YxXH+WTqy0jnbpr/l4xCFivigpTBD/Mn0D9gUMgWWgQQb /AOoqTfOMYyqKNZChRWj/nv1OWlp/5yARCVRGlF/kfGN/rzWGatrM25ocM8I2hFUbzMF lqQg== 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=AR/zF3MjdEN8pi+UjbSlDX66sZINppfnlc5o9+h/xyE=; b=Nb2JvdvOnF2pZYpbEID7S8Nbdrg3K57OjzGjBC6SBhb6pi1omTBIslqUun7as8duKQ nft3BUPi2LQzCSatjGHrxIRIgspqhRtFiOmglYk7XLnCMQIT3WY9jPjYKXem8sKg7IR4 MlrgPN97UqHr9L8nvWXbmzIlD6SKXlwUTM3q6MmQZpAl1WF6Eu5DblS0/LZy8bw59fCu tANj8CDIRiQ0DJPFmQCOkgyqJVI3/iGTA4BP5jwTWbF9zoG+saZtfmh+rNl4Q179RMQe 2z5PFp4jzFOMYstuecaKiWwURwsb0D6TucfrFFd+KRlOPh5RqfcSQ7uaqPwEO8xljypA Gg4A== X-Gm-Message-State: APjAAAXU7roxSiGYfwyyexRwVOgmOUm3Z9WthJCYH71rIVhuJpJvC9Qp jLRnpFaL2l7fgdZjhmf2WHqp9jBJBZsiltszNIb/8g== X-Google-Smtp-Source: APXvYqzrDkentk5b77p8VXMgGZ/N5vJmV36GdXzuwW4riLjTAndpbCJDbyY1lPtop6d99JybJI7RquNkmTCNqwjMIzI= X-Received: by 2002:a2e:864f:: with SMTP id i15mr5591758ljj.29.1574200135266; Tue, 19 Nov 2019 13:48:55 -0800 (PST) MIME-Version: 1.0 References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> In-Reply-To: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> From: Eric Rescorla Date: Tue, 19 Nov 2019 13:48:18 -0800 Message-ID: To: "Dr. Pala" Cc: IETF SecDispatch Content-Type: multipart/related; boundary="000000000000de68290597ba0710" Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( 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, 19 Nov 2019 21:49:00 -0000 --000000000000de68290597ba0710 Content-Type: multipart/alternative; boundary="000000000000de68280597ba070f" --000000000000de68280597ba070f Content-Type: text/plain; charset="UTF-8" Hi Max, My point is not that it's technically difficult for the clients to add support for composite crypto. Clearly we could do so. My point is rather that at a high level there are two kinds of upgrades of algorithms in an authentication system: - Upgrading to more secure algorithms - Upgrading to algorithms which are better in some other way (e.g., speed, size, etc.) With the second kind of upgrade, you get immediate benefit because your signatures are faster or whatever, but with the first kind of upgrade, you get benefit when you deprecate the old algorithm. As long as you still trust the old algorithm, then the system isn't getting much benefit from the existence of the new algorithm because the attacker just attacks the old one and you'll still accept it. For that reason, you need to do a two step process: 1. Introduce the new algorithm and try to get it to be ubiquitous. 2. Stop trusting the old algorithm. In a system like the Web, you can only do (2) once there is almost no use of the old algorithm, otherwise you cause breakage. This, of course, is what we did with SHA-1 and it took a really long time. We're currently doing it with TLS 1.0 and 1.1 and we have to carefully watch the statistics to cabin the amount of breakage. So, when we look at composite crypto and the Web, we need to ask: are we prepared to introduce some specific set of composite algorithms, put them in the CABF BRs and eventually require that the CAs use them and refuse to honor their certificates if they do not. I do not believe that we are anywhere near that stage, both due to the maturity of the algorithms (aside from hash signatures) and the performance (mostly size) of those algorithms. But until we are prepared to do that, then defining the protocol syntax doesn't really help that much. This isn't to say that I don't think that it's useful to have PQ algorithms in some other context (e.g., code signing) but for those contexts, I'm not sure the right move is composite signatures rather than just to transition wholesale to hash signatures, which we have confidence in. -Ekr On Tue, Nov 19, 2019 at 6:18 AM Dr. Pala wrote: > Hi Eric, all, > > I am sorry I had quite a hard time to understand the questions/comments > today, however, I would like to properly address the raised concerns/points. > > *Clients / Software Updates Comment:* > > I wanted to understand your questions/comments about the need to update > clients and that would never happen. > > Could you please elaborate on this point ? > > It is my understanding that we do have to update our crypto libraries when > we want to support a new algorithm, and that is what we are talking about. > Any time we add a new algorithm, the software needs to be updated - but I > do not see why this is a problem specific for this solution. ALL of the > approaches will need software updates (exactly as we did for TLS 1.3). > > Personally, I think that Composite Crypto is also interesting from this > point of view since updating the crypto layer will enable its use without > the need to change protocols or application behavior. From an > application-development point of view, IMHO, it is a very intriguing > approach. > > *SHA-1 Transition:* > > One of your comments, if I am not mistaken, was about comparing one of the > possible solutions to the problem (Composite Crypto) with the SHA-1 > transitioning period - how, in your opinion, is that transition process > related to the specifics of the proposal ? > > Again, I am sorry I could not understand the questions clearly (normal > language barrier issues :D), but I hope I can address your concerns on the > list. > > Thanks again, > > Cheers, > Max > > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > --000000000000de68280597ba070f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Max,

My point is not that= it's technically difficult for the clients to add support for composit= e crypto. Clearly we could do so.

My point is rath= er that at a high level there are two kinds of upgrades of algorithms in an= authentication system:

- Upgrading to more se= cure algorithms
- Upgrading to algorithms which are better in som= e other way (e.g., speed, size, etc.)

With the sec= ond kind of upgrade, you get immediate benefit because your signatures are = faster or whatever, but with the first kind of upgrade, you get benefit whe= n you deprecate the old algorithm. As long as you still trust the old algor= ithm, then the system isn't getting much benefit from the existence of = the new algorithm because the attacker just attacks the old one and you'= ;ll still accept it. For that reason, you need to do a two step process:

1. Introduce the new algorithm and try to get it to = be ubiquitous.
2. Stop trusting the old algorithm.

=
In a system like the Web, you can only do (2) once there is almo= st no use of the old algorithm, otherwise you cause breakage. This, of cour= se, is what we did with SHA-1 and it took a really long time. We're cur= rently doing it with TLS 1.0 and 1.1 and we have to carefully watch the sta= tistics to cabin the amount of breakage.

So, when = we look at composite crypto and the Web, we need to ask: are we prepared to= introduce some specific set of composite algorithms, put them in the CABF = BRs and eventually require that the CAs use them and refuse to honor their = certificates if they do not. I do not believe that we are anywhere near tha= t stage, both due to the maturity of the algorithms (aside from hash signat= ures) and the performance (mostly size) of those algorithms. But until we a= re prepared to do that, then defining the protocol syntax doesn't reall= y help that much.

This isn't to say that I don= 't think that it's useful to have PQ algorithms in some other conte= xt (e.g., code signing) but for those contexts, I'm not sure the right = move is composite signatures rather than just to transition wholesale to ha= sh signatures, which we have confidence in.

-Ekr


On Tue, Nov 19, 2019 at 6:18 AM Dr. Pala <madwolf@openca.org> wrote:
=20 =20 =20

Hi Eric, all,

I am sorry I had quite a hard time to understand the questions/comments today, however, I would like to properly address the raised concerns/points.

Clients / Software Updates Comment:

I wanted to understand your questions/comments about the need to update clients and that would never happen.

Could you please elaborate on this point ?

It is my understanding that we do have to update our crypto libraries when we want to support a new algorithm, and that is what we are talking about. Any time we add a new algorithm, the software needs to be updated - but I do not see why this is a problem specific for this solution. ALL of the approaches will need software updates (exactly as we did for TLS 1.3).

Personally, I think that Composite Crypto is also interesting from this point of view since updating the crypto layer will enable its use without the need to change protocols or application behavior. From an application-development point of view, IMHO, it is a very intriguing approach.

SHA-1 Transition:

One of your comments, if I am not mistaken, was about comparing one of the possible solutions to the problem (Composite Crypto) with the SHA-1 transitioning period - how, in your opinion, is that transition process related to the specifics of the proposal ?

Again, I am sorry I could not understand the questions clearly (normal language barrier issues :D), but I hope I can address your concerns on the list.

Thanks again,

Cheers,
Max


--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--000000000000de68280597ba070f-- --000000000000de68290597ba0710 Content-Type: image/png; name="eemlkaeepgealfoc.png" Content-Disposition: inline; filename="eemlkaeepgealfoc.png" Content-Transfer-Encoding: base64 Content-ID: <16e8599906849784e911> X-Attachment-Id: 16e8599906849784e911 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --000000000000de68290597ba0710-- From nobody Tue Nov 19 17:33:32 2019 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 9A6B4120930 for ; Tue, 19 Nov 2019 17:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 dJYgho5mNc5L for ; Tue, 19 Nov 2019 17:33:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AD612092A for ; Tue, 19 Nov 2019 17:33:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77209BE53; Wed, 20 Nov 2019 01:33:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AWb2tLhRy5e; Wed, 20 Nov 2019 01:33:26 +0000 (GMT) Received: from [31.133.152.38] (dhcp-9826.meeting.ietf.org [31.133.152.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCC92BE3E; Wed, 20 Nov 2019 01:33:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1574213606; bh=vVArbFzPpkrXS9jXSZtf1fyq9abrsQICpgGrcSa3q84=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=I4HYLADWBgdpG+04eWrhZk04z11us6CJZXSBt2fWZwdDmPpcr9ZpndJM2QN07Xcas zBNTKHZJwBWg+Vd5BsbdukdIwZecXG1tiazj/+bca2syU9miqnDA+/TH61CAqKH8Fr t9hDF97ASTlvya933S6VzQ/VPG2zqYE5dNlgncYE= To: Eric Rescorla , "Dr. Pala" Cc: IETF SecDispatch References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> Date: Wed, 20 Nov 2019 01:33:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fyClckCQMSegK9Z0b1vTcRapJyugKCYeO" Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( 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, 20 Nov 2019 01:33:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fyClckCQMSegK9Z0b1vTcRapJyugKCYeO Content-Type: multipart/mixed; boundary="h3j0RyZat8vq0Z1gNGg6Z3rkzqOZJN2Xu"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , "Dr. Pala" Cc: IETF SecDispatch Message-ID: <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> In-Reply-To: --h3j0RyZat8vq0Z1gNGg6Z3rkzqOZJN2Xu Content-Type: multipart/mixed; boundary="------------8713502B1B7D7E0651F1D0C6" Content-Language: en-US This is a multi-part message in MIME format. --------------8713502B1B7D7E0651F1D0C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/11/2019 21:48, Eric Rescorla wrote: > But until we are prepared to do that, then defining the > protocol syntax doesn't really help that much. +1 Sometimes waiting a bit is better:-) S. --------------8713502B1B7D7E0651F1D0C6 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------8713502B1B7D7E0651F1D0C6-- --h3j0RyZat8vq0Z1gNGg6Z3rkzqOZJN2Xu-- --fyClckCQMSegK9Z0b1vTcRapJyugKCYeO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3Ul94ACgkQWrL68XsX K+qeJQ/9ECmhn6f3pd1mVGs8N3/kguSxYodZzYejuis4aXsdukjpenBLtBNCHD8L yfi1iK/SankGdxY9dOiXXNFKruy3qJuJonAXZUBppUHPHVE6YW8LQjmwLqfx1Tpc 9ikTHMrUwK8TnX9H9EqnKuQ+OP47hBZER4v/1fmaPweut9+UfjGZbqAQs4HCjCD5 0HeMkmajDKt9iARhzm43dD385iCBFMlJwkIQgGBAlX1Pk/SMSxKaV8JrVV3ir9pj ETVqzLrfupCMrkTEgTp4fosON6EmlkELOcf+EKcc0ASZ60qOVkN+9NoPkp5FNFJ4 c8CiCChFgPseT7tUmLOQ7kfVdqxD1X96wKQDYX+QMvfdiCSO8c/RWJ7dwUeTn4Kn CuGWyBMk43iYWK6pw2Roo232WbxOnP0DMWzwxpmLvq7fWjonJofgTTzNJDN8hgpm B4h7+6CV2F6VcmCyVEZljKxgb2Q20jy28IKJUsyVv2qNTk1QU13n0bXnmVkWrPC4 GH4A0M1pNCMpRXNvrj8CAYwr6tGXKU7geHUV+tAe8a9OD/+l4Z2euCRl4tFRThyB DhNYfdoBKFAhAGX5VHEWwzR6LU50qE5JxezJIiJgaOiG3SKxz7KPlRfnO/l107a5 7lV3M7YrnmTBwGbFi3P5slvsFxxbTj3KoDWhQsjbyfQzr92iov0= =CCcd -----END PGP SIGNATURE----- --fyClckCQMSegK9Z0b1vTcRapJyugKCYeO-- From nobody Tue Nov 19 20:34:28 2019 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 A2F2D1201E0; Tue, 19 Nov 2019 20:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 bSs7_9HRivD2; Tue, 19 Nov 2019 20:34:20 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on061f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::61f]) (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 45C24120143; Tue, 19 Nov 2019 20:34:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UWGeVF3tJh568SJywj/5PMn4xRo2tCgNw9dSyL77UByOvtMBblp/2U0B20v+lFVD2vw9rfxYqjNI1/oeILRLXeACpIn5VEdt+ydLqk9UV3TNNmwqgrc8Z39IN1hs2EsGUnfkesZD/CVWrw29KW+znMBHahnEF+V0nSrCvPWVFbBDjxyV7SQesr0ybLa3cuG9vcfOgaaCuBUPWYK4fJJxF0n+jdTz6gDuzULdVJWAj4WU6WIN5jomZ87WfSqb/YAyMM36ASQ27MclYEZMz3+cYJQtIT6hnqzFFSryeMn1ZtoHAqrZUOAEz8A5jV/XqTRZ0KwDoXZF2pwyBEcyYpgACQ== 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=eKkdlM1991WvkVBuRB9H3CXetuxum8OPhq3dSlQrPXI=; b=mn3B8QZUKVCSTspLr8YEFbCeb+mw8lluVIqxHODJkspJyMvfCXBNP3Vnrt7d9wgI5Ms4F0hd366p1tUDt4S6i3nSJQ5xEaNc2pp23DzWwuYgUXbdBdJ7iThkT6Zs4fMY6XzFG7D6dIa3+lby1hKTmfQDkBUmELqRT7irqtVdiw7OZopsN5crEbfpAM4+QZWI+ZqeirU7UtzbGSWV8a8G/O4Pb2HYjZgAkd3UUZKOFz8jc2yWa3H2NXi4je3X1+lwd2/b13SgTcxnY83xb1VF/Wtj27OtE/Iolk3/QmmuCMiT8cxsBlyOLFAOFM0f8OQbFmiXsk7wZ2AyK9YBv+Q5Dg== 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=eKkdlM1991WvkVBuRB9H3CXetuxum8OPhq3dSlQrPXI=; b=ZDJwhdOy3sw0rKkD1qunncNduLcg9gGP6Y7qX5/C0Sp52tgI/FUMIoZaDAsfyKp9hNyP6cYEPPmq15kmiJEBxQRZATgOA1hJ+gGl5RCvTUD+/k7iYJuS3QBn+wqhucAmTUVTQM8FEjZOGwImpRZchxE25UKfcq1zo7npqyyEfPI= Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB3936.eurprd07.prod.outlook.com (52.134.28.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Wed, 20 Nov 2019 04:34:18 +0000 Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2474.015; Wed, 20 Nov 2019 04:34:18 +0000 From: Francesca Palombini To: "saag@ietf.org" , "secdispatch@ietf.org" CC: "Dr. Pala" , Nick Sullivan , Justin Richer , Joachim Fabini , Brian Campbell Thread-Topic: SECDISPATCH WG Summary from IETF 106 Thread-Index: AQHVn1vFDxHCv1ors0i+tXiIXiWbjg== Date: Wed, 20 Nov 2019 04:34:17 +0000 Message-ID: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [2001:67c:370:128:686f:cddf:6958:2afd] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cecbbc79-a465-40e8-69ad-08d76d72e7ea x-ms-traffictypediagnostic: VI1PR07MB3936: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(396003)(136003)(376002)(199004)(189003)(54906003)(99286004)(25786009)(102836004)(71190400001)(71200400001)(110136005)(33656002)(316002)(8936002)(81166006)(81156014)(66476007)(14454004)(966005)(186003)(66946007)(66446008)(5660300002)(2501003)(66556008)(8676002)(478600001)(64756008)(14444005)(256004)(36756003)(6436002)(2616005)(7736002)(6116002)(6486002)(2906002)(6506007)(4326008)(486006)(44832011)(86362001)(476003)(6512007)(54896002)(6306002)(66574012)(76116006)(46003)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3936; H:VI1PR07MB5469.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BFZHgjM6ayFcyxLiJ1niHK09qEKcaisMu3U5P7joaZ6nAqZFnb6qIafD00V2UW0wuXx9/Ux9KheY5R+WtfpGayaXkhYdA0fwg7RamEkt/Crfbcv7i/4Md22WfbIR/BqbFrSm6BYYso1OeKxAAOtpQfO9eVzBQd/ZnlWmQCUDPkw2H3KPlz0nEyTdPoDiCk78g8/wTolS7Q6VZjdH5WPQnQAHTJpncvjRkWRIW5ANCmmg9oTwQqS2lCnzniArie+wrsaeSIu/RMwEQuiNUIPPkhBNO8ql7je6ORYhUItG40A3mKxOG2u0c7BP0WhsfpYKkurZmzaP7iiDQrf0NoMLtoW4GWXMMX9OOkr+AkuBkBS5V4IG+6uCNi6lY/qolkE0dOA94RQ1xvuCfU8d+jdbIEM4nORkRShzWLobpNKas6jWM6GMiU0Rz687KoB/STJ0x4k1wODTp+4lkBZLgrlbYREGYb3h152Of2PAw7j9uBQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3088D69816164A749CBC4A9345E46C15ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cecbbc79-a465-40e8-69ad-08d76d72e7ea X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 04:34:17.9444 (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: mh7yYZxM6HE8npz5jjDbsPn4wJFk44Tcy/mUbXK6+4dtZHAA5MIA4njSsd/RTjFp56xwmzGORRtCoy/Uj4KFsRZlQavhTqD69ts/zDaFIWFLzicutJTrDblJ9EPccziP X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3936 Archived-At: Subject: [Secdispatch] SECDISPATCH WG Summary from IETF 106 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, 20 Nov 2019 04:34:23 -0000 --_000_3088D69816164A749CBC4A9345E46C15ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFNFQ0RJU1BBVENIIFdHIG1ldCBvbiBUdWVzZGF5IE5vdmVtYmVyIDE5LiAgVGhlIGFnZW5k YSBpdGVtcyB3ZXJlIGRpc3BhdGNoZWQgYXMgZm9sbG93czoNCg0KKDEpIFByb2JsZW0gc3RhdGVt ZW50IGZvciBwb3N0LXF1YW50dW0gbXVsdGktYWxnb3JpdGhtIFBLSSAoTWF4IFBhbGEpDQpkcmFm dHM6ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wcS1wa2l4LXByb2Js ZW0tc3RhdGVtZW50Lw0KICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1vdW5zd29ydGgtcHEtY29tcG9zaXRlLXNpZ3MvDQotLT4gZGlzcGF0Y2ggdG8gTEFNUFMg V0cgKGNvbmZpcm0gb24gbWFpbGluZyBsaXN0KQ0KDQooMikgT0NTUHYyIC0gSW1wcm92aW5nIE9D U1AgUmVzcG9uc2VzIChNYXggUGFsYSkNCkxBTVBTICYgUEtJWCBkaXNjdXNzaW9uczoNCkRyYWZ0 OiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbGEtb2NzcHYyLTAwDQotLT4g Y3JlYXRlIGEgQm9GIGZvciBzbWFsbCBmb2N1c2VkIFdHDQoNCigzKSBQcml2YWN5IFBhc3MgUHJv dG9jb2wgKE5pY2sgU3VsbGl2YW4pDQpkcmFmdHM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXByaXZhY3ktcGFzcy8NCi0tPiB3b3JrIG9uIGNoYXJ0ZXIgdGV4dCB0aGVu IEJvRiBmb3Igc21hbGwgZm9jdXNlZCBXRw0KDQooNCkgSFRUUCBSZXF1ZXN0IHNpZ25pbmcgKEp1 c3RpbiBSaWNoZXIpDQpkcmFmdDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNh dmFnZS1odHRwLXNpZ25hdHVyZXMNCi0tPiBkaXNwYXRjaGVkIHRvIEhUVFBCSVMgV0cNCg0KKDUp IENvbW11bmljYXRpb24gTmV0d29yayBQZXJzcGVjdGl2ZSBvbiBNYWx3YXJlIExpZmVjeWNsZSAo Sm9hY2hpbSBGYWJpbmkpDQpkcmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZmFiaW5pLXNtYXJ0LW1hbHdhcmUtbGlmZWN5Y2xlLw0KLS0+IGNoZWNrIHRoZSBJQUIg cHJvamVjdCAodGFsayB0byBUZWQpDQoNCig2KSBTZWN1cmluZyBwcm90b2NvbHMgYmV0d2VlbiBw cm94aWVzIGFuZCBiYWNrZW5kIChIVFRQPykgc2VydmVycyAoQnJpYW4gQ2FtcGJlbGwpDQpkcmFm dDogTG9va2luZyBmb3Igc3VwcG9ydC9jb250cmlidXRvcnMsIG5vIGRyYWZ0IHlldA0KLS0+IG5l ZWRzIGRyYWZ0DQoNCkRldGFpbGVkIG1pbnV0ZXMgd2lsbCBiZSBjb21pbmcgaW4gdGhlIG5leHQg Y291cGxlIG9mIHdlZWtzLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg== --_000_3088D69816164A749CBC4A9345E46C15ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIFNFQ0RJU1BBVENIIFdHIG1ldCBvbiBUdWVzZGF5IE5v dmVtYmVyIDE5LiZuYnNwOyBUaGUgYWdlbmRhIGl0ZW1zIHdlcmUgZGlzcGF0Y2hlZCBhcyBmb2xs b3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDEpIFByb2Js ZW0gc3RhdGVtZW50IGZvciBwb3N0LXF1YW50dW0gbXVsdGktYWxnb3JpdGhtIFBLSSAoTWF4IFBh bGEpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0czombmJzcDsgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHEtcGtpeC1wcm9ibGVtLXN0YXRlbWVudC88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vdW5z d29ydGgtcHEtY29tcG9zaXRlLXNpZ3MvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tJmd0OyBkaXNwYXRjaCB0byBMQU1Q UyBXRyAoY29uZmlybSBvbiBtYWlsaW5nIGxpc3QpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4oMikgT0NTUHYyIC0gSW1wcm92aW5nIE9DU1AgUmVzcG9uc2VzIChN YXggUGFsYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TEFNUFMgJmFtcDsgUEtJWCBkaXNjdXNzaW9uczog PG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+RHJhZnQ6Jm5ic3A7IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1wYWxhLW9jc3B2Mi0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLSZndDsgY3JlYXRl IGEgQm9GIGZvciBzbWFsbCBmb2N1c2VkIFdHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDMpIFByaXZhY3kgUGFzcyBQcm90b2NvbCAoTmljayBT dWxsaXZhbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0czogaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHJpdmFjeS1wYXNzLzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4tLSZndDsgd29yayBvbiBjaGFydGVyIHRleHQgdGhlbiBCb0YgZm9yIHNtYWxsIGZvY3VzZWQg V0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPig0KSBIVFRQIFJl cXVlc3Qgc2lnbmluZyAoSnVzdGluIFJpY2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PmRyYWZ0OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2F2YWdlLWh0dHAtc2ln bmF0dXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLSZndDsgZGlzcGF0Y2hlZCB0byBIVFRQQklTIFdH PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4oNSkgQ29tbXVuaWNh dGlvbiBOZXR3b3JrIFBlcnNwZWN0aXZlIG9uIE1hbHdhcmUgTGlmZWN5Y2xlIChKb2FjaGltIEZh YmluaSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0OiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYWJpbmktc21hcnQtbWFsd2FyZS1saWZlY3ljbGUvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPi0tJmd0OyBjaGVjayB0aGUgSUFCIHByb2plY3QgKHRhbGsgdG8gVGVk KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDYpIFNlY3VyaW5n IHByb3RvY29scyBiZXR3ZWVuIHByb3hpZXMgYW5kIGJhY2tlbmQgKEhUVFA/KSBzZXJ2ZXJzIChC cmlhbiBDYW1wYmVsbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ZHJhZnQ6IExvb2tpbmcgZm9yIHN1cHBv cnQvY29udHJpYnV0b3JzLCBubyBkcmFmdCB5ZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS0mZ3Q7IG5l ZWRzIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZXRh aWxlZCBtaW51dGVzIHdpbGwgYmUgY29taW5nIGluIHRoZSBuZXh0IGNvdXBsZSBvZiB3ZWVrcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8YnI+DQpG cmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_3088D69816164A749CBC4A9345E46C15ericssoncom_-- From nobody Tue Nov 19 21:08:12 2019 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 71A9A120A8E for ; Tue, 19 Nov 2019 21:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cloudflare.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 AWPjVmK4FKEU for ; Tue, 19 Nov 2019 21:08:06 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 4FDA1120840 for ; Tue, 19 Nov 2019 21:08:06 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id x21so15988513vsp.6 for ; Tue, 19 Nov 2019 21:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f+S4nbEgxNrqD4+Ld/z2ike+T8WepUOA7o9ydQtOaJQ=; b=pqMiHxl6CmKZ8lgnDPFzTscJwuZPixwDC2xq4k8gGL9cJ3dlXTbfGPs43SLQIMCjkK Dv9acoPBQH6M9Iw4KV1Bf4GmqsdnbOA+7f5qW8HrVHqgjkZJy8Da9LaDFc7TVJIJkzEh 8lsUeyISMATtWO6VL4CZFCTBx/4sxqu56AtaI= 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=f+S4nbEgxNrqD4+Ld/z2ike+T8WepUOA7o9ydQtOaJQ=; b=KTy6bUUk41gOmo3lsUgfK0G2tRDEdafaBjKrKQ2T/OAnR7nFrn3DRb7DJgdeJ4QFoS w0wlMoxodFriVXDCTpd21PNL9c2MQp+IJLcLoUzRdxLQ55JEnUeUjwcQ2dYfCQpV9QZE dXUoTmYe6khYSyaaSHNYaGeI013tsghdrR83Z3Pk/LBCw2+eD+fqSxNpu6iCY0klqXwT 9Qyk0KUJJrIvtzAMDL913GqdRJXEAa87Q8++YLFomhCwUqBk8lH+RtMVQODY3dSXi2vj scCtYl5+VNEhph3lIiubwifXAYkZAG8paqbsbdJchp7136f3wg23cTkgg2SmuOXak3jg yyMw== X-Gm-Message-State: APjAAAWTO4umqyLgkzgbuTohBfPqc7Bvi3dXqwXKFEHwFiz9nce1lWIu HcQubQrV29D5avPbgCDcCwszsuJjKlV01nJL8xJn1Q== X-Google-Smtp-Source: APXvYqy7baKdti40rAZWDbVfNheltYSCG5XORLXZmXVZPmU95NzXjwlFKAUhnN5kgh0tePP78ltdsqyoSj2eDTXO5SM= X-Received: by 2002:a67:5d02:: with SMTP id r2mr425906vsb.212.1574226484978; Tue, 19 Nov 2019 21:08:04 -0800 (PST) MIME-Version: 1.0 References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> In-Reply-To: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> From: Nick Sullivan Date: Wed, 20 Nov 2019 13:07:48 +0800 Message-ID: To: "Dr. Pala" Cc: IETF SecDispatch , Tim Hollebeek Content-Type: multipart/related; boundary="0000000000006fcc220597c02a02" Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) 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, 20 Nov 2019 05:08:11 -0000 --0000000000006fcc220597c02a02 Content-Type: multipart/alternative; boundary="0000000000006fcc1f0597c02a01" --0000000000006fcc1f0597c02a01 Content-Type: text/plain; charset="UTF-8" Hi Max, Thanks for your clarification. I now understand the work is aimed at optimizing the number of signatures by the CA's OCSP responder and the number of bytes of unique OCSP data. Currently, the number of OCSP signatures the CA needs to do is linear in the number of active certificates. This proposal changes this so that the number of signatures is linear in the number of revocations of active certificates. It's conceptually similar to NSEC in that way: it's a cover proposal in which the artifacts are constant size, but require a linear number signatures in the size of the revocation set. Contrast this with CRLs, which require a constant number of signatures, but are linear in the size of the revocation set. So maybe the goals could be better phrased in terms of *lowering the cost of generating compared to OCSP and distributing compared to CRLs*. This proposal implies a middle-ground PKI deployment that has enough revocations for CRL to be inefficient but not enough to cause the negative space of the serial number to be of the same order as the number of certificates. It would be great to see examples of PKIs that motivate this optimization, which is why I suggested that data could help. I should also note that while this proposal reduces the number of OCSP signatures (which can be on the order of 104 signatures for 2-year certs), the impact is less dramatic for CAs that issue shorter-lived certs. For example, Let's Encrypt only signs around 13 OCSP responses for each of their 3-month certificates. Nick On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala wrote: > Hi Nick, all, > > at the end of the second presentation on lowering the costs of revocation, > if I am not mistaken, your question/comment (Nick) was about the fact that > Cloudflare hosts / serve most of the cached OCSP responses and that the > system does not have issues. > > I am not sure if this comment is pertinent to what we are trying to solve > here... let me elaborate a bit more. > > The work we have been doing around the proposed topic of work is aimed at *lowering > the cost of generating and distributing these large volumes of signed data* > when there is actually no need for that. By optimizing the protocol to > provide range responses (or other methods, if we decide to go with a > different approaches), we can reduce the number of signatures needed from a > CA and their distribution - very expensive operations. > > In other words, the proposal is *not aimed at fixing any caching issues* > because, as you noticed in your comment, that works just fine. The proposal > at hand, instead, is about fixing a problem that CAs are facing today - > high costs of deploying and running such systems. > > On the other hand, your comment made me think about the caching service > you mentioned and its associated costs. > > Is it a service for which your company charge CAs ? If so, would you be > able to share what are currently the costs incurred by CAs to leverage your > service ? (I totally understand if you are not willing to - after all, this > is usually the secret sauce :D) > > Last but not least, I also would like to point out that optimizing the > revocation can also help open-source communities, small companies, > universities, non-profit, etc. by enabling them to deploy cost-efficient > systems that can provide good quality of service using less resources > (computational, storage, network). > > Please let me know, > > Cheers, > Max > > P.S.: If we could combine this idea with OCSP over DNS, we could really > provide access to revocation technology for everybody, not just who can > afford the price. Unfortunately we know how that discussion went, and I > still think it is a very evident mistake not doing it (I am still working > on this in my spare time - I think it is of enormous value for emerging > countries to have access to cheap secure technologies and, in my opinion, > IETF is dropping / has dropped the ball on this for not-so-honorable > reasons, I suspect...). I hope We can fix it in the open-source community. > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > --0000000000006fcc1f0597c02a01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Max,

Thanks for your clarification. = I now understand the work is aimed at optimizing the number of signatures b= y the CA's OCSP responder and the number of bytes of unique OCSP data.<= /div>

Currently, the number of OCSP signatures the = CA needs to do is linear in the number of active certificates. This proposa= l changes this so that the number of signatures is linear in the number of = revocations of active certificates. It's conceptually similar to NSEC i= n that way: it's a cover proposal in which the artifacts are constant s= ize, but require a linear number signatures in the size of the revocation s= et. Contrast this with CRLs, which require a constant number of signatures,= but are linear in the size of the revocation set. So maybe the goals could= be better phrased in terms of=C2=A0lowering the cost of= =C2=A0generating=C2=A0compared to= OCSP and=C2=A0distributing=C2=A0= compared to CRLs.

This proposal implies a = middle-ground PKI deployment that has enough revocations for CRL to be inef= ficient but not enough to cause the negative space of the serial number to = be of the same order as the number of certificates. It would be great to se= e examples of PKIs that motivate this optimization, which is why I suggeste= d that data could help.

I should = also note that while this proposal reduces the number of OCSP signatures (w= hich can be on the order of 104 signatures for 2-year certs), the impact is= less dramatic for CAs that issue shorter-lived certs. For example, Let'= ;s Encrypt only signs around 13 OCSP responses for each of their 3-month ce= rtificates.

Nick

On Tue, Nov 19, 2019 at 9:11= PM Dr. Pala <madwolf@openca.org> wrote:
=20 =20 =20

Hi Nick, all,

at the end of the second presentation on lowering the costs of revocation, if I am not mistaken, your question/comment (Nick) was about the fact that Cloudflare hosts / serve most of the cached OCSP responses and that the system does not have issues.

I am not sure if this comment is pertinent to what we are trying to solve here... let me elaborate a bit more.

The work we have been doing around the proposed topic of work is aimed at lowering the cost of generating and distribu= ting these large volumes of signed data when there is actually no need for that. By optimizing the protocol to provide range responses (or other methods, if we decide to go with a different approaches), we can reduce the number of signatures needed from a CA and their distribution - very expensive operations.

In other words, the proposal is not aimed at fixing any caching issues because, as you noticed in your comment, that works just fine. The proposal at hand, instead, is about fixing a problem that CAs are facing today - high costs of deploying and running such systems.

On the other hand, your comment made me think about the caching service you mentioned and its associated costs.

Is it a service for which your company charge CAs ? If so, would you be able to share what are currently the costs incurred by CAs to leverage your service ? (I totally understand if you are not willing to - after all, this is usually the secret sauce :D)

Last but not least, I also would like to point out that optimizing the revocation can also help open-source communities, small companies, universities, non-profit, etc. by enabling them to deploy cost-efficient systems that can provide good quality of service using less resources (computational, storage, network).

Please let me know,

Cheers,
Max

P.S.: If we could combine this idea with OCSP over DNS, we could really provide access to revocation technology for everybody, not just who can afford the price. Unfortunately we know how that discussion went, and I still think it is a very evident mistake not doing it=C2=A0 (I am still working on this in my spare time - I think it is of enormous value for emerging countries to have access to cheap secure technologies and, in my opinion, IETF is dropping / has dropped the ball on this for not-so-honorable reasons, I suspect...). I hope We can fix it in the open-source community.

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--0000000000006fcc1f0597c02a01-- --0000000000006fcc220597c02a02 Content-Type: image/png; name="dhmacjdifkefaoin.png" Content-Disposition: inline; filename="dhmacjdifkefaoin.png" Content-Transfer-Encoding: base64 Content-ID: <16e86f7aa328fa0c7f81> X-Attachment-Id: 16e86f7aa328fa0c7f81 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --0000000000006fcc220597c02a02-- From nobody Tue Nov 19 22:47:14 2019 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 9B4F8120125 for ; Tue, 19 Nov 2019 22:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 0hOkwBC36N4Z for ; Tue, 19 Nov 2019 22:47:08 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id B5EAE120255 for ; Tue, 19 Nov 2019 22:47:08 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 85BA537413B5; Wed, 20 Nov 2019 06:47:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iGVWyEOjdX4m; Wed, 20 Nov 2019 01:47:07 -0500 (EST) Received: from Maxs-MacBook-Pro-2.local (unknown [101.100.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 1000537408D6; Wed, 20 Nov 2019 01:47:05 -0500 (EST) To: Nick Sullivan Cc: IETF SecDispatch , Tim Hollebeek References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> From: "Dr. Pala" Message-ID: <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> Date: Wed, 20 Nov 2019 14:47:03 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1524C40E438E389B70EB9251" Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) 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, 20 Nov 2019 06:47:10 -0000 This is a multi-part message in MIME format. --------------1524C40E438E389B70EB9251 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Nick, thanks for the reply. My comments are inline... On 11/20/19 1:07 PM, Nick Sullivan wrote: > Hi Max, > > Thanks for your clarification. I now understand the work is aimed at > optimizing the number of signatures by the CA's OCSP responder and the > number of bytes of unique OCSP data. > Yes, that is correct. The other optimization is about the ability to provide responses for the whole chain in a single message. > Currently, the number of OCSP signatures the CA needs to do is linear > in the number of active certificates. This proposal changes this so > that the number of signatures is linear in the number of revocations > of active certificates. It's conceptually similar to NSEC in that way: > it's a cover proposal in which the artifacts are constant size, but > require a linear number signatures in the size of the revocation set. > Contrast this with CRLs, which require a constant number of > signatures, but are linear in the size of the revocation set. So maybe > the goals could be better phrased in terms of _/lowering the cost of > /*generating*/ compared to OCSP and /*distributing*/ compared to CRLs/_. > I am not sure I follow. In PKIs, today, we use both mechanisms. This is because usually the CRLs are used as a backup mechanism for OCSP - we also need to support both because of Certification Policies (exactly as in the Internet PKI environment), therefore it is not a choice :D The proposed approach can be used to (a) limit the amount of data that needs to be generated, stored, and transferred when pre-computing responses, and (b) to compute all responses and serve them from memory - even small instances without any hardware acceleration could achieve reasonable performances (also for shorter validity periods in responses). > This proposal implies a middle-ground PKI deployment that has enough > revocations for CRL to be inefficient but not enough to cause the > negative space of the serial number to be of the same order as the > number of certificates. It would be great to see examples of PKIs that > motivate this optimization, which is why I suggested that data could help. Technically, you are correct. If we could predict the size of CRLs, we could potentially try to understand what that threshold is. However, as I explained in the presentation, the size is fairly unpredictable. That is why we primarily use OCSP today. > > I should also note that while this proposal reduces the number of OCSP > signatures (which can be on the order of 104 signatures for 2-year > certs), the impact is less dramatic for CAs that issue shorter-lived > certs. For example, Let's Encrypt only signs around 13 OCSP responses > for each of their 3-month certificates. That is correct, the impact is less with short-lived certificates because in those environment, the population of active certificates is usually smaller. If the population is still large, you still have the same problem. You mention that your OCSP responses have a 7 days validity, correct ? My question is: which considerations went into deciding such a large validity period for the OCSP responses (7 days) ? Maybe costs considerations drove the decision ? From a security standpoint, such long validity periods blinds clients from detecting revocation that might happen during the 7-days validity period (the problem is worse now with the deployment of OCSP stapling because clients do not fetch fresh responses at connect time, AFAIK, if stapling is supported). I would expect that few minutes validity windows or maybe few hours would be a better choice - but how much does that cost to Let's Encrypt ? The Cable industry has used certificates, for few decades now, for different purposes - as a hardware certification tool and to secure our networks - in this environment, the typical life-span of a certificate is many years (up to 20) and it is tied to the envisioned life-span of the device (no renewal). As you can see, in our environment, CRLs will never be an option and OCSP simply costs too much (for an infrastructure that, over all, has an active population of several hundreds million of active certificates - we might be even beyond that with just the three OpenCable, PacketCable, and DOCSIS). Ultimately, we need to work on the solution so that we can have our vendors to integrate it in their products, like CableModes, that are going to be deployed (and provide internet connectivity) for hundreds of millions of households for the next 10 to 20 years. We need to lower the security risks associated with the infrastructures that brings Internet to many of us - revocation is important to prevent possible compromises to go undetected. I think that everybody who has Cable should support this work that is going to directly impact them for many years. Cheers, Max P.S.: I also have other personal motivations for this work. I think that this is also the right thing to do for non-technical reasons - I come from the OpenSource world that so much has give for the success of the Internet but where there is no money. More efficient technologies could be leveraged by communities around the world who deserve good security but costs get in the way. I know it is not a technical detail, but I think we shall always try to have these considerations in our minds - making the world a better place and less wasteful (energy) is an amendable goal in general and emerging communities could really benefit from our work. > On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala > wrote: > > Hi Nick, all, > > at the end of the second presentation on lowering the costs of > revocation, if I am not mistaken, your question/comment (Nick) was > about the fact that Cloudflare hosts / serve most of the cached > OCSP responses and that the system does not have issues. > > I am not sure if this comment is pertinent to what we are trying > to solve here... let me elaborate a bit more. > > The work we have been doing around the proposed topic of work is > aimed at /_lowering the cost of *generating* and *distributing* > these large volumes of signed data_/ when there is actually no > need for that. By optimizing the protocol to provide range > responses (or other methods, if we decide to go with a different > approaches), we can reduce the number of signatures needed from a > CA and their distribution - very expensive operations. > > In other words, the proposal is /_not aimed at fixing any caching > issues_/ because, as you noticed in your comment, that works just > fine. The proposal at hand, instead, is about fixing a problem > that CAs are facing today - high costs of deploying and running > such systems. > > On the other hand, your comment made me think about the caching > service you mentioned and its associated costs. > > Is it a service for which your company charge CAs ? If so, would > you be able to share what are currently the costs incurred by CAs > to leverage your service ? (I totally understand if you are not > willing to - after all, this is usually the secret sauce :D) > > Last but not least, I also would like to point out that optimizing > the revocation can also help open-source communities, small > companies, universities, non-profit, etc. by enabling them to > deploy cost-efficient systems that can provide good quality of > service using less resources (computational, storage, network). > > Please let me know, > > Cheers, > Max > > P.S.: If we could combine this idea with OCSP over DNS, we could > really provide access to revocation technology for everybody, not > just who can afford the price. Unfortunately we know how that > discussion went, and I still think it is a very evident mistake > not doing it  (I am still working on this in my spare time - I > think it is of enormous value for emerging countries to have > access to cheap secure technologies and, in my opinion, IETF is > dropping / has dropped the ball on this for not-so-honorable > reasons, I suspect...). I hope We can fix it in the open-source > community. > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------1524C40E438E389B70EB9251 Content-Type: multipart/related; boundary="------------C08ABA80CBCA04EFA6AD612E" --------------C08ABA80CBCA04EFA6AD612E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Nick,

thanks for the reply. My comments are inline...

On 11/20/19 1:07 PM, Nick Sullivan wrote:
Hi Max,

Thanks for your clarification. I now understand the work is aimed at optimizing the number of signatures by the CA's OCSP responder and the number of bytes of unique OCSP data.

Yes, that is correct. The other optimization is about the ability to provide responses for the whole chain in a single message.
Currently, the number of OCSP signatures the CA needs to do is linear in the number of active certificates. This proposal changes this so that the number of signatures is linear in the number of revocations of active certificates. It's conceptually similar to NSEC in that way: it's a cover proposal in which the artifacts are constant size, but require a linear number signatures in the size of the revocation set. Contrast this with CRLs, which require a constant number of signatures, but are linear in the size of the revocation set. So maybe the goals could be better phrased in terms of lowering the cost of generating compared to OCSP and distributing compared to CRLs.

I am not sure I follow. In PKIs, today, we use both mechanisms. This is because usually the CRLs are used as a backup mechanism for OCSP - we also need to support both because of Certification Policies (exactly as in the Internet PKI environment), therefore it is not a choice :D The proposed approach can be used to (a) limit the amount of data that needs to be generated, stored, and transferred when pre-computing responses, and (b) to compute all responses and serve them from memory - even small instances without any hardware acceleration could achieve reasonable performances (also for shorter validity periods in responses).
This proposal implies a middle-ground PKI deployment that has enough revocations for CRL to be inefficient but not enough to cause the negative space of the serial number to be of the same order as the number of certificates. It would be great to see examples of PKIs that motivate this optimization, which is why I suggested that data could help.

Technically, you are correct. If we could predict the size of CRLs, we could potentially try to understand what that threshold is. However, as I explained in the presentation, the size is fairly unpredictable. That is why we primarily use OCSP today.


I should also note that while this proposal reduces the number of OCSP signatures (which can be on the order of 104 signatures for 2-year certs), the impact is less dramatic for CAs that issue shorter-lived certs. For example, Let's Encrypt only signs around 13 OCSP responses for each of their 3-month certificates.

That is correct, the impact is less with short-lived certificates because in those environment, the population of active certificates is usually smaller. If the population is still large, you still have the same problem.

You mention that your OCSP responses have a 7 days validity, correct ? My question is: which considerations went into deciding such a large validity period for the OCSP responses (7 days) ? Maybe costs considerations drove the decision ? From a security standpoint, such long validity periods blinds clients from detecting revocation that might happen during the 7-days validity period (the problem is worse now with the deployment of OCSP stapling because clients do not fetch fresh responses at connect time, AFAIK, if stapling is supported). I would expect that few minutes validity windows or maybe few hours would be a better choice - but how much does that cost to Let's Encrypt ?

The Cable industry has used certificates, for few decades now, for different purposes - as a hardware certification tool and to secure our networks - in this environment, the typical life-span of a certificate is many years (up to 20) and it is tied to the envisioned life-span of the device (no renewal). As you can see, in our environment, CRLs will never be an option and OCSP simply costs too much (for an infrastructure that, over all, has an active population of several hundreds million of active certificates - we might be even beyond that with just the three OpenCable, PacketCable, and DOCSIS).

Ultimately, we need to work on the solution so that we can have our vendors to integrate it in their products, like CableModes, that are going to be deployed (and provide internet connectivity) for hundreds of millions of households for the next 10 to 20 years. We need to lower the security risks associated with the infrastructures that brings Internet to many of us - revocation is important to prevent possible compromises to go undetected. I think that everybody who has Cable should support this work that is going to directly impact them for many years.

Cheers,
Max

P.S.: I also have other personal motivations for this work. I think that this is also the right thing to do for non-technical reasons - I come from the OpenSource world that so much has give for the success of the Internet but where there is no money. More efficient technologies could be leveraged by communities around the world who deserve good security but costs get in the way. I know it is not a technical detail, but I think we shall always try to have these considerations in our minds - making the world a better place and less wasteful (energy) is an amendable goal in general and emerging communities could really benefit from our work.


On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <madwolf@openca.org> wrote:

Hi Nick, all,

at the end of the second presentation on lowering the costs of revocation, if I am not mistaken, your question/comment (Nick) was about the fact that Cloudflare hosts / serve most of the cached OCSP responses and that the system does not have issues.

I am not sure if this comment is pertinent to what we are trying to solve here... let me elaborate a bit more.

The work we have been doing around the proposed topic of work is aimed at lowering the cost of generating and distributing these large volumes of signed data when there is actually no need for that. By optimizing the protocol to provide range responses (or other methods, if we decide to go with a different approaches), we can reduce the number of signatures needed from a CA and their distribution - very expensive operations.

In other words, the proposal is not aimed at fixing any caching issues because, as you noticed in your comment, that works just fine. The proposal at hand, instead, is about fixing a problem that CAs are facing today - high costs of deploying and running such systems.

On the other hand, your comment made me think about the caching service you mentioned and its associated costs.

Is it a service for which your company charge CAs ? If so, would you be able to share what are currently the costs incurred by CAs to leverage your service ? (I totally understand if you are not willing to - after all, this is usually the secret sauce :D)

Last but not least, I also would like to point out that optimizing the revocation can also help open-source communities, small companies, universities, non-profit, etc. by enabling them to deploy cost-efficient systems that can provide good quality of service using less resources (computational, storage, network).

Please let me know,

Cheers,
Max

P.S.: If we could combine this idea with OCSP over DNS, we could really provide access to revocation technology for everybody, not just who can afford the price. Unfortunately we know how that discussion went, and I still think it is a very evident mistake not doing it  (I am still working on this in my spare time - I think it is of enormous value for emerging countries to have access to cheap secure technologies and, in my opinion, IETF is dropping / has dropped the ball on this for not-so-honorable reasons, I suspect...). I hope We can fix it in the open-source community.

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------C08ABA80CBCA04EFA6AD612E Content-Type: image/png; name="dhmacjdifkefaoin.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dhmacjdifkefaoin.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------C08ABA80CBCA04EFA6AD612E Content-Type: image/png; name="ijeffbhlgncflbab.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ijeffbhlgncflbab.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------C08ABA80CBCA04EFA6AD612E-- --------------1524C40E438E389B70EB9251-- From nobody Tue Nov 19 23:22:29 2019 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 3709112085C for ; Tue, 19 Nov 2019 23:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.437 X-Spam-Level: * X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 5gU_U-O1Wl8y for ; Tue, 19 Nov 2019 23:22:25 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id DB2A7120856 for ; Tue, 19 Nov 2019 23:22:25 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 8905F37413DF; Wed, 20 Nov 2019 07:22:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y0b1brM-RDlT; Wed, 20 Nov 2019 02:22:24 -0500 (EST) Received: from Maxs-MacBook-Pro-2.local (unknown [101.100.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id E48A737408D6; Wed, 20 Nov 2019 02:22:23 -0500 (EST) To: Stephen Farrell , Eric Rescorla Cc: IETF SecDispatch References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> From: "Dr. Pala" Message-ID: <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> Date: Wed, 20 Nov 2019 15:22:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------1791D35CBED82C14CAB1F794" Content-Language: en-US Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( 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, 20 Nov 2019 07:22:27 -0000 This is a multi-part message in MIME format. --------------1791D35CBED82C14CAB1F794 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, all, I just want to add a quick consideration here. We work with hardware that is deployed at the customer's homes, offices, etc. When planning for our innovation to hit the networks, we need to plan years in advance - this is not something we deal with in universities, but, I assure you, it requires a lot more planning than you might be used to. I do disagree with the fact that what we are doing doesn't really help that much. The proposed approach does provide a solution that, although it might not be optimized, it works. Other solutions might come afterwards that provide (probably more complex) optimized paths (maybe TLS 2.0 will be quite different because its design will cover the new design requirements). Another possibility is that application specific would define their own code points: the "CompositCrypto" algorithm OID will allow to combine any algorithms. Applications can then define their own code-points that they accept by simply defining the appropriate OID for the algorithm identifer. For example, when and if TLS, for example, would like to define its own combination of algorithms, a set of specific code-points can be defined for that. Coming back to delaying the work - I think it is wrong and I would like to understand why you think it is a good idea. * We have the interest of an industry sector * Plus, there has been support on the MLs for not delaying the work any further * Plus, this work is presented by a /_*committed set of Companies that have real interest in using this technology*_/ to protect the PKIs that secure the internet connectivity for hundreds of millions of users. * Plus, the problem has been already addressed in other institutions (ITU-T) - thus indicating that IETF is falling behind on this topic. * Plus, we are in contact with NIST to possibly collaborate on real-world deployment of QRC by using Composite Crypto. I think that blocking or stalling this work within the IETF does not make any sense. If there are other competing/compelling proposals, please let's talk about that and find a common solution we standardize. I personally do not think that "Sometimes waiting is a little better" is a valid argument. If you have technical reasons as to why this work shall not proceed, please let us know, we want to deploy the best solution possible. Thanks, Max On 11/20/19 9:33 AM, Stephen Farrell wrote: > > On 19/11/2019 21:48, Eric Rescorla wrote: >> But until we are prepared to do that, then defining the >> protocol syntax doesn't really help that much. > +1 > > Sometimes waiting a bit is better:-) > > S. -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------1791D35CBED82C14CAB1F794 Content-Type: multipart/related; boundary="------------5B0A95165EEA2437F2A36885" --------------5B0A95165EEA2437F2A36885 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Stephen, all,

I just want to add a quick consideration here. We work with hardware that is deployed at the customer's homes, offices, etc. When planning for our innovation to hit the networks, we need to plan years in advance - this is not something we deal with in universities, but, I assure you, it requires a lot more planning than you might be used to.

I do disagree with the fact that what we are doing doesn't really help that much. The proposed approach does provide a solution that, although it might not be optimized, it works.

Other solutions might come afterwards that provide (probably more complex) optimized paths (maybe TLS 2.0 will be quite different because its design will cover the new design requirements). Another possibility is that application specific would define their own code points: the "CompositCrypto" algorithm OID will allow to combine any algorithms. Applications can then define their own code-points that they accept by simply defining the appropriate OID for the algorithm identifer. For example, when and if TLS, for example, would like to define its own combination of algorithms, a set of specific code-points can be defined for that.

Coming back to delaying the work - I think it is wrong and I would like to understand why you think it is a good idea.

  • We have the interest of an industry sector
  • Plus, there has been support on the MLs for not delaying the work any further
  • Plus, this work is presented by a committed set of Companies that have real interest in using this technology to protect the PKIs that secure the internet connectivity for hundreds of millions of users.
  • Plus, the problem has been already addressed in other institutions (ITU-T) - thus indicating that IETF is falling behind on this topic.
  • Plus, we are in contact with NIST to possibly collaborate on real-world deployment of QRC by using Composite Crypto.

I think that blocking or stalling this work within the IETF does not make any sense. If there are other competing/compelling proposals, please let's talk about that and find a common solution we standardize. I personally do not think that "Sometimes waiting is a little better" is a valid argument.

If you have technical reasons as to why this work shall not proceed, please let us know, we want to deploy the best solution possible.

Thanks,
Max


On 11/20/19 9:33 AM, Stephen Farrell wrote:

On 19/11/2019 21:48, Eric Rescorla wrote:

But until we are prepared to do that, then defining the
protocol syntax doesn't really help that much.

+1

Sometimes waiting a bit is better:-)

S.
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------5B0A95165EEA2437F2A36885 Content-Type: image/png; name="boabagnjfjdllcaj.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="boabagnjfjdllcaj.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------5B0A95165EEA2437F2A36885-- --------------1791D35CBED82C14CAB1F794-- From nobody Tue Nov 19 23:30:00 2019 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 471EE120871 for ; Tue, 19 Nov 2019 23:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShAys2Eea6ct for ; Tue, 19 Nov 2019 23:29:55 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 CBF39120866 for ; Tue, 19 Nov 2019 23:29:54 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id l14so12636236lfh.10 for ; Tue, 19 Nov 2019 23:29:54 -0800 (PST) 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=GBc9L3bW0wlHMmn9vPNtIz9YlXzbIWguNVYzxBoitP0=; b=ufse8clAHop3zKQNZHZqaldZjMeUs/fQpoNU2cUiChRhlzafkO+axczvSlFSBS2hrN CkZBi7hhRIV5Ppbk5haAgHPqQMW6I9PURvwCHTs/B2OIwIXO0rvqACsEAmY6Bb9m7qB2 YSDieAX9UM2a6XmgGk3FVq5XcRkkmcHME1qrP+nl2Gfilk0GW9k6E/aiNJXpGKC13S9/ 0fo9yqE1xeXZrXOXHJHI+z4cbAff4dGwjc89qGjPFsTL7WjYHpCH/UokKJquvVThnwbh oVon+2zTNxPlu0WZqvdy4Hx6XhtXaA6okH3vJhhOONGh8HqbmtVMZCe9NClFOWa1a3I2 n2bg== 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=GBc9L3bW0wlHMmn9vPNtIz9YlXzbIWguNVYzxBoitP0=; b=f6mhnfsHQgx0QMJdcoH6dh5c+Xpn+P/tZRmJd4R2kFInNBV6oB3OvGxwGkmQaz9SMr DNd4XJgPBXmWf5yXXwcjihbZHuXsJzC1xmFyvK1pLTkLJ6OO+S+osKgsSkC/IMXMabyz kFRLqmDMzOP8Sq2ecfIeFCFWYqqRz6T6jJaYyHUeVLP9cFHo59Z9kMrp5Ip+Gouy8sig BCTzNW91K5uD0nXwt9ZJhCmx8yUrsgjmaHt3Obn6M4eLCg7N8gKz6/t1TRut+3L1M/Rn Y+jK7s7yVAij34T2RUT3JQsQwmiJVzOxEchKLpYgjd8KE1BeN/Bya1/4MMKL445uwqab I1uA== X-Gm-Message-State: APjAAAXZR1s5m8D8krypwZUlFadsL99rif+kyObSBgNHEBq2eKZPCohG qq7YMECj0e++ShLz09jors+lH7KBTTaNt6VvoV6PzA== X-Google-Smtp-Source: APXvYqyMkvg7xJw5CT3S6HSa/Ztz3P2jtRuThFIyXn2hEPf+OGUvsRt7khyNuXs+79NpkzE9ZR/0neFrw4mEWBBjPWQ= X-Received: by 2002:a19:f107:: with SMTP id p7mr1471411lfh.91.1574234993010; Tue, 19 Nov 2019 23:29:53 -0800 (PST) MIME-Version: 1.0 References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> In-Reply-To: <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> From: Eric Rescorla Date: Tue, 19 Nov 2019 23:29:16 -0800 Message-ID: To: "Dr. Pala" Cc: Stephen Farrell , IETF SecDispatch Content-Type: multipart/related; boundary="0000000000008da7fe0597c22560" Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( 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, 20 Nov 2019 07:29:57 -0000 --0000000000008da7fe0597c22560 Content-Type: multipart/alternative; boundary="0000000000008da7fc0597c2255f" --0000000000008da7fc0597c2255f Content-Type: text/plain; charset="UTF-8" Hi Max, I'm not presently taking a position on whether this work should proceed in a general matter; I haven't thought it through enough to have an opinion. What I was trying to say in the meeting is that I don't think this is probably to be of much use in the WebPKI at this time. -Ekr On Tue, Nov 19, 2019 at 11:22 PM Dr. Pala wrote: > Hi Stephen, all, > > I just want to add a quick consideration here. We work with hardware that > is deployed at the customer's homes, offices, etc. When planning for our > innovation to hit the networks, we need to plan years in advance - this is > not something we deal with in universities, but, I assure you, it requires > a lot more planning than you might be used to. > > I do disagree with the fact that what we are doing doesn't really help > that much. The proposed approach does provide a solution that, although it > might not be optimized, it works. > > Other solutions might come afterwards that provide (probably more complex) > optimized paths (maybe TLS 2.0 will be quite different because its design > will cover the new design requirements). Another possibility is that > application specific would define their own code points: the > "CompositCrypto" algorithm OID will allow to combine any algorithms. > Applications can then define their own code-points that they accept by > simply defining the appropriate OID for the algorithm identifer. For > example, when and if TLS, for example, would like to define its own > combination of algorithms, a set of specific code-points can be defined for > that. > > Coming back to delaying the work - I think it is wrong and I would like to > understand why you think it is a good idea. > > - We have the interest of an industry sector > - Plus, there has been support on the MLs for not delaying the work > any further > - Plus, this work is presented by a *committed set of Companies that > have real interest in using this technology* to protect the PKIs that > secure the internet connectivity for hundreds of millions of users. > - Plus, the problem has been already addressed in other institutions > (ITU-T) - thus indicating that IETF is falling behind on this topic. > - Plus, we are in contact with NIST to possibly collaborate on > real-world deployment of QRC by using Composite Crypto. > > I think that blocking or stalling this work within the IETF does not make > any sense. If there are other competing/compelling proposals, please let's > talk about that and find a common solution we standardize. I personally do > not think that "Sometimes waiting is a little better" is a valid argument. > > If you have technical reasons as to why this work shall not proceed, > please let us know, we want to deploy the best solution possible. > > Thanks, > Max > > > On 11/20/19 9:33 AM, Stephen Farrell wrote: > > On 19/11/2019 21:48, Eric Rescorla wrote: > > But until we are prepared to do that, then defining the > protocol syntax doesn't really help that much. > > +1 > > Sometimes waiting a bit is better:-) > > S. > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > --0000000000008da7fc0597c2255f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Max,

I'm not presentl= y taking a position on whether this work should proceed in a general matter= ; I haven't thought it through enough to have an opinion.
What I was trying to say in the meeting is that I don't thi= nk this is probably to be of much use in the WebPKI at this time.
=

-Ekr


On Tue, Nov 19, 2019 at 11:22 PM Dr.= Pala <madwolf@o= penca.org> wrote:
=20 =20 =20

Hi Stephen, all,

I just want to add a quick consideration here. We work with hardware that is deployed at the customer's homes, offices, etc. When planning for our innovation to hit the networks, we need to plan years in advance - this is not something we deal with in universities, but, I assure you, it requires a lot more planning than you might be used to.

I do disagree with the fact that what we are doing doesn't reall= y help that much. The proposed approach does provide a solution that, although it might not be optimized, it works.

Other solutions might come afterwards that provide (probably more complex) optimized paths (maybe TLS 2.0 will be quite different because its design will cover the new design requirements). Another possibility is that application specific would define their own code points: the "CompositCrypto" algorithm OID w= ill allow to combine any algorithms. Applications can then define their own code-points that they accept by simply defining the appropriate OID for the algorithm identifer. For example, when and if TLS, for example, would like to define its own combination of algorithms, a set of specific code-points can be defined for that.

Coming back to delaying the work - I think it is wrong and I would like to understand why you think it is a good idea.

  • We have the interest of an industry sector
  • Plus, there has been support on the MLs for not delaying the work any further
  • Plus, this work is presented by a committed set of Companies that have real interest in using this technology to protect the PKIs that secure the internet connectivity for hundreds of millions of users.
  • Plus, the problem has been already addressed in other institutions (ITU-T) - thus indicating that IETF is falling behind on this topic.
  • Plus, we are in contact with NIST to possibly collaborate on real-world deployment of QRC by using Composite Crypto.

I think that blocking or stalling this work within the IETF does not make any sense. If there are other competing/compelling proposals, please let's talk about that and find a common solutio= n we standardize. I personally do not think that "Sometimes waitin= g is a little better" is a valid argument.

If you have technical reasons as to why this work shall not proceed, please let us know, we want to deploy the best solution possible.

Thanks,
Max


On 11/20/19 9:33 AM, Stephen Farrell wrote:
On 19/11/2019 21:48, Eric Rescorla wrote:

But until we are prepared to do that, then defining the
protocol syntax doesn't really help that much.

+1

Sometimes waiting a bit is better:-)

S.
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--0000000000008da7fc0597c2255f-- --0000000000008da7fe0597c22560 Content-Type: image/png; name="boabagnjfjdllcaj.png" Content-Disposition: inline; filename="boabagnjfjdllcaj.png" Content-Transfer-Encoding: base64 Content-ID: <16e87b457a848bf71f71> X-Attachment-Id: 16e87b457a848bf71f71 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --0000000000008da7fe0597c22560-- From nobody Tue Nov 19 23:34:11 2019 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 BF0C31209AF for ; Tue, 19 Nov 2019 23:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 wrkvEwvnYOuA for ; Tue, 19 Nov 2019 23:34:04 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 23D731209B8 for ; Tue, 19 Nov 2019 23:34:04 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAK7Tc13000580; Wed, 20 Nov 2019 07:33:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=WmniXZMSQY9mfcMz6jBgiGWOmcEv3vDtKEF87s98Al8=; b=fJ1xYpQZKTCJ33MQLiJ0nOZKe1CUqgQT5Czrl3+P9SD/dxrp6TGvY4BW1+4FCJ3tQeFw yYtZfMXSqPnCOcyHK1dn+6UsZOlbvmhtiy25drAhh2QfkM18knvAY2HdiLFW5+eu/n/M QJXiiuR5uxs3hlwdTJoXDe7yDGQaFz3sfrClIhJ2m6Bq0PsUxRlner4GVr2ckkdVaQRU H4vHr5EogQOZ717r8lS42w37tg3gR3ttpUiD7QRxW9B4FkkJggmVuX9wCV26e6yTbq+6 9asgyZEN1Oy2Y1vEd/rtImWKDSB65kol67OMtiz3Y+h3JSkJljhcH0N+k9Zz/L+CIQEC Ag== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2wagp8988n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 07:33:57 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAK7WIOr021134; Wed, 20 Nov 2019 02:33:56 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wadaxp8ws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 02:33:56 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 02:33:55 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 20 Nov 2019 02:33:55 -0500 From: "Salz, Rich" To: Eric Rescorla , "Dr. Pala" CC: IETF SecDispatch , Stephen Farrell Thread-Topic: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( Thread-Index: AQHVnuRl9glb3sIxbE6JXWJaNFmyNqeTXCQAgAA+3QCAAGGHAIAAAe4AgACHZQA= Date: Wed, 20 Nov 2019 07:33:55 +0000 Message-ID: <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.219.184] Content-Type: multipart/alternative; boundary="_000_95B2FAB766FA44F284F8FA23737AA38Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=882 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911200068 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_01:2019-11-15,2019-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=857 malwarescore=0 impostorscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 suspectscore=0 phishscore=0 mlxscore=0 bulkscore=0 clxscore=1011 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200067 Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( 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, 20 Nov 2019 07:34:09 -0000 --_000_95B2FAB766FA44F284F8FA23737AA38Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2hhdCBJIHdhcyB0cnlpbmcgdG8gc2F5IGluIHRoZSBtZWV0aW5nIGlzIHRoYXQgSSBk b24ndCB0aGluayB0aGlzIGlzIHByb2JhYmx5IHRvIGJlIG9mIG11Y2ggdXNlIGluIHRoZSBXZWJQ S0kgYXQgdGhpcyB0aW1lLg0KDQpJIGFncmVlIHdpdGggdGhhdC4NCg0KQnV0IG9mIGNvdXJzZSB0 aGF04oCZcyBub3QgYSDigJx2ZXRv4oCdIG9uIGRvaW5nIHRoaXMgd29yaywgd2hpY2ggT0YgQ09V UlNFIHlvdSBhcmUgbm90IHNheWluZy4NCg== --_000_95B2FAB766FA44F284F8FA23737AA38Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <86297CAA7B6E534CA3DD9FE61F022C90@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTI0MzUwNDE3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczozNDE1OTQ0MDggLTE1MzM0OTIzNTYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTE2Njc0NDA4NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM1MTI0OTI0ODt9DQpAbGlzdCBs MTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+V2hh dCBJIHdhcyB0cnlpbmcgdG8gc2F5IGluIHRoZSBtZWV0aW5nIGlzIHRoYXQgSSBkb24ndCB0aGlu ayB0aGlzIGlzIHByb2JhYmx5IHRvIGJlIG9mIG11Y2ggdXNlIGluIHRoZSBXZWJQS0kgYXQgdGhp cyB0aW1lLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggdGhhdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IG9mIGNvdXJzZSB0aGF04oCZcyBub3QgYSDigJx2 ZXRv4oCdIG9uIGRvaW5nIHRoaXMgd29yaywgd2hpY2ggT0YgQ09VUlNFIHlvdSBhcmUgbm90IHNh eWluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_95B2FAB766FA44F284F8FA23737AA38Fakamaicom_-- From nobody Tue Nov 19 23:38:10 2019 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 B5BB6120C69 for ; Tue, 19 Nov 2019 23:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ2alAPYFKea for ; Tue, 19 Nov 2019 23:38:02 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 A711C120AA9 for ; Tue, 19 Nov 2019 23:37:54 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id f16so217703lfm.3 for ; Tue, 19 Nov 2019 23:37:54 -0800 (PST) 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=09Vra0As0AZFKeUZ/WGeTE8GLHnBuhqtgQ3iiqZProY=; b=mO8RACNH2JLdsXbwvTUXlnvJvFhFa+2qW5jjlC0CiqPhzfovJ5iGkc1A4pxc8cEWoT DHxcG9k9WkV0T0HnlTqKc9HlffodS7Q8oQI+eA3L+xTb88sog31++k/oRopWlZaMub8a A4kqmB0hphiLLByYy1htqofeuN0XjC5Hwqw6iiFs20w+Dhm1BiNQOYcbZtNVl4PVmTtg kzN9iIlefEtyggtT4n7eBLPHTz62X49J6U0MF7VVeJUO+8ZWV9b2StRbzMIocyHDrXRs 2tHwenneBwHlzJuHB8PEYJM1bGt0wixL7QrL0dFf74jDPdVUk/nmhrojIbxif5iydwz8 LGSA== 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=09Vra0As0AZFKeUZ/WGeTE8GLHnBuhqtgQ3iiqZProY=; b=jOEfEYF4cYIA2zIZ1Cxk0Ezxx0hcLK10RBgchTuwiM4v/hEY4y8lKBipfeuaDLMSrp 1/rhh6JOD32kTfvYGQrcvwV23tWw9UdG1hQPuj6d0cn+e+G1VFDwnPdTm/E6oeJ4w70V 7LeQ64LaTY8hznalUMaPHv7E5uzHGemZvvEsrF6651bT0vsEQ073nuDvT7hncJ9u/HDP Vi2+yF7GEQ0tdnN6VZohhTk593Ty6tPYQSyMC1Ayl5fRUHsT57b8hLOnIjmEshDY+c45 aqPALEfyMOe3yNV8LUwMxkizvD6mmnrXR897MEdMRt/QXNPmc7QtdBo+OTNMzlPtL253 ic9Q== X-Gm-Message-State: APjAAAVFexabTWwXnMuqDW0cfRJtF8jgwSoCXrSSgSe4vwxFOCODRLA2 DzFN42vUJ7H33sn2MGHgkZHNsp9ZzMCrwSLARxBcR6ja X-Google-Smtp-Source: APXvYqzs3w1FvXg2CRawc5ju77je4IyAUIWltyulXnddgXkt3wuhhJa5RvowtZPFaM5ux17BCYFbFLYu0xCZQS+zhiA= X-Received: by 2002:a19:a410:: with SMTP id q16mr1577503lfc.184.1574235472576; Tue, 19 Nov 2019 23:37:52 -0800 (PST) MIME-Version: 1.0 References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> In-Reply-To: <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> From: Eric Rescorla Date: Tue, 19 Nov 2019 23:37:16 -0800 Message-ID: To: "Salz, Rich" Cc: "Dr. Pala" , IETF SecDispatch , Stephen Farrell Content-Type: multipart/alternative; boundary="00000000000022d5410597c242f7" Archived-At: Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla ( 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, 20 Nov 2019 07:38:08 -0000 --00000000000022d5410597c242f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2019 at 11:34 PM Salz, Rich wrote: > > - What I was trying to say in the meeting is that I don't think this > is probably to be of much use in the WebPKI at this time. > > > > I agree with that. > > > > But of course that=E2=80=99s not a =E2=80=9Cveto=E2=80=9D on doing this w= ork, which OF COURSE you > are not saying. > Agreed. I think the relevant question is if there is enough demand, so just because WebPKI doesn't want it doesn't mean that someone doesn't. -Ekr _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --00000000000022d5410597c242f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 19, 2019 at 11:34 PM Salz= , Rich <rsalz@akamai.com> wro= te:
  • What I was trying to say in the meeting is that I don't think= this is probably to be of much use in the WebPKI at this time.

=C2=A0

I agree with that.

=C2=A0

But of course that=E2=80=99s not a =E2=80=9Cveto=E2= =80=9D on doing this work, which OF COURSE you are not saying.


Agreed. I think the relevant question i= s if there is enough demand, so just because WebPKI doesn't want it doe= sn't mean that someone doesn't.

-Ekr

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--00000000000022d5410597c242f7-- From nobody Tue Nov 26 05:42:53 2019 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 4F8C3120121 for ; Tue, 26 Nov 2019 05:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 INmUjBPusqsK for ; Tue, 26 Nov 2019 05:42:49 -0800 (PST) Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B2412009C for ; Tue, 26 Nov 2019 05:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1574775767; bh=H9FNFy3myCG9ZYfgfhaLuuIR8P9gqdzJJ3n5ORGADgY=; h=From:Message-Id:Content-Type:Subject:Date:To; b=p0qCuNfVOyjMgbAxmcgJHiJH5p7hwwzeca5DdwC7fvDAu0FVzdaW2qtps/Pi1Tiad O3BK+nRNemAbEATKZDZHE/o0kpjbua++oRuITAtmecy4d4jF7PVNp3253m5wfWt6re y/DcJ/AH5iUuLAdoahGIX9xupXucnQjS/PTehYlgLWeTpSrzrVK8KDkyNB5Nv56XMV txNtZnMHkO/EnQOFWkVX9DWxMSe/VcMhkWuKYzgICIEwvY7baDKEOheCOUpgT5Oz4t ydxaO2he5bZzcbQUFKezl3kQAtHIAG9yC1w09Kp3PusMjk9w5bpakp/vxDzgs4wEUS ofuZCR5HudWEA== Received: from [17.234.77.133] (unknown [17.234.77.133]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id ED968C1341; Tue, 26 Nov 2019 13:42:46 +0000 (UTC) From: Carrick Bartle Message-Id: <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E744FC56-9C01-4621-B755-A52D7B54E6F8" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Tue, 26 Nov 2019 05:42:45 -0800 In-Reply-To: <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> Cc: Nick Sullivan , IETF SecDispatch , Tim Hollebeek To: "Dr. Pala" References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> X-Mailer: Apple Mail (2.3594.4.19) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-26_03:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911260123 Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) 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, 26 Nov 2019 13:42:52 -0000 --Apple-Mail=_E744FC56-9C01-4621-B755-A52D7B54E6F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Max, What's the current proposal? The draft = doesn't appear to = contain details beyond the notion of providing ranges and information = about the entire chain, and it doesn't seem to address the issues raised = in the PKIX and LAMPS discussions linked here = . At Apple, we also cache OCSP responses in a compressed form, i.e. in = Bloom filters. Having the option to receive CRLs in a compressed format = like that would definitely be more efficient for us. I'm not convinced = that ranges would be as helpful. CRLs are helpful when someone is = compiling an entire catalog of revoked certificates. OCSP is helpful = when you want to check the revocation status of one particular = certificate. If OCSP is instead a hybrid of these two approaches, this = assumes that the client is going to want data on the other certificates = in the range they receive (many of which won't even exist, since, as = someone commented in the pkix thread, serial numbers are often = (usually?) randomized). I'm not sure how often that additional = revocation information is actually going to be useful to the client. = Statistics on that is the sort of data that would be helpful in = evaluating this proposal. If it turns out, for instance, that providing = ranges ends up saving only, say, 0.1% of OCSP requests, it probably = wouldn't be worth the effort. As for returning revocation data for the entire chain, the question must = be asked: which chain? In some cases, certificates are cross-signed, and = so there is no one chain to provide revocation data for. Is the client = effectively going to delegate finding the best chain to the OCSP = responder? I'm not sure that's in the client's best interest, and I'm = not sure OCSP responders are going to want to bother handling that. Carrick > On Nov 20, 2019, at 2:47 PM, Dr. Pala wrote: >=20 > Hi Nick, >=20 > thanks for the reply. My comments are inline... >=20 > On 11/20/19 1:07 PM, Nick Sullivan wrote: >> Hi Max, >>=20 >> Thanks for your clarification. I now understand the work is aimed at = optimizing the number of signatures by the CA's OCSP responder and the = number of bytes of unique OCSP data. >>=20 > Yes, that is correct. The other optimization is about the ability to = provide responses for the whole chain in a single message. >> Currently, the number of OCSP signatures the CA needs to do is linear = in the number of active certificates. This proposal changes this so that = the number of signatures is linear in the number of revocations of = active certificates. It's conceptually similar to NSEC in that way: it's = a cover proposal in which the artifacts are constant size, but require a = linear number signatures in the size of the revocation set. Contrast = this with CRLs, which require a constant number of signatures, but are = linear in the size of the revocation set. So maybe the goals could be = better phrased in terms of lowering the cost of generating compared to = OCSP and distributing compared to CRLs. >>=20 > I am not sure I follow. In PKIs, today, we use both mechanisms. This = is because usually the CRLs are used as a backup mechanism for OCSP - we = also need to support both because of Certification Policies (exactly as = in the Internet PKI environment), therefore it is not a choice :D The = proposed approach can be used to (a) limit the amount of data that needs = to be generated, stored, and transferred when pre-computing responses, = and (b) to compute all responses and serve them from memory - even small = instances without any hardware acceleration could achieve reasonable = performances (also for shorter validity periods in responses). >> This proposal implies a middle-ground PKI deployment that has enough = revocations for CRL to be inefficient but not enough to cause the = negative space of the serial number to be of the same order as the = number of certificates. It would be great to see examples of PKIs that = motivate this optimization, which is why I suggested that data could = help. > Technically, you are correct. If we could predict the size of CRLs, we = could potentially try to understand what that threshold is. However, as = I explained in the presentation, the size is fairly unpredictable. That = is why we primarily use OCSP today. >=20 >>=20 >> I should also note that while this proposal reduces the number of = OCSP signatures (which can be on the order of 104 signatures for 2-year = certs), the impact is less dramatic for CAs that issue shorter-lived = certs. For example, Let's Encrypt only signs around 13 OCSP responses = for each of their 3-month certificates. > That is correct, the impact is less with short-lived certificates = because in those environment, the population of active certificates is = usually smaller. If the population is still large, you still have the = same problem. >=20 > You mention that your OCSP responses have a 7 days validity, correct ? = My question is: which considerations went into deciding such a large = validity period for the OCSP responses (7 days) ? Maybe costs = considerations drove the decision ? =46rom a security standpoint, such = long validity periods blinds clients from detecting revocation that = might happen during the 7-days validity period (the problem is worse now = with the deployment of OCSP stapling because clients do not fetch fresh = responses at connect time, AFAIK, if stapling is supported). I would = expect that few minutes validity windows or maybe few hours would be a = better choice - but how much does that cost to Let's Encrypt ? >=20 > The Cable industry has used certificates, for few decades now, for = different purposes - as a hardware certification tool and to secure our = networks - in this environment, the typical life-span of a certificate = is many years (up to 20) and it is tied to the envisioned life-span of = the device (no renewal). As you can see, in our environment, CRLs will = never be an option and OCSP simply costs too much (for an infrastructure = that, over all, has an active population of several hundreds million of = active certificates - we might be even beyond that with just the three = OpenCable, PacketCable, and DOCSIS). >=20 > Ultimately, we need to work on the solution so that we can have our = vendors to integrate it in their products, like CableModes, that are = going to be deployed (and provide internet connectivity) for hundreds of = millions of households for the next 10 to 20 years. We need to lower the = security risks associated with the infrastructures that brings Internet = to many of us - revocation is important to prevent possible compromises = to go undetected. I think that everybody who has Cable should support = this work that is going to directly impact them for many years.=20 >=20 > Cheers, > Max >=20 > P.S.: I also have other personal motivations for this work. I think = that this is also the right thing to do for non-technical reasons - I = come from the OpenSource world that so much has give for the success of = the Internet but where there is no money. More efficient technologies = could be leveraged by communities around the world who deserve good = security but costs get in the way. I know it is not a technical detail, = but I think we shall always try to have these considerations in our = minds - making the world a better place and less wasteful (energy) is an = amendable goal in general and emerging communities could really benefit = from our work. >=20 >=20 >=20 >> On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala > wrote: >> Hi Nick, all, >>=20 >> at the end of the second presentation on lowering the costs of = revocation, if I am not mistaken, your question/comment (Nick) was about = the fact that Cloudflare hosts / serve most of the cached OCSP responses = and that the system does not have issues. >>=20 >> I am not sure if this comment is pertinent to what we are trying to = solve here... let me elaborate a bit more. >>=20 >> The work we have been doing around the proposed topic of work is = aimed at lowering the cost of generating and distributing these large = volumes of signed data when there is actually no need for that. By = optimizing the protocol to provide range responses (or other methods, if = we decide to go with a different approaches), we can reduce the number = of signatures needed from a CA and their distribution - very expensive = operations. >>=20 >> In other words, the proposal is not aimed at fixing any caching = issues because, as you noticed in your comment, that works just fine. = The proposal at hand, instead, is about fixing a problem that CAs are = facing today - high costs of deploying and running such systems. >>=20 >> On the other hand, your comment made me think about the caching = service you mentioned and its associated costs.=20 >>=20 >> Is it a service for which your company charge CAs ? If so, would you = be able to share what are currently the costs incurred by CAs to = leverage your service ? (I totally understand if you are not willing to = - after all, this is usually the secret sauce :D) >>=20 >> Last but not least, I also would like to point out that optimizing = the revocation can also help open-source communities, small companies, = universities, non-profit, etc. by enabling them to deploy cost-efficient = systems that can provide good quality of service using less resources = (computational, storage, network). >>=20 >> Please let me know, >>=20 >> Cheers, >> Max >>=20 >> P.S.: If we could combine this idea with OCSP over DNS, we could = really provide access to revocation technology for everybody, not just = who can afford the price. Unfortunately we know how that discussion = went, and I still think it is a very evident mistake not doing it (I am = still working on this in my spare time - I think it is of enormous value = for emerging countries to have access to cheap secure technologies and, = in my opinion, IETF is dropping / has dropped the ball on this for = not-so-honorable reasons, I suspect...). I hope We can fix it in the = open-source community. >>=20 >> --=20 >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> > --=20 > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch = --Apple-Mail=_E744FC56-9C01-4621-B755-A52D7B54E6F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Max,

What's the current proposal? = The draft doesn't appear to contain details beyond the = notion of providing ranges and information about the entire chain, and = it doesn't seem to address the issues raised in the PKIX and LAMPS = discussions linked here.

At Apple, we also cache OCSP responses = in a compressed form, i.e. in Bloom filters. Having the option to = receive CRLs in a compressed format like that would definitely be more = efficient for us. I'm not convinced that ranges would be as helpful. = CRLs are helpful when someone is compiling an entire catalog of revoked = certificates. OCSP is helpful when you want to check the revocation = status of one particular certificate. If OCSP is instead a hybrid of = these two approaches, this assumes that the client is going to want data = on the other certificates in the range they receive (many of which won't = even exist, since, as someone commented in the pkix thread, serial = numbers are often (usually?) randomized). I'm not sure how often that = additional revocation information is actually going to be useful to the = client. Statistics on that is the sort of data that would be helpful in = evaluating this proposal. If it turns out, for instance, that providing = ranges ends up saving only, say, 0.1% of OCSP requests, it probably = wouldn't be worth the effort.

As for returning revocation data for = the entire chain, the question must be asked: which chain? In some = cases, certificates are cross-signed, and so there is no one chain to = provide revocation data for. Is the client effectively going to delegate = finding the best chain to the OCSP responder? I'm not sure that's in the = client's best interest, and I'm not sure OCSP responders are going to = want to bother handling that.

Carrick



On Nov = 20, 2019, at 2:47 PM, Dr. Pala <madwolf@openca.org> wrote:

Hi = Nick,

thanks for the reply. My comments are inline...

On 11/20/19 1:07 PM, Nick Sullivan wrote:
Hi = Max,

Thanks for your = clarification. I now understand the work is aimed at optimizing the = number of signatures by the CA's OCSP responder and the number of bytes = of unique OCSP data.

Yes, that is correct. The other optimization is about the = ability to provide responses for the whole chain in a single = message.
Currently, the number of OCSP signatures the = CA needs to do is linear in the number of active certificates. This = proposal changes this so that the number of signatures is linear in the = number of revocations of active certificates. It's conceptually similar = to NSEC in that way: it's a cover proposal in which the artifacts are = constant size, but require a linear number signatures in the size of the = revocation set. Contrast this with CRLs, which require a constant number = of signatures, but are linear in the size of the revocation set. So = maybe the goals could be better phrased in terms of lowering the cost of generating compared to OCSP = and distributing compared to = CRLs.

I am not sure I follow. In PKIs, today, we use both = mechanisms. This is because usually the CRLs are used as a backup = mechanism for OCSP - we also need to support both because of = Certification Policies (exactly as in the Internet PKI environment), = therefore it is not a choice :D The proposed approach can be used to (a) = limit the amount of data that needs to be generated, stored, and = transferred when pre-computing responses, and (b) to compute all = responses and serve them from memory - even small instances without any = hardware acceleration could achieve reasonable performances (also for = shorter validity periods in responses).
This proposal implies a middle-ground PKI = deployment that has enough revocations for CRL to be inefficient but not = enough to cause the negative space of the serial number to be of the = same order as the number of certificates. It would be great to see = examples of PKIs that motivate this optimization, which is why I = suggested that data could help.

Technically, you are correct. If we could predict the size of = CRLs, we could potentially try to understand what that threshold is. = However, as I explained in the presentation, the size is fairly = unpredictable. That is why we primarily use OCSP today.


I should also note that = while this proposal reduces the number of OCSP signatures (which can be = on the order of 104 signatures for 2-year certs), the impact is less = dramatic for CAs that issue shorter-lived certs. For example, Let's = Encrypt only signs around 13 OCSP responses for each of their 3-month = certificates.

That is correct, the impact is less = with short-lived certificates because in those environment, the = population of active certificates is usually smaller. If the population = is still large, you still have the same problem.

You = mention that your OCSP responses have a 7 days validity, correct ? My = question is: which considerations went into deciding such a large = validity period for the OCSP responses (7 days) ? Maybe costs = considerations drove the decision ? =46rom a security standpoint, such = long validity periods blinds clients from detecting revocation that = might happen during the 7-days validity period (the problem is worse now = with the deployment of OCSP stapling because clients do not fetch fresh = responses at connect time, AFAIK, if stapling is supported). I would = expect that few minutes validity windows or maybe few hours would be a = better choice - but how much does that cost to Let's Encrypt ?

The Cable industry has used certificates, for few = decades now, for different purposes - as a hardware certification tool = and to secure our networks - in this environment, the typical life-span = of a certificate is many years (up to 20) and it is tied to the = envisioned life-span of the device (no renewal). As you can see, in our = environment, CRLs will never be an option and OCSP simply costs too much = (for an infrastructure that, over all, has an active population of = several hundreds million of active certificates - we might be even = beyond that with just the three OpenCable, PacketCable, and = DOCSIS).

Ultimately, we need to work on the solution so that we = can have our vendors to integrate it in their products, like CableModes, = that are going to be deployed (and provide internet connectivity) for = hundreds of millions of households for the next 10 to 20 years. We need = to lower the security risks associated with the infrastructures that = brings Internet to many of us - revocation is important to prevent = possible compromises to go undetected. I think that everybody who has = Cable should support this work that is going to directly impact them for = many years. 

Cheers,
Max

P.S.: I also have other personal = motivations for this work. I think that this is also the right thing to = do for non-technical reasons - I come from the OpenSource world that so = much has give for the success of the Internet but where there is no = money. More efficient technologies could be leveraged by communities = around the world who deserve good security but costs get in the way. I = know it is not a technical detail, but I think we shall always try to = have these considerations in our minds - making the world a better place = and less wasteful (energy) is an amendable goal in general and emerging = communities could really benefit from our work.


On Tue, Nov 19, 2019 at 9:11 PM Dr. = Pala <madwolf@openca.org> wrote:

Hi Nick, all,

at the end of = the second presentation on lowering the costs of revocation, if I am not = mistaken, your question/comment (Nick) was about the fact that = Cloudflare hosts / serve most of the cached OCSP responses and that the = system does not have issues.

I am not sure if this = comment is pertinent to what we are trying to solve here... let me = elaborate a bit more.

The work we have been doing = around the proposed topic of work is aimed at lowering the cost of generating and distributing these large volumes of = signed data when= there is actually no need for that. By optimizing the protocol to = provide range responses (or other methods, if we decide to go with a = different approaches), we can reduce the number of signatures needed = from a CA and their distribution - very expensive operations.

In other words, the proposal is not aimed at fixing any caching issues because, as you noticed in = your comment, that works just fine. The proposal at hand, instead, is = about fixing a problem that CAs are facing today - high costs of = deploying and running such systems.

On the other hand, = your comment made me think about the caching service you mentioned and = its associated costs. 

Is it a service for which your company charge CAs ? If so, = would you be able to share what are currently the costs incurred by CAs = to leverage your service ? (I totally understand if you are not willing = to - after all, this is usually the secret sauce :D)

Last= but not least, I also would like to point out that optimizing the = revocation can also help open-source communities, small companies, = universities, non-profit, etc. by enabling them to deploy cost-efficient = systems that can provide good quality of service using less resources = (computational, storage, network).

Please = let me know,

Cheers,
Max

P.S.: If we could combine this idea with OCSP over DNS, we = could really provide access to revocation technology for everybody, not = just who can afford the price. Unfortunately we know how that discussion = went, and I still think it is a very evident mistake not doing it  = (I am still working on this in my spare time - I think it is of enormous = value for emerging countries to have access to cheap secure technologies = and, in my opinion, IETF is dropping / has dropped the ball on this for = not-so-honorable reasons, I suspect...). I hope We can fix it in the = open-source community.

-- 
Best Regards,
Massimiliano = Pala, Ph.D.
OpenCA Labs Director
<dhmacjdifkefaoin.png>=
-- 
Best Regards,
Massimiliano = Pala, Ph.D.
OpenCA Labs Director
<ijeffbhlgncflbab.png>=
_______________________________________________
Secdispatch mailing = list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

= --Apple-Mail=_E744FC56-9C01-4621-B755-A52D7B54E6F8-- From nobody Tue Nov 26 06:26:36 2019 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 188CC12081E for ; Tue, 26 Nov 2019 06:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ohIv6YA1MMnA for ; Tue, 26 Nov 2019 06:26:32 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 94861120106 for ; Tue, 26 Nov 2019 06:26:31 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id l14so14242320lfh.10 for ; Tue, 26 Nov 2019 06:26:31 -0800 (PST) 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=yUxQdBT5z7VRQC9IKoJfuAI0+0ev3y2Hrao5TbJvVpU=; b=rv1aGeOnRkcXyQsiSfsv2CwbqK3IJ+ewx3BPUWd2ttvSlB6roil6F+VmizHLb+5f9Y CjTQGdPhNilK84o1R3L/XJHHyQW5Z/6tEwZg3wWySrUUHXeOfF19/1DWHNymsR2YTVXl 9scVm2saryKb/KxGS/UnKbpb0c+dkDKcxYdlbSOTBYuMniUQYPzcXCnaX2AzrOJd7RFO 5L9KRSEsqerj0IRpdUc14fmInP+jddsUMIsKXsBynu3VCCgD8Q4+7U0A/HtMlkmoMqy+ W8G65f2TWwZkXQHbSWe3R4bIa9X+kJrtQIad2WlPxnVwT+LaARthboLodhpfafcrazR6 PCCg== 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=yUxQdBT5z7VRQC9IKoJfuAI0+0ev3y2Hrao5TbJvVpU=; b=bSXYTMccLsoZVoGGBLg6fEbNVRjQNE/9XRm6+UefTJDN58pGt3gqYpH3HhtMGqFOVx BrFL4vGm9+RvwkEpaPx3rQUAxf39NpAOsoyaI1HCHRPTl5ZnQxDXKZTVwyuhFRHhaZR6 VGcvnU58ZpiFe6SSX/FZ5uR0V4ivzLUMKq9bgIl2TJvbhnyQCBeSCSz1cpFjROLYcDOO bwIA26HvWQKvWk4vEZQbDCvHPyeBwFOZaLFp+yl0c1IHR00kFBrq2I9NKE4HyMr3nzet sZrMMwW75OVwBp7tXNflU25PDqWu2r6l6ffiYQZ/U3izfSU7gN42qm5E0NXTwEP5FYuZ xqyg== X-Gm-Message-State: APjAAAV62MRGwGSsZHAQxz1qXpPdrVYrmKfNGwXUG3gJTou24jb6aPny F/xOuI60hUNyZukduZl8KVwffCgddpE2s9ZV8yscsg== X-Google-Smtp-Source: APXvYqzM8AmcOgPfcADBV2BRBmvYhMB1/Envw50a67DtmNF4zkigwcpmnYEsirxclHc8ugFdj7lJy064BUvAl1s4htM= X-Received: by 2002:ac2:4422:: with SMTP id w2mr13019946lfl.178.1574778389781; Tue, 26 Nov 2019 06:26:29 -0800 (PST) MIME-Version: 1.0 References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> In-Reply-To: <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> From: Eric Rescorla Date: Tue, 26 Nov 2019 06:25:53 -0800 Message-ID: To: Carrick Bartle Cc: "Dr. Pala" , IETF SecDispatch , Nick Sullivan , Tim Hollebeek Content-Type: multipart/alternative; boundary="00000000000085f659059840aa14" Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) 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, 26 Nov 2019 14:26:35 -0000 --00000000000085f659059840aa14 Content-Type: text/plain; charset="UTF-8" It's probably useful to start with a clear problem statement. if I understood Max's presentation correctly, it's that it's too expensive to compute all the OCSP signatures. I'm not sure I'm persuaded that that's true, as public key signatures are very fast (especially if you use ECDSA), and even the largest public CAs don't actually have that many certificates on the grand scheme of things [0]. However, to the extent to which it is true, it seems like the natural response would be to move to a batch signature scheme, such as the one David Benjamin proposed for TLS [1]. This would have the advantage that it doesn't require any new protocol definition or reasoning, it's just a drop-in for the existing signatures. -Ekr [0] Let's Encrypt has about 10^8 certificates active. [1] https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00 On Tue, Nov 26, 2019 at 5:42 AM Carrick Bartle wrote: > Hi Max, > > What's the current proposal? The draft > doesn't appear to > contain details beyond the notion of providing ranges and information about > the entire chain, and it doesn't seem to address the issues raised in the > PKIX and LAMPS discussions linked here > > . > > At Apple, we also cache OCSP responses in a compressed form, i.e. in Bloom > filters. Having the option to receive CRLs in a compressed format like that > would definitely be more efficient for us. I'm not convinced that ranges > would be as helpful. CRLs are helpful when someone is compiling an entire > catalog of revoked certificates. OCSP is helpful when you want to check the > revocation status of one particular certificate. If OCSP is instead a > hybrid of these two approaches, this assumes that the client is going to > want data on the other certificates in the range they receive (many of > which won't even exist, since, as someone commented in the pkix thread, > serial numbers are often (usually?) randomized). I'm not sure how often > that additional revocation information is actually going to be useful to > the client. Statistics on that is the sort of data that would be helpful in > evaluating this proposal. If it turns out, for instance, that providing > ranges ends up saving only, say, 0.1% of OCSP requests, it probably > wouldn't be worth the effort. > > As for returning revocation data for the entire chain, the question must > be asked: which chain? In some cases, certificates are cross-signed, and so > there is no one chain to provide revocation data for. Is the client > effectively going to delegate finding the best chain to the OCSP responder? > I'm not sure that's in the client's best interest, and I'm not sure OCSP > responders are going to want to bother handling that. > > Carrick > > > > On Nov 20, 2019, at 2:47 PM, Dr. Pala wrote: > > Hi Nick, > > thanks for the reply. My comments are inline... > On 11/20/19 1:07 PM, Nick Sullivan wrote: > > Hi Max, > > Thanks for your clarification. I now understand the work is aimed at > optimizing the number of signatures by the CA's OCSP responder and the > number of bytes of unique OCSP data. > > Yes, that is correct. The other optimization is about the ability to > provide responses for the whole chain in a single message. > > Currently, the number of OCSP signatures the CA needs to do is linear in > the number of active certificates. This proposal changes this so that the > number of signatures is linear in the number of revocations of active > certificates. It's conceptually similar to NSEC in that way: it's a cover > proposal in which the artifacts are constant size, but require a linear > number signatures in the size of the revocation set. Contrast this with > CRLs, which require a constant number of signatures, but are linear in the > size of the revocation set. So maybe the goals could be better phrased in > terms of *lowering the cost of generating compared to OCSP > and distributing compared to CRLs*. > > I am not sure I follow. In PKIs, today, we use both mechanisms. This is > because usually the CRLs are used as a backup mechanism for OCSP - we also > need to support both because of Certification Policies (exactly as in the > Internet PKI environment), therefore it is not a choice :D The proposed > approach can be used to (a) limit the amount of data that needs to be > generated, stored, and transferred when pre-computing responses, and (b) to > compute all responses and serve them from memory - even small instances > without any hardware acceleration could achieve reasonable performances > (also for shorter validity periods in responses). > > This proposal implies a middle-ground PKI deployment that has enough > revocations for CRL to be inefficient but not enough to cause the negative > space of the serial number to be of the same order as the number of > certificates. It would be great to see examples of PKIs that motivate this > optimization, which is why I suggested that data could help. > > Technically, you are correct. If we could predict the size of CRLs, we > could potentially try to understand what that threshold is. However, as I > explained in the presentation, the size is fairly unpredictable. That is > why we primarily use OCSP today. > > > I should also note that while this proposal reduces the number of OCSP > signatures (which can be on the order of 104 signatures for 2-year certs), > the impact is less dramatic for CAs that issue shorter-lived certs. For > example, Let's Encrypt only signs around 13 OCSP responses for each of > their 3-month certificates. > > That is correct, the impact is less with short-lived certificates because > in those environment, the population of active certificates is usually > smaller. If the population is still large, you still have the same problem. > > You mention that your OCSP responses have a 7 days validity, correct ? My > question is: which considerations went into deciding such a large validity > period for the OCSP responses (7 days) ? Maybe costs considerations drove > the decision ? From a security standpoint, such long validity periods > blinds clients from detecting revocation that might happen during the > 7-days validity period (the problem is worse now with the deployment of > OCSP stapling because clients do not fetch fresh responses at connect time, > AFAIK, if stapling is supported). I would expect that few minutes validity > windows or maybe few hours would be a better choice - but how much does > that cost to Let's Encrypt ? > > The Cable industry has used certificates, for few decades now, for > different purposes - as a hardware certification tool and to secure our > networks - in this environment, the typical life-span of a certificate is > many years (up to 20) and it is tied to the envisioned life-span of the > device (no renewal). As you can see, in our environment, CRLs will never be > an option and OCSP simply costs too much (for an infrastructure that, over > all, has an active population of several hundreds million of active > certificates - we might be even beyond that with just the three OpenCable, > PacketCable, and DOCSIS). > > Ultimately, we need to work on the solution so that we can have our > vendors to integrate it in their products, like CableModes, that are going > to be deployed (and provide internet connectivity) for hundreds of millions > of households for the next 10 to 20 years. We need to lower the security > risks associated with the infrastructures that brings Internet to many of > us - revocation is important to prevent possible compromises to go > undetected. I think that everybody who has Cable should support this work > that is going to directly impact them for many years. > > Cheers, > Max > > P.S.: I also have other personal motivations for this work. I think that > this is also the right thing to do for non-technical reasons - I come from > the OpenSource world that so much has give for the success of the Internet > but where there is no money. More efficient technologies could be leveraged > by communities around the world who deserve good security but costs get in > the way. I know it is not a technical detail, but I think we shall always > try to have these considerations in our minds - making the world a better > place and less wasteful (energy) is an amendable goal in general and > emerging communities could really benefit from our work. > > > On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala wrote: > >> Hi Nick, all, >> >> at the end of the second presentation on lowering the costs of >> revocation, if I am not mistaken, your question/comment (Nick) was about >> the fact that Cloudflare hosts / serve most of the cached OCSP responses >> and that the system does not have issues. >> >> I am not sure if this comment is pertinent to what we are trying to solve >> here... let me elaborate a bit more. >> >> The work we have been doing around the proposed topic of work is aimed at >> *lowering the cost of generating and distributing these large volumes >> of signed data* when there is actually no need for that. By optimizing >> the protocol to provide range responses (or other methods, if we decide to >> go with a different approaches), we can reduce the number of signatures >> needed from a CA and their distribution - very expensive operations. >> >> In other words, the proposal is *not aimed at fixing any caching issues* because, >> as you noticed in your comment, that works just fine. The proposal at hand, >> instead, is about fixing a problem that CAs are facing today - high costs >> of deploying and running such systems. >> >> On the other hand, your comment made me think about the caching service >> you mentioned and its associated costs. >> >> Is it a service for which your company charge CAs ? If so, would you be >> able to share what are currently the costs incurred by CAs to leverage your >> service ? (I totally understand if you are not willing to - after all, this >> is usually the secret sauce :D) >> >> Last but not least, I also would like to point out that optimizing the >> revocation can also help open-source communities, small companies, >> universities, non-profit, etc. by enabling them to deploy cost-efficient >> systems that can provide good quality of service using less resources >> (computational, storage, network). >> >> Please let me know, >> >> Cheers, >> Max >> >> P.S.: If we could combine this idea with OCSP over DNS, we could really >> provide access to revocation technology for everybody, not just who can >> afford the price. Unfortunately we know how that discussion went, and I >> still think it is a very evident mistake not doing it (I am still working >> on this in my spare time - I think it is of enormous value for emerging >> countries to have access to cheap secure technologies and, in my opinion, >> IETF is dropping / has dropped the ball on this for not-so-honorable >> reasons, I suspect...). I hope We can fix it in the open-source community. >> -- >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> >> > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > _______________________________________________ > 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 > --00000000000085f659059840aa14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's probably useful to start with a clear proble= m statement. if I understood Max's presentation correctly, it's tha= t it's too expensive to compute all the OCSP signatures.=C2=A0 I'm = not sure I'm persuaded that that's true, as public key signatures a= re very fast (especially if you use ECDSA), and even the largest public CAs= don't actually have that many certificates on the grand scheme of thin= gs [0]. However, to the extent to which it is true, it seems like the natur= al response would be to move to a batch signature scheme, such as the one D= avid Benjamin proposed for TLS [1]. This would have the advantage that it d= oesn't require any new protocol definition or reasoning, it's just = a drop-in for the existing signatures.

-Ekr
<= div>
[0] Let's Encrypt has about 10^8 certificates active= .

On Tue, Nov 26, 2019 at 5:42 AM Carrick Bartle <cbart= le891=3D40icloud.com@dmarc.i= etf.org> wrote:
Hi Max,

What's the current proposal? The=C2= =A0draft=C2=A0doesn't appear to contain details beyond the noti= on of providing ranges and information about the entire chain, and it doesn= 't seem to address the issues raised in the PKIX and LAMPS discussions = linked=C2=A0here.

<= div>At Apple, we also cache OCSP responses in a compressed form, i.e. in Bl= oom filters. Having the option to receive CRLs in a compressed format like = that would definitely be more efficient for us. I'm not convinced that = ranges would be as helpful. CRLs are helpful when someone is compiling an e= ntire catalog of revoked certificates. OCSP is helpful when you want to che= ck the revocation status of one particular certificate. If OCSP is instead = a hybrid of these two approaches, this assumes that the client is going to = want data on the other certificates in the range they receive (many of whic= h won't even exist, since, as someone commented in the pkix thread, ser= ial numbers are often (usually?) randomized). I'm not sure how often th= at additional revocation information is actually going to be useful to the = client. Statistics on that is the sort of data that would be helpful in eva= luating this proposal. If it turns out, for instance, that providing ranges= ends up saving only, say, 0.1% of OCSP requests, it probably wouldn't = be worth the effort.

As for returning revocation d= ata for the entire chain, the question must be asked: which chain? In some = cases, certificates are cross-signed, and so there is no one chain to provi= de revocation data for. Is the client effectively going to delegate finding= the best chain to the OCSP responder? I'm not sure that's in the c= lient's best interest, and I'm not sure OCSP responders are going t= o want to bother handling that.

Carrick
=


On Nov 20, 2019,= at 2:47 PM, Dr. Pala <madwolf@openca.org> wrote:

H= i Nick,

thanks for the reply. My comments are inline.= ..

On 11/20/19 1:07 PM, Nick Sullivan wrote:
Hi Max,
Thanks for your clarification. I now understand the work = is aimed at optimizing the number of signatures by the CA's OCSP respon= der and the number of bytes of unique OCSP data.

=
Yes, that is c= orrect. The other optimization is about the ability to provide responses fo= r the whole chain in a single message.
Currently, the n= umber of OCSP signatures the CA needs to do is linear in the number of acti= ve certificates. This proposal changes this so that the number of signature= s is linear in the number of revocations of active certificates. It's c= onceptually similar to NSEC in that way: it's a cover proposal in which= the artifacts are constant size, but require a linear number signatures in= the size of the revocation set. Contrast this with CRLs, which require a c= onstant number of signatures, but are linear in the size of the revocation = set. So maybe the goals could be better phrased in terms of=C2=A0lowe= ring the cost of=C2=A0generating= =C2=A0compared to OCSP and=C2=A0distribu= ting=C2=A0compared to CRLs.

=
I am not sure = I follow. In PKIs, today, we use both mechanisms. This is because usually t= he CRLs are used as a backup mechanism for OCSP - we also need to support b= oth because of Certification Policies (exactly as in the Internet PKI envir= onment), therefore it is not a choice :D The proposed approach can be used = to (a) limit the amount of data that needs to be generated, stored, and tra= nsferred when pre-computing responses, and (b) to compute all responses and= serve them from memory - even small instances without any hardware acceler= ation could achieve reasonable performances (also for shorter validity peri= ods in responses).
This proposal implies a middle-groun= d PKI deployment that has enough revocations for CRL to be inefficient but = not enough to cause the negative space of the serial number to be of the sa= me order as the number of certificates. It would be great to see examples o= f PKIs that motivate this optimization, which is why I suggested that data = could help.

Technically, y= ou are correct. If we could predict the size of CRLs, we could potentially = try to understand what that threshold is. However, as I explained in the pr= esentation, the size is fairly unpredictable. That is why we primarily use = OCSP today.

<= div>
I should also note that while this proposal reduces the = number of OCSP signatures (which can be on the order of 104 signatures for = 2-year certs), the impact is less dramatic for CAs that issue shorter-lived= certs. For example, Let's Encrypt only signs around 13 OCSP responses = for each of their 3-month certificates.

That is correct, the impact is less with short-lived certificates b= ecause in those environment, the population of active certificates is usual= ly smaller. If the population is still large, you still have the same probl= em.

You mention that your OCSP responses have a 7= days validity, correct ? My question is: which considerations went into de= ciding such a large validity period for the OCSP responses (7 days) ? Maybe= costs considerations drove the decision ? From a security standpoint, such= long validity periods blinds clients from detecting revocation that might = happen during the 7-days validity period (the problem is worse now with the= deployment of OCSP stapling because clients do not fetch fresh responses a= t connect time, AFAIK, if stapling is supported). I would expect that few m= inutes validity windows or maybe few hours would be a better choice - but h= ow much does that cost to Let's Encrypt ?

The= Cable industry has used certificates, for few decades now, for different p= urposes - as a hardware certification tool and to secure our networks - in = this environment, the typical life-span of a certificate is many years (up = to 20) and it is tied to the envisioned life-span of the device (no renewal= ). As you can see, in our environment, CRLs will never be an option and OCS= P simply costs too much (for an infrastructure that, over all, has an activ= e population of several hundreds million of active certificates - we might = be even beyond that with just the three OpenCable, PacketCable, and DOCSIS)= .

Ultimately, we need to work on the solution so that= we can have our vendors to integrate it in their products, like CableModes= , that are going to be deployed (and provide internet connectivity) for hun= dreds of millions of households for the next 10 to 20 years. We need to low= er the security risks associated with the infrastructures that brings Inter= net to many of us - revocation is important to prevent possible compromises= to go undetected. I think that everybody who has Cable should support this= work that is going to directly impact them for many years.=C2=A0

Cheers,
Max

P.S.: I = also have other personal motivations for this work. I think that this is al= so the right thing to do for non-technical reasons - I come from the OpenSo= urce world that so much has give for the success of the Internet but where = there is no money. More efficient technologies could be leveraged by commun= ities around the world who deserve good security but costs get in the way. = I know it is not a technical detail, but I think we shall always try to hav= e these considerations in our minds - making the world a better place and l= ess wasteful (energy) is an amendable goal in general and emerging communit= ies could really benefit from our work.


<= blockquote type=3D"cite" style=3D"font-family:Helvetica;font-size:18px;font= -style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:no= rmal;text-align:start;text-indent:0px;text-transform:none;white-space:norma= l;word-spacing:0px;text-decoration:none">
On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <= ;madwolf@openca.org= > wrote:
=

Hi Nick, all,

at the end of the second presentation on loweri= ng the costs of revocation, if I am not mistaken, your question/comment (Ni= ck) was about the fact that Cloudflare hosts / serve most of the cached OCS= P responses and that the system does not have issues.

I am not sure i= f this comment is pertinent to what we are trying to solve here... let me e= laborate a bit more.

The work we have been doing around the proposed = topic of work is aimed at=C2=A0lowering the cost of=C2=A0generating=C2=A0and=C2=A0= distributing=C2=A0these large volumes of signed data=C2=A0when there is actually no need for that. By optimizing= the protocol to provide range responses (or other methods, if we decide to= go with a different approaches), we can reduce the number of signatures ne= eded from a CA and their distribution - very expensive operations.

In= other words, the proposal is=C2=A0not aimed at fixing a= ny caching issues=C2=A0because, as you noticed in your= comment, that works just fine. The proposal at hand, instead, is about fix= ing a problem that CAs are facing today - high costs of deploying and runni= ng such systems.

On the other hand, your comment made me think about = the caching service you mentioned and its associated costs.=C2=A0

Is it a service for which your company charge CAs ? If so, wo= uld you be able to share what are currently the costs incurred by CAs to le= verage your service ? (I totally understand if you are not willing to - aft= er all, this is usually the secret sauce :D)

Last but not least, I al= so would like to point out that optimizing the revocation can also help ope= n-source communities, small companies, universities, non-profit, etc. by en= abling them to deploy cost-efficient systems that can provide good quality = of service using less resources (computational, storage, network).

<= p>Please let me know,

Cheers,
Max

P.S.: If we could combine = this idea with OCSP over DNS, we could really provide access to revocation = technology for everybody, not just who can afford the price. Unfortunately = we know how that discussion went, and I still think it is a very evident mi= stake not doing it=C2=A0 (I am still working on this in my spare time - I t= hink it is of enormous value for emerging countries to have access to cheap= secure technologies and, in my opinion, IETF is dropping / has dropped the= ball on this for not-so-honorable reasons, I suspect...). I hope We can fi= x it in the open-source community.

--=C2=A0
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
= <dhmacjdifkefaoin.png>
--=C2=A0
Best Regards,
= Massimiliano Pala, Ph.D.
OpenCA Labs Director
<ijeffbhl= gncflbab.png>
_______________________________________________
Secdispatch mail= ing list
Secdispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/secdispatch

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--00000000000085f659059840aa14-- From nobody Tue Nov 26 11:55:44 2019 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 4D883120127 for ; Tue, 26 Nov 2019 11:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=digicert.com header.b=Oy2gT+oz; dkim=pass (1024-bit key) header.d=digicert.com header.b=OQLNprC/ 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 BQuwXu-CjwYz for ; Tue, 26 Nov 2019 11:55:37 -0800 (PST) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA18F120018 for ; Tue, 26 Nov 2019 11:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1574798135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Zf0F6DqkOmNDVWH6z3ek7Vs2volz0LM44W8yXadnRqM=; b=Oy2gT+oztxK5zQNFgLEuOWYvEl7thLnIM4+WVWFVZ0thytaUq7eYQZ2Dj3LnqngQbbTTD1 j5wbL9dQxTTVMCemRUg6rWzEbnjxFKG6TnP3gB1BAKD/lB4zyz4g8sPAf7W+kWsdcdRD61 jubmT6ac56iu9mQMAgooorvb7dtACF4= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2052.outbound.protection.outlook.com [104.47.38.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-270-NCOfqPM3O2C3L8-LvKV7cg-1; Tue, 26 Nov 2019 14:55:30 -0500 X-MC-Unique: NCOfqPM3O2C3L8-LvKV7cg-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EtOob0qK+Hty2/SZj5/WHWmTDoY5OzjPpd1/yftzvSt8xYR+KG/sVyyLN6Ecvls15wMg4bfDSEhZNnjnS8MerwFTqCOGPebBlEllMN1DV6aUipV7dXjPkBSvUuj3pCixPWt5X2o/9c+YkJmi1Yj/gr02D1zn/GXzstnD2gQUGm7SlLByVvQrxvWd25KITC4DbHk1NAN8VjiB0GXbzcRRV0wZTnll2rb7TQM8o6gOSagxm1/SX066vzagAHx0xBfGYB4RtFZuudP8ZxUP8PEazgIfmZBdxdoJizK8U5zN4nl+12nyjGWiMU07FXsNhV66tWOsH9oHsnLfMwDpDEFc8g== 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=Zf0F6DqkOmNDVWH6z3ek7Vs2volz0LM44W8yXadnRqM=; b=oXRfzi8ax9b7iXi6E78Szsbglu3AEihBFM9Sq+veCpdbD7etiYtMSEEAalBx8KVrFA8OEB/DAoWQyNXqud3HTkANRAECdYaVv+HFfeg5r1IUYhYXrWGRl5r638fl5VqUDFUp57+XVeei57D02FJkwGPa48G/0xGHcOyaYDdISvjKVPdwMJq/LEdzrNhni7ArS5CsOB5QS0V0PjBeRRw1naFyj35RkbRExbOYi7QbyHp6/BVDOj0mWZlVBQZQKyLNOmSNWi1xL0GezF9o/kPd6NZ282MRG/+ubrsSlvlswYmT1/45oRrJ9pJZ5JhEmzk1yrq2v5Okdz4ZNw6rIUOlWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zf0F6DqkOmNDVWH6z3ek7Vs2volz0LM44W8yXadnRqM=; b=OQLNprC/mYuvYW0yzt8bsSIWBJCGiVpgxa2NHvDP0g3a5srwAVtp++7d4AK1rtg5Q6i1EOvsaFIPmZpfRrhrNrM6NACkL9Ye6fvPkx5uvbLrpf/jUJTUfmtQKY9KL7yg5qjsaT9HJZuc1P3dfVWzK1OLwdKva+5iY7lHWfABLbE= Received: from CH2PR14MB3644.namprd14.prod.outlook.com (10.186.137.20) by CH2PR14MB3944.namprd14.prod.outlook.com (20.180.16.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Tue, 26 Nov 2019 19:55:27 +0000 Received: from CH2PR14MB3644.namprd14.prod.outlook.com ([fe80::f4a8:8f67:3f90:2736]) by CH2PR14MB3644.namprd14.prod.outlook.com ([fe80::f4a8:8f67:3f90:2736%4]) with mapi id 15.20.2474.023; Tue, 26 Nov 2019 19:55:27 +0000 From: Tim Hollebeek To: Carrick Bartle , "Dr. Pala" CC: Nick Sullivan , IETF SecDispatch Thread-Topic: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) Thread-Index: AQHVntrLBvBdg70fIEi/GUO8I2l8aKeTgzEAgAAbu4CACeIigIAAYLDw Date: Tue, 26 Nov 2019 19:55:27 +0000 Message-ID: References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> In-Reply-To: <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f56e9aff-247b-4e71-bfd4-08d772aa95a6 x-ms-traffictypediagnostic: CH2PR14MB3944: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(136003)(39850400004)(366004)(40224003)(51914003)(189003)(199004)(51444003)(11346002)(53546011)(66066001)(30864003)(229853002)(86362001)(6436002)(5660300002)(55016002)(6306002)(9686003)(99286004)(14454004)(966005)(316002)(54906003)(446003)(66574012)(52536014)(26005)(186003)(6246003)(110136005)(102836004)(2906002)(478600001)(76116006)(33656002)(256004)(3846002)(6116002)(71200400001)(561944003)(71190400001)(4326008)(66446008)(66946007)(66556008)(66616009)(66476007)(64756008)(81166006)(8936002)(81156014)(8676002)(44832011)(14444005)(305945005)(25786009)(76176011)(7696005)(74316002)(7736002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR14MB3944; H:CH2PR14MB3644.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wlL/svQwYJk5tk7ZFhvfcJSgTRw/zYh83Yvrxzpp17aF0KFI3OPntoBtRyAZQcv1T/WyqH6TsyzIh0Zj8x4EQuHOad/eGDi81AxaxsjcCRehPvO86YKH/apzhmnPEY6wYRCOYgPLfUU70nR4L4PGv2+Di7z1mG+XnktvLj5aRkJBldHxFhrxqGGbogxOsPWHbFmm0R0OOt1BC+btByNHiqE91BzDRbsi2ML39RbfTnthxGDBnNSiJAAW0ILd+Cm8RKi+o5xZsaIe8dG0FJ/MFQWR6I01L8ltOsU6HH11iZiDr4/KLoBPQbpd8XLnHNh8jXWEUEBCT6GGQwl+vt0msr793wPxSqG/ps1LypH1+Xf3kBdZdlg1s7/ax6uZxunvs9YyHTyWqf2sRIC3pTKMAN7Cye5CkWuPGITFMQClrje86iusRRC/3Mg+05cTyoLvY1NEOl5m4Pbvm0p9BcW6eSixnzOQEydWuiJkuYSEmPw= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0028_01D5A469.89363490" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: f56e9aff-247b-4e71-bfd4-08d772aa95a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 19:55:27.5042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZX/QARckGc/i1RFf4IYId8UxU/fSA9V0oHwh8JBXkBpABl/N5ncRqkGNMj8WziDPn2wCrTxKW4r10k098pF0J0hSX4V1Z79iL4le9/jSjpw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR14MB3944 Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) 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, 26 Nov 2019 19:55:42 -0000 ------=_NextPart_000_0028_01D5A469.89363490 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0029_01D5A469.89363490" ------=_NextPart_001_0029_01D5A469.89363490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I'm a big fan of the bloom filters that several browsers are deploying. However, these filters express an aggregate of all the information across multiple CRLs, and have some false positives due to the compression. It naively seems to me that creating these bloom filters based on compressed CRLs would be a bad idea, as it would compound the errors. But I'd love to see or work with people on data on that, because perhaps with the proper tuning that isn't really an issue. So if you're using bloom filters, you probably want to spend the time working on raw CRLs, and either way, this proposal is of no interest to you since you're not relying on OCSP on the client side. However, that's not the use case that ranges really address. Ranges are NOT intended for clients that want the status of multiple certificates. Indeed, they don't work particularly well for that use case because it doesn't take too many revocations before you have to get a bit lucky for multiple of the certificates you are interested in to be in the same range. The real use case is for devices that do not have the storage capacity to take advantage of the bloom filter approach. These clients still need OCSP to be efficient for single certificates. And it is, on the client end. However, on the server end, generating individual OCSP responses and distributing them to a CDN for every valid certificate is a significant workload. This is especially true because the smaller and more resource constrained your devices are, the likelihood is you have many, many more of them. So it makes sense to think about how to optimize for the "most lightbulbs are not revoked" case. Both the generation time and the amount of CDN content that needs to be distributed is greatly reduced by allowing range-based responses. So again, this isn't about saving OCSP requests at all, and this proposal has absolutely no impact on the very intelligent and forward looking endpoint that choose to avoid OCSP requests by compressing CRLs and replacing OCSP with local lookup. It's designed for systems and ecosystems who can't do that, which is not the Apple use case. -Tim From: Carrick Bartle Sent: Tuesday, November 26, 2019 8:43 AM To: Dr. Pala Cc: Nick Sullivan ; IETF SecDispatch ; Tim Hollebeek Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) Hi Max, What's the current proposal? The draft doesn't appear to contain details beyond the notion of providing ranges and information about the entire chain, and it doesn't seem to address the issues raised in the PKIX and LAMPS discussions linked here . At Apple, we also cache OCSP responses in a compressed form, i.e. in Bloom filters. Having the option to receive CRLs in a compressed format like that would definitely be more efficient for us. I'm not convinced that ranges would be as helpful. CRLs are helpful when someone is compiling an entire catalog of revoked certificates. OCSP is helpful when you want to check the revocation status of one particular certificate. If OCSP is instead a hybrid of these two approaches, this assumes that the client is going to want data on the other certificates in the range they receive (many of which won't even exist, since, as someone commented in the pkix thread, serial numbers are often (usually?) randomized). I'm not sure how often that additional revocation information is actually going to be useful to the client. Statistics on that is the sort of data that would be helpful in evaluating this proposal. If it turns out, for instance, that providing ranges ends up saving only, say, 0.1% of OCSP requests, it probably wouldn't be worth the effort. As for returning revocation data for the entire chain, the question must be asked: which chain? In some cases, certificates are cross-signed, and so there is no one chain to provide revocation data for. Is the client effectively going to delegate finding the best chain to the OCSP responder? I'm not sure that's in the client's best interest, and I'm not sure OCSP responders are going to want to bother handling that. Carrick On Nov 20, 2019, at 2:47 PM, Dr. Pala > wrote: Hi Nick, thanks for the reply. My comments are inline... On 11/20/19 1:07 PM, Nick Sullivan wrote: Hi Max, Thanks for your clarification. I now understand the work is aimed at optimizing the number of signatures by the CA's OCSP responder and the number of bytes of unique OCSP data. Yes, that is correct. The other optimization is about the ability to provide responses for the whole chain in a single message. Currently, the number of OCSP signatures the CA needs to do is linear in the number of active certificates. This proposal changes this so that the number of signatures is linear in the number of revocations of active certificates. It's conceptually similar to NSEC in that way: it's a cover proposal in which the artifacts are constant size, but require a linear number signatures in the size of the revocation set. Contrast this with CRLs, which require a constant number of signatures, but are linear in the size of the revocation set. So maybe the goals could be better phrased in terms of lowering the cost of generating compared to OCSP and distributing compared to CRLs. I am not sure I follow. In PKIs, today, we use both mechanisms. This is because usually the CRLs are used as a backup mechanism for OCSP - we also need to support both because of Certification Policies (exactly as in the Internet PKI environment), therefore it is not a choice :D The proposed approach can be used to (a) limit the amount of data that needs to be generated, stored, and transferred when pre-computing responses, and (b) to compute all responses and serve them from memory - even small instances without any hardware acceleration could achieve reasonable performances (also for shorter validity periods in responses). This proposal implies a middle-ground PKI deployment that has enough revocations for CRL to be inefficient but not enough to cause the negative space of the serial number to be of the same order as the number of certificates. It would be great to see examples of PKIs that motivate this optimization, which is why I suggested that data could help. Technically, you are correct. If we could predict the size of CRLs, we could potentially try to understand what that threshold is. However, as I explained in the presentation, the size is fairly unpredictable. That is why we primarily use OCSP today. I should also note that while this proposal reduces the number of OCSP signatures (which can be on the order of 104 signatures for 2-year certs), the impact is less dramatic for CAs that issue shorter-lived certs. For example, Let's Encrypt only signs around 13 OCSP responses for each of their 3-month certificates. That is correct, the impact is less with short-lived certificates because in those environment, the population of active certificates is usually smaller. If the population is still large, you still have the same problem. You mention that your OCSP responses have a 7 days validity, correct ? My question is: which considerations went into deciding such a large validity period for the OCSP responses (7 days) ? Maybe costs considerations drove the decision ? From a security standpoint, such long validity periods blinds clients from detecting revocation that might happen during the 7-days validity period (the problem is worse now with the deployment of OCSP stapling because clients do not fetch fresh responses at connect time, AFAIK, if stapling is supported). I would expect that few minutes validity windows or maybe few hours would be a better choice - but how much does that cost to Let's Encrypt ? The Cable industry has used certificates, for few decades now, for different purposes - as a hardware certification tool and to secure our networks - in this environment, the typical life-span of a certificate is many years (up to 20) and it is tied to the envisioned life-span of the device (no renewal). As you can see, in our environment, CRLs will never be an option and OCSP simply costs too much (for an infrastructure that, over all, has an active population of several hundreds million of active certificates - we might be even beyond that with just the three OpenCable, PacketCable, and DOCSIS). Ultimately, we need to work on the solution so that we can have our vendors to integrate it in their products, like CableModes, that are going to be deployed (and provide internet connectivity) for hundreds of millions of households for the next 10 to 20 years. We need to lower the security risks associated with the infrastructures that brings Internet to many of us - revocation is important to prevent possible compromises to go undetected. I think that everybody who has Cable should support this work that is going to directly impact them for many years. Cheers, Max P.S.: I also have other personal motivations for this work. I think that this is also the right thing to do for non-technical reasons - I come from the OpenSource world that so much has give for the success of the Internet but where there is no money. More efficient technologies could be leveraged by communities around the world who deserve good security but costs get in the way. I know it is not a technical detail, but I think we shall always try to have these considerations in our minds - making the world a better place and less wasteful (energy) is an amendable goal in general and emerging communities could really benefit from our work. On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala > wrote: Hi Nick, all, at the end of the second presentation on lowering the costs of revocation, if I am not mistaken, your question/comment (Nick) was about the fact that Cloudflare hosts / serve most of the cached OCSP responses and that the system does not have issues. I am not sure if this comment is pertinent to what we are trying to solve here... let me elaborate a bit more. The work we have been doing around the proposed topic of work is aimed at lowering the cost of generating and distributing these large volumes of signed data when there is actually no need for that. By optimizing the protocol to provide range responses (or other methods, if we decide to go with a different approaches), we can reduce the number of signatures needed from a CA and their distribution - very expensive operations. In other words, the proposal is not aimed at fixing any caching issues because, as you noticed in your comment, that works just fine. The proposal at hand, instead, is about fixing a problem that CAs are facing today - high costs of deploying and running such systems. On the other hand, your comment made me think about the caching service you mentioned and its associated costs. Is it a service for which your company charge CAs ? If so, would you be able to share what are currently the costs incurred by CAs to leverage your service ? (I totally understand if you are not willing to - after all, this is usually the secret sauce :D) Last but not least, I also would like to point out that optimizing the revocation can also help open-source communities, small companies, universities, non-profit, etc. by enabling them to deploy cost-efficient systems that can provide good quality of service using less resources (computational, storage, network). Please let me know, Cheers, Max P.S.: If we could combine this idea with OCSP over DNS, we could really provide access to revocation technology for everybody, not just who can afford the price. Unfortunately we know how that discussion went, and I still think it is a very evident mistake not doing it (I am still working on this in my spare time - I think it is of enormous value for emerging countries to have access to cheap secure technologies and, in my opinion, IETF is dropping / has dropped the ball on this for not-so-honorable reasons, I suspect...). I hope We can fix it in the open-source community. -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch ------=_NextPart_001_0029_01D5A469.89363490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I’m a = big fan of the bloom filters that several browsers are deploying.  = However, these filters express an aggregate of all the information = across multiple CRLs, and have some false positives due to the = compression.  It naively seems to me that creating these bloom = filters based on compressed CRLs would be a bad idea, as it would = compound the errors.  But I’d love to see or work with people = on data on that, because perhaps with the proper tuning that isn’t = really an issue.  So if you’re using bloom filters, you = probably want to spend the time working on raw CRLs, and either way, = this proposal is of no interest to you since you’re not relying on = OCSP on the client side.

 

However, = that’s not the use case that ranges really address.  Ranges = are NOT intended for clients that want the status of multiple = certificates.  Indeed, they don’t work particularly well for = that use case because it doesn’t take too many revocations before = you have to get a bit lucky for multiple of the certificates you are = interested in to be in the same range.

 

The real use = case is for devices that do not have the storage capacity to take = advantage of the bloom filter approach.  These clients still need = OCSP to be efficient for single certificates.  And it is, on the = client end.  However, on the server end, generating individual OCSP = responses and distributing them to a CDN for every valid certificate is = a significant workload.  This is especially true because the = smaller and more resource constrained your devices are, the likelihood = is you have many, many more of them.  So it makes sense to think = about how to optimize for the “most lightbulbs are not = revoked” case.

Both the = generation time and the amount of CDN content that needs to be = distributed is greatly reduced by allowing range-based = responses.

 

So again, this isn’t about saving OCSP requests = at all, and this proposal has absolutely no impact on the very = intelligent and forward looking endpoint that choose to avoid OCSP = requests by compressing CRLs and replacing OCSP with local lookup.  = It’s designed for systems and ecosystems who can’t do that, = which is not the Apple use case.

 

-Tim

 

From: = Carrick Bartle <cbartle891@icloud.com>
Sent: Tuesday, = November 26, 2019 8:43 AM
To: Dr. Pala = <madwolf@openca.org>
Cc: Nick Sullivan = <nick@cloudflare.com>; IETF SecDispatch = <secdispatch@ietf.org>; Tim Hollebeek = <tim.hollebeek@digicert.com>
Subject: Re: [Secdispatch] = Clarification for a question about OCSP caching from Nick = (Cloudflare)

 

Hi = Max,

 

What's the current proposal? The draft = doesn't appear to contain details beyond the notion of providing ranges = and information about the entire chain, and it doesn't seem to address = the issues raised in the PKIX and LAMPS discussions linked here.

 

At Apple, we also cache OCSP responses in a compressed = form, i.e. in Bloom filters. Having the option to receive CRLs in a = compressed format like that would definitely be more efficient for us. = I'm not convinced that ranges would be as helpful. CRLs are helpful when = someone is compiling an entire catalog of revoked certificates. OCSP is = helpful when you want to check the revocation status of one particular = certificate. If OCSP is instead a hybrid of these two approaches, this = assumes that the client is going to want data on the other certificates = in the range they receive (many of which won't even exist, since, as = someone commented in the pkix thread, serial numbers are often = (usually?) randomized). I'm not sure how often that additional = revocation information is actually going to be useful to the client. = Statistics on that is the sort of data that would be helpful in = evaluating this proposal. If it turns out, for instance, that providing = ranges ends up saving only, say, 0.1% of OCSP requests, it probably = wouldn't be worth the effort.

 

As for returning revocation data for the entire chain, = the question must be asked: which chain? In some cases, certificates are = cross-signed, and so there is no one chain to provide revocation data = for. Is the client effectively going to delegate finding the best chain = to the OCSP responder? I'm not sure that's in the client's best = interest, and I'm not sure OCSP responders are going to want to bother = handling that.

 

Carrick

 

 



On Nov 20, 2019, at 2:47 PM, Dr. Pala <madwolf@openca.org> = wrote:

 

Hi = Nick,

thanks for = the reply. My comments are inline...

On = 11/20/19 1:07 PM, Nick Sullivan = wrote:

Hi = Max,

 =

Thanks for = your clarification. I now understand the work is aimed at optimizing the = number of signatures by the CA's OCSP responder and the number of bytes = of unique OCSP data.

 =

Yes, that = is correct. The other optimization is about the ability to provide = responses for the whole chain in a single message.

Currently, = the number of OCSP signatures the CA needs to do is linear in the number = of active certificates. This proposal changes this so that the number of = signatures is linear in the number of revocations of active = certificates. It's conceptually similar to NSEC in that way: it's a = cover proposal in which the artifacts are constant size, but require a = linear number signatures in the size of the revocation set. Contrast = this with CRLs, which require a constant number of signatures, but are = linear in the size of the revocation set. So maybe the goals could be = better phrased in terms of lowering the cost = of generating compared to OCSP = and distributing compared to = CRLs.

 =

I am not = sure I follow. In PKIs, today, we use both mechanisms. This is because = usually the CRLs are used as a backup mechanism for OCSP - we also need = to support both because of Certification Policies (exactly as in the = Internet PKI environment), therefore it is not a choice :D The proposed = approach can be used to (a) limit the amount of data that needs to be = generated, stored, and transferred when pre-computing responses, and (b) = to compute all responses and serve them from memory - even small = instances without any hardware acceleration could achieve reasonable = performances (also for shorter validity periods in responses).

This = proposal implies a middle-ground PKI deployment that has enough = revocations for CRL to be inefficient but not enough to cause the = negative space of the serial number to be of the same order as the = number of certificates. It would be great to see examples of PKIs that = motivate this optimization, which is why I suggested that data could = help.

Technically= , you are correct. If we could predict the size of CRLs, we could = potentially try to understand what that threshold is. However, as I = explained in the presentation, the size is fairly unpredictable. That is = why we primarily use OCSP today.

 =

I should = also note that while this proposal reduces the number of OCSP signatures = (which can be on the order of 104 signatures for 2-year certs), the = impact is less dramatic for CAs that issue shorter-lived certs. For = example, Let's Encrypt only signs around 13 OCSP responses for each of = their 3-month = certificates.

That is = correct, the impact is less with short-lived certificates because in = those environment, the population of active certificates is usually = smaller. If the population is still large, you still have the same = problem.

You = mention that your OCSP responses have a 7 days validity, correct ? My = question is: which considerations went into deciding such a large = validity period for the OCSP responses (7 days) ? Maybe costs = considerations drove the decision ? From a security standpoint, such = long validity periods blinds clients from detecting revocation that = might happen during the 7-days validity period (the problem is worse now = with the deployment of OCSP stapling because clients do not fetch fresh = responses at connect time, AFAIK, if stapling is supported). I would = expect that few minutes validity windows or maybe few hours would be a = better choice - but how much does that cost to Let's Encrypt = ?

The Cable = industry has used certificates, for few decades now, for different = purposes - as a hardware certification tool and to secure our networks - = in this environment, the typical life-span of a certificate is many = years (up to 20) and it is tied to the envisioned life-span of the = device (no renewal). As you can see, in our environment, CRLs will never = be an option and OCSP simply costs too much (for an infrastructure that, = over all, has an active population of several hundreds million of active = certificates - we might be even beyond that with just the three = OpenCable, PacketCable, and DOCSIS).

Ultimately,= we need to work on the solution so that we can have our vendors to = integrate it in their products, like CableModes, that are going to be = deployed (and provide internet connectivity) for hundreds of millions of = households for the next 10 to 20 years. We need to lower the security = risks associated with the infrastructures that brings Internet to many = of us - revocation is important to prevent possible compromises to go = undetected. I think that everybody who has Cable should support this = work that is going to directly impact them for many years. 

Cheers,
= Max

P.S.: I = also have other personal motivations for this work. I think that this is = also the right thing to do for non-technical reasons - I come from the = OpenSource world that so much has give for the success of the Internet = but where there is no money. More efficient technologies could be = leveraged by communities around the world who deserve good security but = costs get in the way. I know it is not a technical detail, but I think = we shall always try to have these considerations in our minds - making = the world a better place and less wasteful (energy) is an amendable goal = in general and emerging communities could really benefit from our = work.

 =

On Tue, = Nov 19, 2019 at 9:11 PM Dr. Pala <madwolf@openca.org> = wrote:

Hi Nick, = all,

at the end = of the second presentation on lowering the costs of revocation, if I am = not mistaken, your question/comment (Nick) was about the fact that = Cloudflare hosts / serve most of the cached OCSP responses and that the = system does not have issues.

I am not = sure if this comment is pertinent to what we are trying to solve here... = let me elaborate a bit more.

The work = we have been doing around the proposed topic of work is aimed at lowering the cost = of generating and distributing these large volumes of signed = data when there = is actually no need for that. By optimizing the protocol to provide = range responses (or other methods, if we decide to go with a different = approaches), we can reduce the number of signatures needed from a CA and = their distribution - very expensive operations.

In other = words, the proposal is not aimed at fixing any = caching issues because, as you noticed in = your comment, that works just fine. The proposal at hand, instead, is = about fixing a problem that CAs are facing today - high costs of = deploying and running such systems.

On the = other hand, your comment made me think about the caching service you = mentioned and its associated costs. 

Is it a = service for which your company charge CAs ? If so, would you be able to = share what are currently the costs incurred by CAs to leverage your = service ? (I totally understand if you are not willing to - after all, = this is usually the secret sauce :D)

Last but = not least, I also would like to point out that optimizing the revocation = can also help open-source communities, small companies, universities, = non-profit, etc. by enabling them to deploy cost-efficient systems that = can provide good quality of service using less resources (computational, = storage, network).

Please let = me know,

Cheers,
= Max

P.S.: If = we could combine this idea with OCSP over DNS, we could really provide = access to revocation technology for everybody, not just who can afford = the price. Unfortunately we know how that discussion went, and I still = think it is a very evident mistake not doing it  (I am still = working on this in my spare time - I think it is of enormous value for = emerging countries to have access to cheap secure technologies and, in = my opinion, IETF is dropping / has dropped the ball on this for = not-so-honorable reasons, I suspect...). I hope We can fix it in the = open-source community.

-- 

Best = Regards,

Massimilian= o Pala, Ph.D.
OpenCA Labs Director

<dhmacjd= ifkefaoin.png>

-- 

Best = Regards,

Massimilian= o Pala, Ph.D.
OpenCA Labs Director

<ijeffbh= lgncflbab.png>

___________= ____________________________________
Secdispatch mailing = list
Secdispatch= @ietf.org
= https://www= .ietf.org/mailman/listinfo/secdispatch

 

------=_NextPart_001_0029_01D5A469.89363490-- ------=_NextPart_000_0028_01D5A469.89363490 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkxMTI2MTk1NTI1WjAvBgkqhkiG9w0BCQQxIgQg9nL8KyLUL9Ua6MDHyvjcTJk3ERvO KNjrWi0XcwYYdxkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAAppEJLZ+DzqTGM5ftS24qh5PPIyOj5EVeleb8tCVB6LKEbMCUgry4p/NzGGvWJSgnHFKAWG 0cv9XzBunshgPlj8yPSDXcxL6LiQCedKCOMg0MZGXX8o5nVQTglFSvs0tVkWjl91dUvGg3mj4EXZ a0fTDBQWzzFbwEhLHn+4BEr3JC3qU6ceShISmkqZ9BFGyZ+JsY6DZVY/+DXOJQoyftzh3HfmmvBz xy6VISYyKg70KXDlWkWfv1/KEKuSE7ufbS5GXFi0I5pylWlgFCKYEbl3kVxdCQQ9to6R4PCn8C8d pmTO4jhFZ+bkwvlCtwDBGit5UX6PfjWpRNzAhrOB/nUAAAAAAAA= ------=_NextPart_000_0028_01D5A469.89363490-- From nobody Wed Nov 27 09:43:02 2019 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 29751120B66 for ; Wed, 27 Nov 2019 09:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-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 s--qr8MP-Cgn for ; Wed, 27 Nov 2019 09:42:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FF2120978 for ; Wed, 27 Nov 2019 09:42:59 -0800 (PST) Received: from dooku.sandelman.ca (unknown [81.168.90.245]) by relay.sandelman.ca (Postfix) with ESMTPS id 5B2BD1F47D; Wed, 27 Nov 2019 17:42:57 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2F77C2CC; Thu, 28 Nov 2019 01:42:58 +0800 (+08) From: Michael Richardson To: "Dr. Pala" cc: Carrick Bartle , IETF SecDispatch , Nick Sullivan , Tim Hollebeek In-reply-to: References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> Comments: In-reply-to Eric Rescorla message dated "Tue, 26 Nov 2019 06:25:53 -0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 27 Nov 2019 18:42:58 +0100 Message-ID: <20002.1574876578@dooku.sandelman.ca> Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 17:43:01 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > It's probably useful to start with a clear problem statement. if I > understood Max's presentation correctly, it's that it's too expensive to > compute all the OCSP signatures. I'm not sure I'm persuaded that that's > true, as public key signatures are very fast (especially if you use ECDSA), > and even the largest public CAs don't actually have that many certificates > on the grand scheme of things [0]. However, to the extent to which it is > true, it seems like the natural response would be to move to a batch > signature scheme, such as the one David Benjamin proposed for TLS [1]. This would work well for TLS. It would be good to understand if the problems that Dr. Pala is talking about are specifically about TLS, or if it relates to some other system common in the cable industry. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3etaEACgkQlUzhVv38 QpBqVgf9HE065vy3MVwJwFs7d5INiWpa4U5rOzPalzaVVWr1Fb3enkurREQo0NGx xRmcn317da44WlB5G1Hly2/rAJkYNxqOZCMgqkr5qizU8Z4I/QfaaX55F+y5vIBi LXgh2lPF6JrpKfoBy1XrCBuGCYZ/IkKcxjn2Bn4Cm7QUPxDQlP42drG5FOCap92Z ssfiKDA4WFtMw2rgpLXc1rv74yPXfd1cbBRwcu324bp5N8+stlgPUKHEGIKKPfSy +JPX7v6tZC8a0ErR8SSl0cW4J2/sQjX3UXJrrad1VBOSF0HTDTqrSf8PmxBifViV CfT05XIW/LkQ5rShdOLKMbHsgQ8yTg== =t5oT -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 27 14:20:55 2019 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 17CC8120145 for ; Wed, 27 Nov 2019 14:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 PDg80nD7FGn7 for ; Wed, 27 Nov 2019 14:20:48 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 87558120108 for ; Wed, 27 Nov 2019 14:20:48 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id t5so26224361ljk.0 for ; Wed, 27 Nov 2019 14:20:48 -0800 (PST) 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=IpW877pZSGqes71/Q1+XuJshkp5VPRNLhQ3p0JraA2g=; b=O2rQrZg4KLCZcgbs2yIjtxRl14hxr7duVwm2rXrK+H66qXSXF7b95luZqBbjdsTcb9 G1fW1T0FGYn7fB8iUUExdWFZG+tWRXxLqPgjgV7x6nYzMeqUEFdWzvDj+UPm32qtlgda j/zYK97jxpWbw2NNYNX3crHIR0DMMTNW6qBuUHP9VS8E8vg7d24IGH4Xl/893jtsUaXN jj30PkSMP0FFDF0FABA1Gy8iiko1HW0ZiTCooza7SkKnO0qDzTuodQfKgr19ir/0gEZK VSb7PJj36Fg/lTrTl8XbrwYgBPPrHLCCzEKO/uwX8qbxyqhuFEqUYFmC2sx3KFV2Uw4n XYfA== 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=IpW877pZSGqes71/Q1+XuJshkp5VPRNLhQ3p0JraA2g=; b=Gb13eomyrfK4mQjNGDA4IkLYYQafgi/iwNqEqRUVxXtNIgrIJr5dgD5KIC95zFrc+Z F5yq0DRmKgbBxJGLFiwrlgex8wMDlHXfuf+Nd+5F3TaD1nbKd/Y4UcvpXXerD2AZ/k76 BCYgmlP8zvEbUxWpWLv8CjDNQzHr+2XraP8rCEiEkSXHi2b3DjYSwUHuEeMcgZBUQS0g 7AuKMFuo/Y7NksdMM3w3DLaG0/QYTfoWKkMZ7Wx0S5S/3ldzy1PuF5Pjl7hcpskRBU+X B9bHgSDBkPmUCN3ZHotWb6ji4ZBZAqkYrSOrsDVGzuFRTkvoEARhzRxJC2c1F3jSEDUa VtPg== X-Gm-Message-State: APjAAAUCCSWXP4Rh86CcnkVw5bodadCXBwYW+tidX3I0HatFZ76KQFRK EzacSFVhT05Ize49usJaEaTiPaTkC2Dcjekeu99CSQ== X-Google-Smtp-Source: APXvYqzHTG7b3ntPOIaCJXHmAHJOb0YS7UIvebt/TomCZ1c+P9viLox6THzMPk4260YWBa7kHkvXa4P41Qv6BRLdnxk= X-Received: by 2002:a2e:3a12:: with SMTP id h18mr26239925lja.217.1574893246663; Wed, 27 Nov 2019 14:20:46 -0800 (PST) MIME-Version: 1.0 References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> <20002.1574876578@dooku.sandelman.ca> In-Reply-To: <20002.1574876578@dooku.sandelman.ca> From: Eric Rescorla Date: Wed, 27 Nov 2019 14:20:10 -0800 Message-ID: To: Michael Richardson Cc: "Dr. Pala" , Carrick Bartle , IETF SecDispatch , Nick Sullivan , Tim Hollebeek Content-Type: multipart/alternative; boundary="00000000000086e2fe05985b6818" Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 22:20:54 -0000 --00000000000086e2fe05985b6818 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 27, 2019 at 9:43 AM Michael Richardson wrote: > > Eric Rescorla wrote: > > It's probably useful to start with a clear problem statement. if I > > understood Max's presentation correctly, it's that it's too > expensive to > > compute all the OCSP signatures. I'm not sure I'm persuaded that > that's > > true, as public key signatures are very fast (especially if you use > ECDSA), > > and even the largest public CAs don't actually have that many > certificates > > on the grand scheme of things [0]. However, to the extent to which > it is > > true, it seems like the natural response would be to move to a batch > > signature scheme, such as the one David Benjamin proposed for TLS > [1]. > > This would work well for TLS. > It would be good to understand if the problems that Dr. Pala is talking > about > are specifically about TLS, or if it relates to some other system common in > the cable industry. > I think it's less a matter of TLS versus not TLS but rather of what you are trying to optimize for. If it's just signing bandwidth then this is a good solution. If it's also network bandwidth, then perhaps less so, though we'd need to do the math. -Ekr > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --00000000000086e2fe05985b6818 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 27, 2019 at 9:43 AM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 > It's probably useful to start with a clear problem s= tatement. if I
=C2=A0 =C2=A0 > understood Max's presentation correctly, it's th= at it's too expensive to
=C2=A0 =C2=A0 > compute all the OCSP signatures.=C2=A0 I'm not sure = I'm persuaded that that's
=C2=A0 =C2=A0 > true, as public key signatures are very fast (especially= if you use ECDSA),
=C2=A0 =C2=A0 > and even the largest public CAs don't actually have = that many certificates
=C2=A0 =C2=A0 > on the grand scheme of things [0]. However, to the exten= t to which it is
=C2=A0 =C2=A0 > true, it seems like the natural response would be to mov= e to a batch
=C2=A0 =C2=A0 > signature scheme, such as the one David Benjamin propose= d for TLS [1].

This would work well for TLS.
It would be good to understand if the problems that Dr. Pala is talking abo= ut
are specifically about TLS, or if it relates to some other system common in=
the cable industry.

I think it's le= ss a matter of TLS versus not TLS but rather of what you are trying to opti= mize for.

If it's just signing bandwidth then = this is a good solution. If it's also network bandwidth, then perhaps l= ess so, though we'd need to do the math.

-Ekr<= /div>



--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--00000000000086e2fe05985b6818-- From nobody Thu Nov 28 02:41:48 2019 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 E306C120143 for ; Thu, 28 Nov 2019 02:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 GjpbXpSSr5oK for ; Thu, 28 Nov 2019 02:41:44 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30054.outbound.protection.outlook.com [40.107.3.54]) (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 85FE1120132 for ; Thu, 28 Nov 2019 02:41:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HY5A8pAF7ib7fH3yX2niKC5DFesPghQiEQ0jy7TfMV+VIexElxERR5M9SYYcSQ2Lpn9VnMOGSw9hIpCC9As/GadAGnbKEVwC3KP46NovsHdBsZC0dqaLu759RPyRxL5DZnxuO2vGbiOKllvAEQgrERTwABNiK9HoJczZpeiGuglLAQoxKRBodQdNp43oT0JCc33seYEx+WLr3eiMD9ohMUAo4oa2fEXEtQms983UQegt72JEBTzGF65mxxvMaKjrwmOQ1kwWEF5At0zfyUSvVIWTQoAAG93sOZ//0JulV+mRhLtukaQBbpwU6L2q7eqYLPZPdsIefjR23dP07XtIog== 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=8+G0RIgkZyyyGUWm6X7zDhlBtz9/wefV7y1+cfTHzOU=; b=cCDSp5a9YX8f+A0e83mF8/b1vvWSOW9iVTf70rtXOJjKvxsU7l9vkDjvH4pDy1z+8x7tjFrKQigDnYoTfiAbw0pheaNrc4Nd4/YjxzAmaW5uhHvkR4W4a9EA9HRcKEMmtgphfa4nO3FlC32/ogArPp4QnEtRrts9Gx50y2v7H2vZXci1u1XaqSufBpZBVzs4m/h7MB7qBvaLoM3JUFoGI+V4IJ1V80J67PVXSCLH685wekzQanrvFkyLW2PA9jMiryUmlAgorySRy7e1QPB0VvUHXBJdEbXpB1tfsjvKy+7rc5mqenAHnStgDPerG+RaagvnplACA19hd0vEXIzBVw== 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=8+G0RIgkZyyyGUWm6X7zDhlBtz9/wefV7y1+cfTHzOU=; b=D+CDU/LCDqB5W03/YNU5yqNz410RmX4iTW5fh/3iwb+gM6fUV+wqk3k6aTg/gj1oLHoJhZTlW1eJ1sD63OX0UDYFMDSwgEx/svODIHDej8P3wZr7DRMhn07OCxtuIWf28pV3J39r86F2JHE9l8W3/sV7MhVUQmZVZGZcg5KsxEQ= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3258.eurprd07.prod.outlook.com (10.170.244.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.10; Thu, 28 Nov 2019 10:41:42 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac%3]) with mapi id 15.20.2495.014; Thu, 28 Nov 2019 10:41:42 +0000 From: John Mattsson To: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI Thread-Index: AQHVpdhsu+5j4N8dSke7OXT+fIJOeA== Date: Thu, 28 Nov 2019 10:41:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.97] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 322d68e2-8b9d-4118-6534-08d773ef8eb4 x-ms-traffictypediagnostic: HE1PR07MB3258: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(199004)(189003)(5660300002)(6436002)(86362001)(8936002)(81166006)(8676002)(966005)(33656002)(1730700003)(36756003)(2351001)(229853002)(81156014)(6486002)(6246003)(71200400001)(71190400001)(6512007)(6306002)(5640700003)(478600001)(14454004)(6116002)(66066001)(3846002)(186003)(2906002)(316002)(6506007)(58126008)(102836004)(7736002)(26005)(66476007)(99286004)(66556008)(305945005)(44832011)(6916009)(2616005)(76116006)(25786009)(256004)(66446008)(64756008)(66946007)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3258; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ha8VGt46eNUykxaK3NITefDGTd4VwzdGym/5tkGOuHeo+0sOl+NYZwy1vkfK8kFWoXiqBoMybdEDZl7fCrwXWVKnk2xQlNGWqq7eUmP3igFz+SgZHME1FSHkXDFGGyAN6Aj7FtbHmIhs5nWhMU2rf7Jk+Is8E6l9/byZsL6gibnebtcO8QOBYJqNpBGtu5715kYaIKeBt08kzycTKDdjFlzdLzz2cGntbu5KmPRVnJR4jSGlbYOmLN4wr43sLxtijUQ81sQiASPCypEJpEaavHlrhlVZYZ09cDmY2MVpDQvQHxQcJYs46Kkt0dDBicE2VQnjpGuTpcBSrE9ITnTQ98A038O2EPnRkF6Tdk9i9h+DR/B1IfSvcu7uXdF/0X0ciJSpZEpU0U39owuG9KVYqrdLV9X2DdVKa81iArstOVZcf4zNJuDe8eGtTBCt+Jt31Z1HDHiC7UBhuUXcw5Cp6hi26sfslGry5xg631cIB1U= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <330A3144B68FC44D92450CB44CC24562@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 322d68e2-8b9d-4118-6534-08d773ef8eb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2019 10:41:42.3050 (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: lH+VrTwS3KtwDvqk6/9GY8/hx/JvUQsiJ7DW5wDLMWakZzmrs+2/KTexURQCsSbjmmIre2NEJagQJEIkCsNo8j6CcwGzv3mZl5Q/6AcUAK4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3258 Archived-At: Subject: Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI 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, 28 Nov 2019 10:41:47 -0000 SGksDQoNClRoZXJlIGFyZSBub3cgdHdvIHZlcnkgZGlmZmVyZW50IHVzZSBjYXNlcyBvZiB0aGUg d29yZCAnaHlicmlkJyBiZWluZyBkaXNjdXNzZWQgaW4gSVJURi9JRVRGLiANCg0KQ29tYmluYXRp b24gb2YgS0VNICsgREVNOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0 Zi1jZnJnLWhwa2UNCg0KQ29tYmluYXRpb24gb2YgbXVsdGlwbGUgYWxnb3JpdGhtcyBvZiB0aGUg c2FtZSB0eXBlIChLRU0gb3IgU2lnbmF0dXJlKQ0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2Mg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXN0ZWJpbGEtdGxzLWh5YnJpZC1kZXNpZ24NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYWduYS10bHMtYmlrZS1zaWtlLWh5YnJpZA0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBxLXBraXgtcHJvYmxlbS1zdGF0ZW1lbnQN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10cnVza292c2t5LWxhbXBzLXBxLWh5 YnJpZC14NTA5DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb3Vuc3dvcnRoLXBx LWNvbXBvc2l0ZS1zaWdzDQoNCkkgd291bGQgc3VnZ2VzdCB0aGF0IElSVEYvSUVURiBkbyBub3Qg dXNlIHRoZSB3b3JkICdoeWJyaWQnIGZvciBib3RoIG9mIHRoZXNlIGRpZmZlcmVudCBtZWFuaW5n cy4gR2l2ZW4gdGhhdCAnaHlicmlkJyBpcyBxdWl0ZSBlc3RhYmxpc2hlZCBmb3IgdGhlIGNvbWJp bmF0aW9uIG9mIEtFTSArIERFTQ0KDQpodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9IeWJy aWRfY3J5cHRvc3lzdGVtDQoNCmFuZCB0aGUgdXNlIG9mICdoeWJyaWQnIGZvciBQUUMgaXMgcXVp dGUgbmV3IGFuZCBub3QgeWV0IHRoYXQgZXN0YWJsaXNoZWQsIEkgd291bGQgc3VnZ2VzdCB0aGF0 IElSVEYvSUVURiB1c2UgJ2h5YnJpZCcgZm9yIEtFTSArIERFTSBhbmQgYWdyZWUgb24gYW5vdGhl ciB0ZXJtIGZvciB0aGUgUFFDIHVzZSBjYXNlcy4gJ211bHRpcGxlLWFsZ29yaXRobXMnIGFuZCAn Y29tcG9zaXRlJyBoYXMgYmVlbiBtZW50aW9uZWQgaW4gZG9jdW1lbnRzIGFuZCBkaXNjdXNzaW9u cy4gSSB3b3VsZCBiZSBmaW5lIHdpdGggYm90aCBvZiB0aGVzZS4gJ011bHRpcGxlIGVuY3J5cHRp b24nIHNlZW0gdG8gYmUgdGhlIG1vc3QgY29tbW9uIHRlcm0gZm9yIGVuY3J5cHRpbmcgd2l0aCBz ZXZlcmFsIGFsZ29yaXRobXMuDQoNCmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL011bHRp cGxlX2VuY3J5cHRpb24NCg0KQ2hlZXJzLA0KSm9obg0KDQoNCg== From nobody Thu Nov 28 03:17:49 2019 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 B896B120801 for ; Thu, 28 Nov 2019 03:17:48 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=pqshield-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 8-YAauXs8MgG for ; Thu, 28 Nov 2019 03:17:46 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 823E312080C for ; Thu, 28 Nov 2019 03:17:46 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id m125so22370074qkd.8 for ; Thu, 28 Nov 2019 03:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqshield-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1QiOfiMfRauH9mqzz+nExQxkZ645nua71utX7kAsvlM=; b=H7d2BYb8HXkCY5jFdPa80cn5TbJlcS0Rp4hOYwlykRLBcUicP75alMxo84SW/QPCG7 nC5AjgcCt88q8FlUQg3zi5ujTCBj3pBrzCnf/5gIRYMJBOox0CgLcFoAGG8GU6bAVNj7 pyk+nPLpz5F2l4m1iGmMYFUOLzu8r2lGYYfPyTw2IHdSLfkq7YUrSj3MQ10T4YiTFSdf 2tzbjL8R4x1U3cTfdtpmfCvkk8TwSfK5UE+lpxwLLWzR3fCSFPwIzFsX6p3ne1HrnHRb Z86VlewTGsbMweSujW640FZ2h0+WMxA56XjTfRuiXQTOlM22VywenaDYbqI23Z+C368H 5ZTg== 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=1QiOfiMfRauH9mqzz+nExQxkZ645nua71utX7kAsvlM=; b=o+PtTrDmIRDfuPAh2ib0uTry63OI2HdRdEVviVZExiSCQk5fM10lkXe0DGmNOu5lYP IJZ4nvJpA5USpAgewjEiErLgA4Epiio1G2IDHgHue+NWQCWueZwqQ0+uflk+SHZTX7ZF JbMWv6ZtLK77sSZO5bAwerSklqB25KkrX675dNwkJoeSvDiKXTwLKM30s99xPgSG+Oa3 3FsII9dsTyqq4ZrpJ1yD2b214oBnxlbz+Ch4W9uirBO8cLTMAGU7dncm59bGsGtwjWt5 gxc8zIOrBe+M9oVD4VVTTDjsytJ3Z2Wa1/Wf+/Tm+39qHJ3CGpUcIYYPzNhVjxbL6h4O vDoQ== X-Gm-Message-State: APjAAAWUCnxeVMaiy4nBydcj6umgT2PA7q2QUHgW0zZv3kiX8Yki/HH1 vDYSmlh4oouq2uHt/tiKxvWxZC9Fbac/A3SUx1VbtZvzAcE= X-Google-Smtp-Source: APXvYqyWX9Js15uaqg1JiEhPZf+lxT3LyX66V85/VWjT4+nLM4+MMb/b3UCQPRpJhfnMQeFoBXqcguaNBiZ/TiOP0PI= X-Received: by 2002:a37:61c2:: with SMTP id v185mr9758524qkb.429.1574939865385; Thu, 28 Nov 2019 03:17:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Markku-Juhani O. Saarinen" Date: Thu, 28 Nov 2019 11:17:34 +0000 Message-ID: To: John Mattsson Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000381e1805986643cf" Archived-At: Subject: Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI 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, 28 Nov 2019 11:17:49 -0000 --000000000000381e1805986643cf Content-Type: text/plain; charset="UTF-8" Hi, Agree that Hybrid should be PKE/KEM + DEM. That's what I learned in school and that's what cryptography textbooks have said for decades (although the current KEM/DEM terminology is newer). Note that to add to the confusion, NIST discusses "dual signatures" (not to be confused with 1990's SET "dual signatures") in their proposed amendment to the NIST PQC FAQ. Dustin Moody (NIST), October 30: "Is it possible for a dual signature to be validated according to FIPS 140?" https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/qRP63ucWIgs/rY5Sr_52AAAJ Sadly his key-establishment is still "hybrid". Hopefully we can change this. A quick poll in this particular office seems to favour the word "composite" for both key establishment and signatures. Cheers, - markku Dr. Markku-Juhani O. Saarinen PQShield, Oxford UK. On Thu, Nov 28, 2019 at 10:41 AM John Mattsson wrote: > Hi, > > There are now two very different use cases of the word 'hybrid' being > discussed in IRTF/IETF. > > Combination of KEM + DEM: > > https://tools.ietf.org/html/draft-irtf-cfrg-hpke > > Combination of multiple algorithms of the same type (KEM or Signature) > > https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2 > https://tools.ietf.org/html/draft-stebila-tls-hybrid-design > https://tools.ietf.org/html/draft-campagna-tls-bike-sike-hybrid > https://tools.ietf.org/html/draft-pq-pkix-problem-statement > https://tools.ietf.org/html/draft-truskovsky-lamps-pq-hybrid-x509 > https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs > > I would suggest that IRTF/IETF do not use the word 'hybrid' for both of > these different meanings. Given that 'hybrid' is quite established for the > combination of KEM + DEM > > https://en.wikipedia.org/wiki/Hybrid_cryptosystem > > and the use of 'hybrid' for PQC is quite new and not yet that established, > I would suggest that IRTF/IETF use 'hybrid' for KEM + DEM and agree on > another term for the PQC use cases. 'multiple-algorithms' and 'composite' > has been mentioned in documents and discussions. I would be fine with both > of these. 'Multiple encryption' seem to be the most common term for > encrypting with several algorithms. > > https://en.wikipedia.org/wiki/Multiple_encryption > > Cheers, > John > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000381e1805986643cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Agree that Hybrid = should be PKE/KEM=C2=A0+ DEM. That's what I learned in school and that&= #39;s what cryptography textbooks have said for decades (although the curre= nt KEM/DEM terminology is newer).=C2=A0

Note that = to add to the confusion, NIST discusses "dual signatures" (not to= be confused with 1990's SET "dual signatures") in their prop= osed amendment to the NIST PQC FAQ.=C2=A0




Cheers,

On Thu, Nov 28, 2019 at 10:41 AM John Mattsson <john.= mattsson=3D40ericsson.com@= dmarc.ietf.org> wrote:
Hi,

There are now two very different use cases of the word 'hybrid' bei= ng discussed in IRTF/IETF.

Combination of KEM + DEM:

https://tools.ietf.org/html/draft-irtf-cfrg-hpke=

Combination of multiple algorithms of the same type (KEM or Signature)

https://tools.ietf.org/html/draft-t= jhai-ipsecme-hybrid-qske-ikev2
https://tools.ietf.org/html/draft-stebila= -tls-hybrid-design
https://tools.ietf.org/html/draft-cam= pagna-tls-bike-sike-hybrid
https://tools.ietf.org/html/draft-pq-pkix= -problem-statement
https://tools.ietf.org/html/draft-t= ruskovsky-lamps-pq-hybrid-x509
https://tools.ietf.org/html/draft-ounsw= orth-pq-composite-sigs

I would suggest that IRTF/IETF do not use the word 'hybrid' for bot= h of these different meanings. Given that 'hybrid' is quite establi= shed for the combination of KEM + DEM

https://en.wikipedia.org/wiki/Hybrid_cryptosystem

and the use of 'hybrid' for PQC is quite new and not yet that estab= lished, I would suggest that IRTF/IETF use 'hybrid' for KEM + DEM a= nd agree on another term for the PQC use cases. 'multiple-algorithms= 9; and 'composite' has been mentioned in documents and discussions.= I would be fine with both of these. 'Multiple encryption' seem to = be the most common term for encrypting with several algorithms.

https://en.wikipedia.org/wiki/Multiple_encryption

Cheers,
John


_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000381e1805986643cf-- From nobody Thu Nov 28 04:26:13 2019 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 BB81A120848 for ; Thu, 28 Nov 2019 04:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 S83fHQh4SJRY for ; Thu, 28 Nov 2019 04:26:09 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50084.outbound.protection.outlook.com [40.107.5.84]) (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 E3C0F120845 for ; Thu, 28 Nov 2019 04:26:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l8QIhm14J4o3CVRJQdlBSd/JJvZJPJbTrQrNfa6ZQHdlDaGXdxnxVsJXwBDTdzCY5vnyyC2/O3DyPzm5z2yn/KtkaNVzF/YK+e8HzyyEybgV/TLUjnAWHBljHR26rofPhzzD+z18CWalf04wm43jmcPyTZw/OVO/NxqL2kqJ9MX7MRGkmlkH5RCoRO/2vIkj4+i5QgAehYKbXyLZXpGY2NAp2lRUWQKkR/32yeY/ZrwiMPLJOHMdF9HnJPjp9XBZMKxE0K0xvWiiWq+LEVwXymDUlfbHold5IUCurj34foyIa+ECgOIamOpzpjKP/nPgtB8WLs1fHIW6gFOJyirCkQ== 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=yv2wQ4FKWVwT7p/LKWrSwjnY97cGoY04Rx9hBkeUIlo=; b=RuPJ9X9QiTrwsuu06W4UmYAt1rzdEb8fgOEowv36UopogG3zcsmNKGAv0mCKMQ7cq28u3h62xato+pJdykV3aZhNd5mqHtd0Q3BFz2hr5kg6/+HJopKodFM0sSodWiak+Xcc7MRRWwqAPle+6R7vmfiZZZQEsl4+Pi4mynfcbIYjB7C3IzG514axjvNfzZCs9sbvdRPMFFYi+wOjxJu13a0h838eeC0UN/F9Gvn83/W/89wqM3CAsWSKfzK2cLQPKHDLcm0cZ/LSDpa49/bOKb7l9eDjL1DV40jQE6gL7mY+mq1nv+I2RJ3Xwn68GYQqjdq5pMtP8Fe4Gtypc1LF/w== 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=yv2wQ4FKWVwT7p/LKWrSwjnY97cGoY04Rx9hBkeUIlo=; b=HCi0gCHttmP/FLchVN0LYbJm1CMa4dXWOdllB+fjGyveOnV785RWcKSWheIiVL58Q9gH/iq0BvXT9ygtO2u1eWQbIuyDBWD9qyi3Z07oxT7DEPOvQwwOSyiG2bguvyx/+kTj97C+OZqw++rqDXwzW4MWfD9piXKcPkX32eHtKDg= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3403.eurprd07.prod.outlook.com (10.170.244.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.5; Thu, 28 Nov 2019 12:26:06 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac%3]) with mapi id 15.20.2495.014; Thu, 28 Nov 2019 12:26:06 +0000 From: John Mattsson To: "Markku-Juhani O. Saarinen" CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI Thread-Index: AQHVpd1/7lw0Lv5UWEm+bCbLPNVaTKegkwqA Date: Thu, 28 Nov 2019 12:26:06 +0000 Message-ID: <84C6334F-BDB3-40F1-AEB1-6F4B4B4C06C5@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.97] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d3959b4-1556-47df-ece4-08d773fe246f x-ms-traffictypediagnostic: HE1PR07MB3403: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(366004)(346002)(39860400002)(189003)(199004)(6506007)(53546011)(6916009)(8936002)(76176011)(81166006)(81156014)(14444005)(256004)(8676002)(36756003)(25786009)(66946007)(33656002)(478600001)(64756008)(66446008)(99286004)(71190400001)(966005)(5660300002)(7736002)(14454004)(3846002)(86362001)(76116006)(606006)(66476007)(66556008)(6116002)(229853002)(6486002)(58126008)(236005)(6512007)(6246003)(4326008)(6436002)(11346002)(2616005)(26005)(446003)(44832011)(71200400001)(316002)(2906002)(186003)(102836004)(66066001)(54896002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3403; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: i6ekdPvx4U91kyy0oDdABPaATqNyCykKSzHkYB19IlnOJfPLf78XvXSIR9Yqsx1Dqb5vdiaFu/okPRfmbNyyyKe+K1q/bO6urHCnrmD8kLfANVW1VJ8UHaJcA+XnTfWGegpBZ/2uDAWQFnH/G7Vv5HopSvr/JxgmBaUCa7ledeMPNIEc026wElILHgJtah4pvAysFAHtsjuP2w1VDEIo6Fs/QH85CvUGAQwhf+iiUNhfYcqC/3ZxwVQghpaSxmB7ZZDJgtc7mUgdMZ+OyqBJ52PsIlj8gB1lkcQdQIeCEDTWpC+vxGXufrjb3B+eLd2sw2PO90p7qTuXBslI9K1Oskb8rPEfxTEIMx0rnOlfi8oGOBwI7ZelAoARRqdGEC77wSqSk9L+vWikCvlGMFW+VKBTn2p0i9um1WkbTsuuGtiMWL03LSsmCC2ZpKhQH76yV2NozWg9ElKX42DummlYJ3OAxQ9joYbY03ReuLUvfO8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_84C6334FBDB340F1AEB16F4B4B4C06C5ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d3959b4-1556-47df-ece4-08d773fe246f X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2019 12:26:06.4587 (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: h/PjxFfvxUl6YojXhv140ME/w8I6nnz5kqlQPF9991oq3Vkj0qfcWCZHb7nHykbrKnSmFcrN0AkqxEo186tknybwC66bsebFmwoGzkmzSFk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3403 Archived-At: Subject: Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI 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, 28 Nov 2019 12:26:13 -0000 --_000_84C6334FBDB340F1AEB16F4B4B4C06C5ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBiZSBmaW5lIHdpdGggdGhlIHdvcmQg4oCcY29tcG9zaXRl4oCdIGZvciBib3RoIGtl eSBlc3RhYmxpc2htZW50IGFuZCBzaWduYXR1cmVzLg0KDQpBbm90aGVyIHJlYXNvbiDigJxkdWFs 4oCdIGlzIG5vdCBhIGdvb2QgY2hvaWNlIGlzIHRoYXQgbWFueSBvZiB0aGUgc3VnZ2VzdGVkIHNv bHV0aW9ucyBhbGxvdyBtb3JlIHRoYW4gdHdvIGFsZ29yaXRobXMuDQoNCkhvcGVmdWxseSBOSVNU IGFncmVlcyBhbmQgaXMgaGFwcHkgdG8gYWxpZ24gb24gdGVybWlub2xvZ3kgdG9nZXRoZXIgd2l0 aCBJRVRGLiBBcyB5b3UgcG9pbnQgb3V0IHRoZXkgYXJlIGFsc28gdXNpbmcgbXVsdGlwbGUgdGVy bXMgbGlrZSDigJxkdWFs4oCdIGFuZCDigJxoeWJyaWTigJ0uDQoNCkNoZWVycywNCkpvaG4NCg0K RnJvbTogIk1hcmtrdS1KdWhhbmkgTy4gU2FhcmluZW4iIDxtam9zQHBxc2hpZWxkLmNvbT4NCkRh dGU6IFRodXJzZGF5LCAyOCBOb3ZlbWJlciAyMDE5IGF0IDEyOjE4DQpUbzogSm9obiBNYXR0c3Nv biA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+DQpDYzogInNlY2Rpc3BhdGNoQGlldGYub3Jn IiA8c2VjZGlzcGF0Y2hAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1NlY2Rpc3BhdGNoXSBQcm9i bGVtIHN0YXRlbWVudCBmb3IgcG9zdC1xdWFudHVtIG11bHRpLWFsZ29yaXRobSBQS0kNCg0KSGks DQoNCkFncmVlIHRoYXQgSHlicmlkIHNob3VsZCBiZSBQS0UvS0VNICsgREVNLiBUaGF0J3Mgd2hh dCBJIGxlYXJuZWQgaW4gc2Nob29sIGFuZCB0aGF0J3Mgd2hhdCBjcnlwdG9ncmFwaHkgdGV4dGJv b2tzIGhhdmUgc2FpZCBmb3IgZGVjYWRlcyAoYWx0aG91Z2ggdGhlIGN1cnJlbnQgS0VNL0RFTSB0 ZXJtaW5vbG9neSBpcyBuZXdlcikuDQoNCk5vdGUgdGhhdCB0byBhZGQgdG8gdGhlIGNvbmZ1c2lv biwgTklTVCBkaXNjdXNzZXMgImR1YWwgc2lnbmF0dXJlcyIgKG5vdCB0byBiZSBjb25mdXNlZCB3 aXRoIDE5OTAncyBTRVQgImR1YWwgc2lnbmF0dXJlcyIpIGluIHRoZWlyIHByb3Bvc2VkIGFtZW5k bWVudCB0byB0aGUgTklTVCBQUUMgRkFRLg0KDQpEdXN0aW4gTW9vZHkgKE5JU1QpLCBPY3RvYmVy IDMwOiAiSXMgaXQgcG9zc2libGUgZm9yIGEgZHVhbCBzaWduYXR1cmUgdG8gYmUgdmFsaWRhdGVk IGFjY29yZGluZyB0byBGSVBTIDE0MD8iIGh0dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9saXN0 Lm5pc3QuZ292L2QvbXNnL3BxYy1mb3J1bS9xUlA2M3VjV0lncy9yWTVTcl81MkFBQUo8aHR0cHM6 Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/az04ZmUyMDA5Ny1kMzY4Y2E0OS04ZmUyNDAw Yy04NjgyM2UyNzBhNjItODVjMDI4N2NmMGExZDcyMSZxPTEmZT0zMTE3MjYxOC0xZTUzLTQwMTgt OGY4OC1lMWQwNjRlYmUwZjgmdT1odHRwcyUzQSUyRiUyRmdyb3Vwcy5nb29nbGUuY29tJTJGYSUy Rmxpc3QubmlzdC5nb3YlMkZkJTJGbXNnJTJGcHFjLWZvcnVtJTJGcVJQNjN1Y1dJZ3MlMkZyWTVT cl81MkFBQUo+DQoNClNhZGx5IGhpcyBrZXktZXN0YWJsaXNobWVudCBpcyBzdGlsbCAiaHlicmlk Ii4gSG9wZWZ1bGx5IHdlIGNhbiBjaGFuZ2UgdGhpcy4NCg0KQSBxdWljayBwb2xsIGluIHRoaXMg cGFydGljdWxhciBvZmZpY2Ugc2VlbXMgdG8gZmF2b3VyIHRoZSB3b3JkICJjb21wb3NpdGUiIGZv ciBib3RoIGtleSBlc3RhYmxpc2htZW50IGFuZCBzaWduYXR1cmVzLg0KDQpDaGVlcnMsDQotIG1h cmtrdQ0KDQpEci4gTWFya2t1LUp1aGFuaSBPLiBTYWFyaW5lbiA8bWpvc0BwcXNoaWVsZC5jb208 bWFpbHRvOm1qb3NAcHFzaGllbGQuY29tPj4gUFFTaGllbGQsIE94Zm9yZCBVSy4NCg0KDQpPbiBU aHUsIE5vdiAyOCwgMjAxOSBhdCAxMDo0MSBBTSBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29u PTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFy Yy5pZXRmLm9yZz4+IHdyb3RlOg0KSGksDQoNClRoZXJlIGFyZSBub3cgdHdvIHZlcnkgZGlmZmVy ZW50IHVzZSBjYXNlcyBvZiB0aGUgd29yZCAnaHlicmlkJyBiZWluZyBkaXNjdXNzZWQgaW4gSVJU Ri9JRVRGLg0KDQpDb21iaW5hdGlvbiBvZiBLRU0gKyBERU06DQoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLWNmcmctaHBrZQ0KDQpDb21iaW5hdGlvbiBvZiBtdWx0aXBs ZSBhbGdvcml0aG1zIG9mIHRoZSBzYW1lIHR5cGUgKEtFTSBvciBTaWduYXR1cmUpDQoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10amhhaS1pcHNlY21lLWh5YnJpZC1xc2tlLWlr ZXYyDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3RlYmlsYS10bHMtaHlicmlk LWRlc2lnbg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBhZ25hLXRscy1i aWtlLXNpa2UtaHlicmlkDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcHEtcGtp eC1wcm9ibGVtLXN0YXRlbWVudA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRy dXNrb3Zza3ktbGFtcHMtcHEtaHlicmlkLXg1MDkNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1vdW5zd29ydGgtcHEtY29tcG9zaXRlLXNpZ3MNCg0KSSB3b3VsZCBzdWdnZXN0IHRo YXQgSVJURi9JRVRGIGRvIG5vdCB1c2UgdGhlIHdvcmQgJ2h5YnJpZCcgZm9yIGJvdGggb2YgdGhl c2UgZGlmZmVyZW50IG1lYW5pbmdzLiBHaXZlbiB0aGF0ICdoeWJyaWQnIGlzIHF1aXRlIGVzdGFi bGlzaGVkIGZvciB0aGUgY29tYmluYXRpb24gb2YgS0VNICsgREVNDQoNCmh0dHBzOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL0h5YnJpZF9jcnlwdG9zeXN0ZW0NCg0KYW5kIHRoZSB1c2Ugb2YgJ2h5 YnJpZCcgZm9yIFBRQyBpcyBxdWl0ZSBuZXcgYW5kIG5vdCB5ZXQgdGhhdCBlc3RhYmxpc2hlZCwg SSB3b3VsZCBzdWdnZXN0IHRoYXQgSVJURi9JRVRGIHVzZSAnaHlicmlkJyBmb3IgS0VNICsgREVN IGFuZCBhZ3JlZSBvbiBhbm90aGVyIHRlcm0gZm9yIHRoZSBQUUMgdXNlIGNhc2VzLiAnbXVsdGlw bGUtYWxnb3JpdGhtcycgYW5kICdjb21wb3NpdGUnIGhhcyBiZWVuIG1lbnRpb25lZCBpbiBkb2N1 bWVudHMgYW5kIGRpc2N1c3Npb25zLiBJIHdvdWxkIGJlIGZpbmUgd2l0aCBib3RoIG9mIHRoZXNl LiAnTXVsdGlwbGUgZW5jcnlwdGlvbicgc2VlbSB0byBiZSB0aGUgbW9zdCBjb21tb24gdGVybSBm b3IgZW5jcnlwdGluZyB3aXRoIHNldmVyYWwgYWxnb3JpdGhtcy4NCg0KaHR0cHM6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvTXVsdGlwbGVfZW5jcnlwdGlvbg0KDQpDaGVlcnMsDQpKb2huDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNlY2Rpc3Bh dGNoIG1haWxpbmcgbGlzdA0KU2VjZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOlNlY2Rpc3BhdGNo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNw YXRjaA0K --_000_84C6334FBDB340F1AEB16F4B4B4C06C5ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <7E8517B734191841BC46E9EF0C62A47C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+SSB3b3VsZCBiZSBmaW5lIHdpdGggdGhlIHdvcmQg4oCcY29tcG9zaXRl 4oCdIGZvciBib3RoIGtleSBlc3RhYmxpc2htZW50IGFuZCBzaWduYXR1cmVzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFub3RoZXIgcmVhc29uIOKAnGR1YWzigJ0gaXMgbm90IGEg Z29vZCBjaG9pY2UgaXMgdGhhdCBtYW55IG9mIHRoZSBzdWdnZXN0ZWQgc29sdXRpb25zIGFsbG93 IG1vcmUgdGhhbiB0d28gYWxnb3JpdGhtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5Ib3BlZnVsbHkgTklTVCBhZ3JlZXMgYW5kIGlzIGhhcHB5IHRvIGFsaWduIG9uIHRlcm1pbm9s b2d5IHRvZ2V0aGVyIHdpdGggSUVURi4gQXMgeW91IHBvaW50IG91dCB0aGV5IGFyZSBhbHNvIHVz aW5nIG11bHRpcGxlIHRlcm1zIGxpa2Ug4oCcZHVhbOKAnSBhbmQg4oCcaHlicmlk4oCdLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mcXVvdDtN YXJra3UtSnVoYW5pIE8uIFNhYXJpbmVuJnF1b3Q7ICZsdDttam9zQHBxc2hpZWxkLmNvbSZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIDI4IE5vdmVtYmVyIDIwMTkgYXQgMTI6MTg8YnI+ DQo8Yj5UbzogPC9iPkpvaG4gTWF0dHNzb24gJmx0O2pvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29t Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c2VjZGlzcGF0Y2hAaWV0Zi5vcmcmcXVvdDsgJmx0 O3NlY2Rpc3BhdGNoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1NlY2Rp c3BhdGNoXSBQcm9ibGVtIHN0YXRlbWVudCBmb3IgcG9zdC1xdWFudHVtIG11bHRpLWFsZ29yaXRo bSBQS0k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5IaSwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5BZ3JlZSB0aGF0IEh5YnJpZCBzaG91bGQgYmUgUEtFL0tFTSZuYnNwOyYjNDM7IERFTS4g VGhhdCdzIHdoYXQgSSBsZWFybmVkIGluIHNjaG9vbCBhbmQgdGhhdCdzIHdoYXQgY3J5cHRvZ3Jh cGh5IHRleHRib29rcyBoYXZlIHNhaWQgZm9yIGRlY2FkZXMgKGFsdGhvdWdoIHRoZSBjdXJyZW50 IEtFTS9ERU0gdGVybWlub2xvZ3kgaXMgbmV3ZXIpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Ob3RlIHRoYXQgdG8gYWRkIHRvIHRoZSBj b25mdXNpb24sIE5JU1QgZGlzY3Vzc2VzICZxdW90O2R1YWwgc2lnbmF0dXJlcyZxdW90OyAobm90 IHRvIGJlIGNvbmZ1c2VkIHdpdGggMTk5MCdzIFNFVCAmcXVvdDtkdWFsIHNpZ25hdHVyZXMmcXVv dDspIGluIHRoZWlyIHByb3Bvc2VkIGFtZW5kbWVudCB0byB0aGUgTklTVCBQUUMgRkFRLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EdXN0 aW4gTW9vZHkgKE5JU1QpLCBPY3RvYmVyIDMwOiZuYnNwOyZxdW90O0lzIGl0IHBvc3NpYmxlIGZv ciBhIGR1YWwgc2lnbmF0dXJlIHRvIGJlIHZhbGlkYXRlZCBhY2NvcmRpbmcgdG8gRklQUyAxNDA/ JnF1b3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/ az04ZmUyMDA5Ny1kMzY4Y2E0OS04ZmUyNDAwYy04NjgyM2UyNzBhNjItODVjMDI4N2NmMGExZDcy MSZhbXA7cT0xJmFtcDtlPTMxMTcyNjE4LTFlNTMtNDAxOC04Zjg4LWUxZDA2NGViZTBmOCZhbXA7 dT1odHRwcyUzQSUyRiUyRmdyb3Vwcy5nb29nbGUuY29tJTJGYSUyRmxpc3QubmlzdC5nb3YlMkZk JTJGbXNnJTJGcHFjLWZvcnVtJTJGcVJQNjN1Y1dJZ3MlMkZyWTVTcl81MkFBQUoiPmh0dHBzOi8v Z3JvdXBzLmdvb2dsZS5jb20vYS9saXN0Lm5pc3QuZ292L2QvbXNnL3BxYy1mb3J1bS9xUlA2M3Vj V0lncy9yWTVTcl81MkFBQUo8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPlNhZGx5IGhpcyBrZXktZXN0YWJsaXNobWVudCBpcyBzdGlsbCAmcXVv dDtoeWJyaWQmcXVvdDsuIEhvcGVmdWxseSB3ZSBjYW4gY2hhbmdlIHRoaXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkEgcXVpY2sgcG9sbCBpbiB0 aGlzIHBhcnRpY3VsYXIgb2ZmaWNlIHNlZW1zIHRvIGZhdm91ciB0aGUgd29yZCAmcXVvdDtjb21w b3NpdGUmcXVvdDsgZm9yIGJvdGgga2V5IGVzdGFibGlzaG1lbnQgYW5kIHNpZ25hdHVyZXMuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNo ZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0gbWFya2t1PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkRyLiBNYXJr a3UtSnVoYW5pIE8uIFNhYXJpbmVuICZsdDs8YSBocmVmPSJtYWlsdG86bWpvc0BwcXNoaWVsZC5j b20iIHRhcmdldD0iX2JsYW5rIj5tam9zQHBxc2hpZWxkLmNvbTwvYT4mZ3Q7IFBRU2hpZWxkLCBP eGZvcmQgVUsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVGh1LCBOb3YgMjgs IDIwMTkgYXQgMTA6NDEgQU0gSm9obiBNYXR0c3NvbiAmbHQ7am9obi5tYXR0c3Nvbj08YSBocmVm PSJtYWlsdG86NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmciPjQwZXJpY3Nzb24uY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5I aSw8YnI+DQo8YnI+DQpUaGVyZSBhcmUgbm93IHR3byB2ZXJ5IGRpZmZlcmVudCB1c2UgY2FzZXMg b2YgdGhlIHdvcmQgJ2h5YnJpZCcgYmVpbmcgZGlzY3Vzc2VkIGluIElSVEYvSUVURi4NCjxicj4N Cjxicj4NCkNvbWJpbmF0aW9uIG9mIEtFTSAmIzQzOyBERU06PGJyPg0KPGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtY2ZyZy1ocGtlIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtY2ZyZy1ocGtl PC9hPjxicj4NCjxicj4NCkNvbWJpbmF0aW9uIG9mIG11bHRpcGxlIGFsZ29yaXRobXMgb2YgdGhl IHNhbWUgdHlwZSAoS0VNIG9yIFNpZ25hdHVyZSk8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2 MiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10amhh aS1pcHNlY21lLWh5YnJpZC1xc2tlLWlrZXYyPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdGViaWxhLXRscy1oeWJyaWQtZGVzaWduIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXN0ZWJpbGEtdGxzLWh5 YnJpZC1kZXNpZ248L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWNhbXBhZ25hLXRscy1iaWtlLXNpa2UtaHlicmlkIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBhZ25hLXRscy1iaWtlLXNpa2UtaHli cmlkPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1w cS1wa2l4LXByb2JsZW0tc3RhdGVtZW50IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXBxLXBraXgtcHJvYmxlbS1zdGF0ZW1lbnQ8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRydXNrb3Zza3ktbGFtcHMt cHEtaHlicmlkLXg1MDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtdHJ1c2tvdnNreS1sYW1wcy1wcS1oeWJyaWQteDUwOTwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb3Vuc3dvcnRoLXBxLWNvbXBvc2l0 ZS1zaWdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW91bnN3b3J0aC1wcS1jb21wb3NpdGUtc2lnczwvYT48YnI+DQo8YnI+DQpJIHdvdWxkIHN1Z2dl c3QgdGhhdCBJUlRGL0lFVEYgZG8gbm90IHVzZSB0aGUgd29yZCAnaHlicmlkJyBmb3IgYm90aCBv ZiB0aGVzZSBkaWZmZXJlbnQgbWVhbmluZ3MuIEdpdmVuIHRoYXQgJ2h5YnJpZCcgaXMgcXVpdGUg ZXN0YWJsaXNoZWQgZm9yIHRoZSBjb21iaW5hdGlvbiBvZiBLRU0gJiM0MzsgREVNPGJyPg0KPGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvSHlicmlkX2NyeXB0b3N5 c3RlbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0h5YnJp ZF9jcnlwdG9zeXN0ZW08L2E+PGJyPg0KPGJyPg0KYW5kIHRoZSB1c2Ugb2YgJ2h5YnJpZCcgZm9y IFBRQyBpcyBxdWl0ZSBuZXcgYW5kIG5vdCB5ZXQgdGhhdCBlc3RhYmxpc2hlZCwgSSB3b3VsZCBz dWdnZXN0IHRoYXQgSVJURi9JRVRGIHVzZSAnaHlicmlkJyBmb3IgS0VNICYjNDM7IERFTSBhbmQg YWdyZWUgb24gYW5vdGhlciB0ZXJtIGZvciB0aGUgUFFDIHVzZSBjYXNlcy4gJ211bHRpcGxlLWFs Z29yaXRobXMnIGFuZCAnY29tcG9zaXRlJyBoYXMgYmVlbiBtZW50aW9uZWQgaW4gZG9jdW1lbnRz IGFuZCBkaXNjdXNzaW9ucy4NCiBJIHdvdWxkIGJlIGZpbmUgd2l0aCBib3RoIG9mIHRoZXNlLiAn TXVsdGlwbGUgZW5jcnlwdGlvbicgc2VlbSB0byBiZSB0aGUgbW9zdCBjb21tb24gdGVybSBmb3Ig ZW5jcnlwdGluZyB3aXRoIHNldmVyYWwgYWxnb3JpdGhtcy48YnI+DQo8YnI+DQo8YSBocmVmPSJo dHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9NdWx0aXBsZV9lbmNyeXB0aW9uIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvTXVsdGlwbGVfZW5jcnlwdGlv bjwvYT48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KSm9objxicj4NCjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KU2VjZGlzcGF0 Y2ggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+U2VjZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0 Y2g8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_84C6334FBDB340F1AEB16F4B4B4C06C5ericssoncom_-- From nobody Fri Nov 29 16:02:34 2019 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 340A61200CC for ; Fri, 29 Nov 2019 16:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 2vrD0pS_dOv2 for ; Fri, 29 Nov 2019 16:02:29 -0800 (PST) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7706F120033 for ; Fri, 29 Nov 2019 16:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1575072147; bh=4OpZ2aAOC2b9OjL4IPRE9B6dL7SJtM3eDJ12/1Z6L1I=; h=From:Message-Id:Content-Type:Subject:Date:To; b=wD4Mzo1haOSMkK1y0lqPaDwt9r++plCIHGSWc4YjJ/9Ri4UwxrXZ41N1GKKxlmg7S ZUKlJ94c08fYgIxFq47m0A+b5glHqSoyWJvsA7tm22fpnZtMJMtpnrn9fM+BxUZuzo 9aBZiE8CHp+A6uCOqkX7o53mVUy11lTlHHtxVAphxjqj4IAiMij/9hS86QLV8SNfCP GY8p0o4G44VgRK9dUmPGJEqeRm+ZMe+sQIe0unBIye4lu1dSNESnL36urEW55Djoii mVPZAlEoDVzns043Wkp8PYpJoR6rj4jVAix9WErBSIh2resx9nNFnQ49RujPeCZ4Y7 v2NgzhfAwmpkQ== Received: from [192.168.0.26] (cpe-76-169-103-143.socal.res.rr.com [76.169.103.143]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id 06EC17212E3; Sat, 30 Nov 2019 00:02:26 +0000 (UTC) From: Carrick Bartle Message-Id: <60ED5473-66BB-472D-B87E-4E5E245B61CD@icloud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F32FB32C-0395-4713-A223-7CCC086F87EA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Fri, 29 Nov 2019 16:02:26 -0800 In-Reply-To: Cc: "Dr. Pala" , IETF SecDispatch , Nick Sullivan , Tim Hollebeek To: Eric Rescorla References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org> <58FB63D0-58A3-4610-8A86-43D6050C5FAA@icloud.com> X-Mailer: Apple Mail (2.3594.4.19) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-29_08:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911290209 Archived-At: Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare) 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, 30 Nov 2019 00:02:32 -0000 --Apple-Mail=_F32FB32C-0395-4713-A223-7CCC086F87EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > It's probably useful to start with a clear problem statement. Agreed. > if I understood Max's presentation correctly, it's that it's too = expensive to compute all the OCSP signatures. I'm not sure I'm persuaded = that that's true, as public key signatures are very fast (especially if = you use ECDSA) Although the current draft states that it "address(es) the = inefficiencies of OCSPv1 by (a) providing range-based responses to = optimize (reduce) the number of pre-computed responses," my = understanding was that it wasn't to save on computation time = necessarily, but network time and bandwidth. But actually, one common = problem with OCSP is the failure to get any response at all because = responders are sometimes unavailable for one reason or another. So if = the client received a whole batch of revocation data instead of = information only on one certificate, the client could cache and use that = data instead of having to make additional OCSP requests that may never = get responses. Carrick > , and even the largest public CAs don't actually have that many = certificates on the grand scheme of things [0]. However, to the extent = to which it is true, it seems like the natural response would be to move = to a batch signature scheme, such as the one David Benjamin proposed for = TLS [1]. This would have the advantage that it doesn't require any new = protocol definition or reasoning, it's just a drop-in for the existing = signatures. >=20 > -Ekr >=20 > [0] Let's Encrypt has about 10^8 certificates active.. > [1] https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00 = > On Tue, Nov 26, 2019 at 5:42 AM Carrick Bartle = > wrote: > Hi Max, >=20 > What's the current proposal? The draft = doesn't appear to = contain details beyond the notion of providing ranges and information = about the entire chain, and it doesn't seem to address the issues raised = in the PKIX and LAMPS discussions linked here = . >=20 > At Apple, we also cache OCSP responses in a compressed form, i.e. in = Bloom filters. Having the option to receive CRLs in a compressed format = like that would definitely be more efficient for us. I'm not convinced = that ranges would be as helpful. CRLs are helpful when someone is = compiling an entire catalog of revoked certificates. OCSP is helpful = when you want to check the revocation status of one particular = certificate. If OCSP is instead a hybrid of these two approaches, this = assumes that the client is going to want data on the other certificates = in the range they receive (many of which won't even exist, since, as = someone commented in the pkix thread, serial numbers are often = (usually?) randomized). I'm not sure how often that additional = revocation information is actually going to be useful to the client. = Statistics on that is the sort of data that would be helpful in = evaluating this proposal. If it turns out, for instance, that providing = ranges ends up saving only, say, 0.1% of OCSP requests, it probably = wouldn't be worth the effort. >=20 > As for returning revocation data for the entire chain, the question = must be asked: which chain? In some cases, certificates are = cross-signed, and so there is no one chain to provide revocation data = for. Is the client effectively going to delegate finding the best chain = to the OCSP responder? I'm not sure that's in the client's best = interest, and I'm not sure OCSP responders are going to want to bother = handling that. >=20 > Carrick >=20 >=20 >=20 >> On Nov 20, 2019, at 2:47 PM, Dr. Pala > wrote: >>=20 >> Hi Nick, >>=20 >> thanks for the reply. My comments are inline.... >>=20 >> On 11/20/19 1:07 PM, Nick Sullivan wrote: >>> Hi Max, >>>=20 >>> Thanks for your clarification. I now understand the work is aimed at = optimizing the number of signatures by the CA's OCSP responder and the = number of bytes of unique OCSP data. >>>=20 >> Yes, that is correct. The other optimization is about the ability to = provide responses for the whole chain in a single message. >>> Currently, the number of OCSP signatures the CA needs to do is = linear in the number of active certificates. This proposal changes this = so that the number of signatures is linear in the number of revocations = of active certificates. It's conceptually similar to NSEC in that way: = it's a cover proposal in which the artifacts are constant size, but = require a linear number signatures in the size of the revocation set. = Contrast this with CRLs, which require a constant number of signatures, = but are linear in the size of the revocation set. So maybe the goals = could be better phrased in terms of lowering the cost of generating = compared to OCSP and distributing compared to CRLs. >>>=20 >> I am not sure I follow. In PKIs, today, we use both mechanisms. This = is because usually the CRLs are used as a backup mechanism for OCSP - we = also need to support both because of Certification Policies (exactly as = in the Internet PKI environment), therefore it is not a choice :D The = proposed approach can be used to (a) limit the amount of data that needs = to be generated, stored, and transferred when pre-computing responses, = and (b) to compute all responses and serve them from memory - even small = instances without any hardware acceleration could achieve reasonable = performances (also for shorter validity periods in responses). >>> This proposal implies a middle-ground PKI deployment that has enough = revocations for CRL to be inefficient but not enough to cause the = negative space of the serial number to be of the same order as the = number of certificates. It would be great to see examples of PKIs that = motivate this optimization, which is why I suggested that data could = help. >> Technically, you are correct. If we could predict the size of CRLs, = we could potentially try to understand what that threshold is. However, = as I explained in the presentation, the size is fairly unpredictable. = That is why we primarily use OCSP today. >>=20 >>>=20 >>> I should also note that while this proposal reduces the number of = OCSP signatures (which can be on the order of 104 signatures for 2-year = certs), the impact is less dramatic for CAs that issue shorter-lived = certs. For example, Let's Encrypt only signs around 13 OCSP responses = for each of their 3-month certificates. >> That is correct, the impact is less with short-lived certificates = because in those environment, the population of active certificates is = usually smaller. If the population is still large, you still have the = same problem. >>=20 >> You mention that your OCSP responses have a 7 days validity, correct = ? My question is: which considerations went into deciding such a large = validity period for the OCSP responses (7 days) ? Maybe costs = considerations drove the decision ? =46rom a security standpoint, such = long validity periods blinds clients from detecting revocation that = might happen during the 7-days validity period (the problem is worse now = with the deployment of OCSP stapling because clients do not fetch fresh = responses at connect time, AFAIK, if stapling is supported). I would = expect that few minutes validity windows or maybe few hours would be a = better choice - but how much does that cost to Let's Encrypt ? >>=20 >> The Cable industry has used certificates, for few decades now, for = different purposes - as a hardware certification tool and to secure our = networks - in this environment, the typical life-span of a certificate = is many years (up to 20) and it is tied to the envisioned life-span of = the device (no renewal). As you can see, in our environment, CRLs will = never be an option and OCSP simply costs too much (for an infrastructure = that, over all, has an active population of several hundreds million of = active certificates - we might be even beyond that with just the three = OpenCable, PacketCable, and DOCSIS).. >>=20 >> Ultimately, we need to work on the solution so that we can have our = vendors to integrate it in their products, like CableModes, that are = going to be deployed (and provide internet connectivity) for hundreds of = millions of households for the next 10 to 20 years. We need to lower the = security risks associated with the infrastructures that brings Internet = to many of us - revocation is important to prevent possible compromises = to go undetected. I think that everybody who has Cable should support = this work that is going to directly impact them for many years.=20 >>=20 >> Cheers, >> Max >>=20 >> P.S.: I also have other personal motivations for this work. I think = that this is also the right thing to do for non-technical reasons - I = come from the OpenSource world that so much has give for the success of = the Internet but where there is no money. More efficient technologies = could be leveraged by communities around the world who deserve good = security but costs get in the way. I know it is not a technical detail, = but I think we shall always try to have these considerations in our = minds - making the world a better place and less wasteful (energy) is an = amendable goal in general and emerging communities could really benefit = from our work. >>=20 >>=20 >>=20 >>> On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala > wrote: >>> Hi Nick, all, >>>=20 >>> at the end of the second presentation on lowering the costs of = revocation, if I am not mistaken, your question/comment (Nick) was about = the fact that Cloudflare hosts / serve most of the cached OCSP responses = and that the system does not have issues. >>>=20 >>> I am not sure if this comment is pertinent to what we are trying to = solve here... let me elaborate a bit more. >>>=20 >>> The work we have been doing around the proposed topic of work is = aimed at lowering the cost of generating and distributing these large = volumes of signed data when there is actually no need for that. By = optimizing the protocol to provide range responses (or other methods, if = we decide to go with a different approaches), we can reduce the number = of signatures needed from a CA and their distribution - very expensive = operations. >>>=20 >>> In other words, the proposal is not aimed at fixing any caching = issues because, as you noticed in your comment, that works just fine. = The proposal at hand, instead, is about fixing a problem that CAs are = facing today - high costs of deploying and running such systems. >>>=20 >>> On the other hand, your comment made me think about the caching = service you mentioned and its associated costs.=20 >>>=20 >>> Is it a service for which your company charge CAs ? If so, would you = be able to share what are currently the costs incurred by CAs to = leverage your service ? (I totally understand if you are not willing to = - after all, this is usually the secret sauce :D) >>>=20 >>> Last but not least, I also would like to point out that optimizing = the revocation can also help open-source communities, small companies, = universities, non-profit, etc. by enabling them to deploy cost-efficient = systems that can provide good quality of service using less resources = (computational, storage, network). >>>=20 >>> Please let me know, >>>=20 >>> Cheers, >>> Max >>>=20 >>> P.S.: If we could combine this idea with OCSP over DNS, we could = really provide access to revocation technology for everybody, not just = who can afford the price. Unfortunately we know how that discussion = went, and I still think it is a very evident mistake not doing it (I am = still working on this in my spare time - I think it is of enormous value = for emerging countries to have access to cheap secure technologies and, = in my opinion, IETF is dropping / has dropped the ball on this for = not-so-honorable reasons, I suspect...). I hope We can fix it in the = open-source community. >>>=20 >>> --=20 >>> Best Regards, >>> Massimiliano Pala, Ph.D. >>> OpenCA Labs Director >>> >> --=20 >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> >> _______________________________________________ >> 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 = --Apple-Mail=_F32FB32C-0395-4713-A223-7CCC086F87EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
It's probably useful to start = with a clear problem statement.

Agreed.

if I understood Max's presentation correctly, it's that it's = too expensive to compute all the OCSP signatures. I'm not sure I'm = persuaded that that's true, as public key signatures are very fast = (especially if you use ECDSA)

Although the current draft states that = it "address(es) the inefficiencies of OCSPv1 by (a) providing = range-based responses to optimize (reduce) the number of = pre-computed responses," my understanding was that it wasn't to save on = computation time necessarily, but network time and bandwidth. But = actually, one common problem with OCSP is the failure to get any = response at all because responders are sometimes unavailable for one = reason or another. So if the client received a whole batch of revocation = data instead of information only on one certificate, the client could = cache and use that data instead of having to make additional OCSP = requests that may never get responses.

Carrick



, and even the = largest public CAs don't actually have that many certificates on the = grand scheme of things [0]. However, to the extent to which it is true, = it seems like the natural response would be to move to a batch signature = scheme, such as the one David Benjamin proposed for TLS [1]. This would = have the advantage that it doesn't require any new protocol definition = or reasoning, it's just a drop-in for the existing = signatures.

-Ekr

[0] Let's Encrypt has about 10^8 = certificates active..
[1] https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00=

On Tue, Nov 26, 2019 at 5:42 AM Carrick Bartle = <cbartle891=3D40icloud.com@dmarc.ietf.org> wrote:
Hi Max,

What's the current proposal? The draft doesn't appear to contain = details beyond the notion of providing ranges and information about the = entire chain, and it doesn't seem to address the issues raised in the = PKIX and LAMPS discussions linked here.

At Apple, we also cache = OCSP responses in a compressed form, i.e. in Bloom filters. Having the = option to receive CRLs in a compressed format like that would definitely = be more efficient for us. I'm not convinced that ranges would be as = helpful. CRLs are helpful when someone is compiling an entire catalog of = revoked certificates. OCSP is helpful when you want to check the = revocation status of one particular certificate. If OCSP is instead a = hybrid of these two approaches, this assumes that the client is going to = want data on the other certificates in the range they receive (many of = which won't even exist, since, as someone commented in the pkix thread, = serial numbers are often (usually?) randomized). I'm not sure how often = that additional revocation information is actually going to be useful to = the client. Statistics on that is the sort of data that would be helpful = in evaluating this proposal. If it turns out, for instance, that = providing ranges ends up saving only, say, 0.1% of OCSP requests, it = probably wouldn't be worth the effort.

As for returning revocation data for = the entire chain, the question must be asked: which chain? In some = cases, certificates are cross-signed, and so there is no one chain to = provide revocation data for. Is the client effectively going to delegate = finding the best chain to the OCSP responder? I'm not sure that's in the = client's best interest, and I'm not sure OCSP responders are going to = want to bother handling that.

Carrick



On Nov = 20, 2019, at 2:47 PM, Dr. Pala <madwolf@openca.org> wrote:

Hi Nick,

thanks for the reply. My comments are = inline....

On 11/20/19 1:07 PM, Nick Sullivan = wrote:
Hi Max,

Thanks for your = clarification. I now understand the work is aimed at optimizing the = number of signatures by the CA's OCSP responder and the number of bytes = of unique OCSP data.

Yes, that is = correct. The other optimization is about the ability to provide = responses for the whole chain in a single message.
Currently, the number of OCSP signatures the = CA needs to do is linear in the number of active certificates. This = proposal changes this so that the number of signatures is linear in the = number of revocations of active certificates. It's conceptually similar = to NSEC in that way: it's a cover proposal in which the artifacts are = constant size, but require a linear number signatures in the size of the = revocation set. Contrast this with CRLs, which require a constant number = of signatures, but are linear in the size of the revocation set. So = maybe the goals could be better phrased in terms of lowering the cost of generating compared to OCSP = and distributing compared to CRLs.

I am not sure I = follow. In PKIs, today, we use both mechanisms. This is because usually = the CRLs are used as a backup mechanism for OCSP - we also need to = support both because of Certification Policies (exactly as in the = Internet PKI environment), therefore it is not a choice :D The proposed = approach can be used to (a) limit the amount of data that needs to be = generated, stored, and transferred when pre-computing responses, and (b) = to compute all responses and serve them from memory - even small = instances without any hardware acceleration could achieve reasonable = performances (also for shorter validity periods in responses).
This proposal implies a middle-ground PKI = deployment that has enough revocations for CRL to be inefficient but not = enough to cause the negative space of the serial number to be of the = same order as the number of certificates. It would be great to see = examples of PKIs that motivate this optimization, which is why I = suggested that data could help.

Technically, you are correct. If we could = predict the size of CRLs, we could potentially try to understand what = that threshold is. However, as I explained in the presentation, the size = is fairly unpredictable. That is why we primarily use OCSP = today.


I should also note that = while this proposal reduces the number of OCSP signatures (which can be = on the order of 104 signatures for 2-year certs), the impact is less = dramatic for CAs that issue shorter-lived certs. For example, Let's = Encrypt only signs around 13 OCSP responses for each of their 3-month = certificates.

That is correct, the impact is less with = short-lived certificates because in those environment, the population of = active certificates is usually smaller. If the population is still = large, you still have the same problem.

You mention that your OCSP responses have = a 7 days validity, correct ? My question is: which considerations went = into deciding such a large validity period for the OCSP responses (7 = days) ? Maybe costs considerations drove the decision ? =46rom a = security standpoint, such long validity periods blinds clients from = detecting revocation that might happen during the 7-days validity period = (the problem is worse now with the deployment of OCSP stapling because = clients do not fetch fresh responses at connect time, AFAIK, if stapling = is supported). I would expect that few minutes validity windows or maybe = few hours would be a better choice - but how much does that cost to = Let's Encrypt ?

The Cable industry has used certificates, = for few decades now, for different purposes - as a hardware = certification tool and to secure our networks - in this environment, the = typical life-span of a certificate is many years (up to 20) and it is = tied to the envisioned life-span of the device (no renewal). As you can = see, in our environment, CRLs will never be an option and OCSP simply = costs too much (for an infrastructure that, over all, has an active = population of several hundreds million of active certificates - we might = be even beyond that with just the three OpenCable, PacketCable, and = DOCSIS)..

Ultimately, we need to work on the = solution so that we can have our vendors to integrate it in their = products, like CableModes, that are going to be deployed (and provide = internet connectivity) for hundreds of millions of households for the = next 10 to 20 years. We need to lower the security risks associated with = the infrastructures that brings Internet to many of us - revocation is = important to prevent possible compromises to go undetected. I think that = everybody who has Cable should support this work that is going to = directly impact them for many years. 

Cheers,
Max

P.S.: I also have other personal = motivations for this work. I think that this is also the right thing to = do for non-technical reasons - I come from the OpenSource world that so = much has give for the success of the Internet but where there is no = money. More efficient technologies could be leveraged by communities = around the world who deserve good security but costs get in the way. I = know it is not a technical detail, but I think we shall always try to = have these considerations in our minds - making the world a better place = and less wasteful (energy) is an amendable goal in general and emerging = communities could really benefit from our work.


On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <madwolf@openca.org> wrote:

Hi = Nick, all,

at the end of the second presentation on = lowering the costs of revocation, if I am not mistaken, your = question/comment (Nick) was about the fact that Cloudflare hosts / serve = most of the cached OCSP responses and that the system does not have = issues.

I am not sure if this comment is pertinent to = what we are trying to solve here... let me elaborate a bit more.

The work we have been doing around the proposed topic of work = is aimed at lowering the cost of generating and distributing these large volumes of signed data when there is actually no need for that. By = optimizing the protocol to provide range responses (or other methods, if = we decide to go with a different approaches), we can reduce the number = of signatures needed from a CA and their distribution - very expensive = operations.

In other words, the proposal is not aimed at fixing = any caching issues because, as you = noticed in your comment, that works just fine. The proposal at hand, = instead, is about fixing a problem that CAs are facing today - high = costs of deploying and running such systems.

On the = other hand, your comment made me think about the caching service you = mentioned and its associated costs. 

Is it a service for which your company = charge CAs ? If so, would you be able to share what are currently the = costs incurred by CAs to leverage your service ? (I totally understand = if you are not willing to - after all, this is usually the secret sauce = :D)

Last but not least, I also would like to point out = that optimizing the revocation can also help open-source communities, = small companies, universities, non-profit, etc. by enabling them to = deploy cost-efficient systems that can provide good quality of service = using less resources (computational, storage, network).

Please let me know,

Cheers,
Max

P.S.: If we could = combine this idea with OCSP over DNS, we could really provide access to = revocation technology for everybody, not just who can afford the price. = Unfortunately we know how that discussion went, and I still think it is = a very evident mistake not doing it  (I am still working on this in = my spare time - I think it is of enormous value for emerging countries = to have access to cheap secure technologies and, in my opinion, IETF is = dropping / has dropped the ball on this for not-so-honorable reasons, I = suspect...). I hope We can fix it in the open-source community.

-- 
Best Regards,
Massimiliano Pala, = Ph.D.
OpenCA Labs Director
<dhmacjdifkefaoin.png>
-- 
Best Regards,
Massimiliano Pala, = Ph.D.
OpenCA Labs Director
<ijeffbhlgncflbab.png>
_______________________________________________
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

= --Apple-Mail=_F32FB32C-0395-4713-A223-7CCC086F87EA--