From nobody Fri Nov 1 15:00:03 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:15 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:10 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:31 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522DD12008B 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 IMNcPpg-xi-l for ; Sat, 2 Nov 2019 20:18:28 -0700 (PDT) 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 992F2120013 for ; Sat, 2 Nov 2019 20:18:28 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id a194so14330465qkg.10 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=GbNXG/1n+SeahhtwxRdQVjLMPYz9/SDr6wesJ2aesuQXBtob1eq2HBhbBqYgfpi2eX 7FztiNyoA8UboTIjYqggr+595wPv3QM2krhRHCSnlAjqSowp5GWmL0p8VYnoxh3SUHWa gAovv+ocWf2w00geQfzJYBvf9m+b4pDZoD3m1FiCKSVTojDfDP1ocskjnlqZPY1v8fTa EJ0Aj6t5NNCKgbgKurL9GHp54w42G439fJDzH1fmd3dHcyktoJHXLIe0UxEA1adP6trC FZA3R4DoP4LPHkqafa75K1kZTb+mDelDxjX6nM6nsnvHbF/orCdGUlkLzPPalafHXmZ0 ZEuw== X-Gm-Message-State: APjAAAXItxxKprJahtTW9gs7ZdFo99ow4jvVkSGh7JGZGnr5BXfW82Tu e5trGDlJfGjEpsg6fS+1j9pz0M9yvSzacYouajAuQQ== 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: [dispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:25 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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 Mon Nov 4 05:44:38 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] [Secdispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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 12:03:12 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:05 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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 09:00:07 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] [Secdispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:49 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] [Secdispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:13 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] [Secdispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:41 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] [Secdispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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:30 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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: [dispatch] [Secdispatch] HTTP Request Signing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List 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 6 12:04:19 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC411200E7; Wed, 6 Nov 2019 12:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 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] 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 jHMyIOdhFgRB; Wed, 6 Nov 2019 12:04:15 -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 DDBC31200A4; Wed, 6 Nov 2019 12:04:15 -0800 (PST) Received: from [172.20.10.2] (mobile-166-171-58-118.mycingular.net [166.171.58.118]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xA6K48D0088395 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Nov 2019 14:04:11 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1573070653; bh=4V9wV2XOypmw1qqJgsanv7gg1XYe5JSpvpWhto3AlZY=; h=From:Subject:Date:Cc:To; b=doLnlXYQwtvXN222SqQ2/P2WhglPyq1LgMC8I8GMgFPiKeTRqJuiP6guAfgAOQQv3 obCEK9dt5H7vBS+5pI2gBYVHn/F9htMEGUQrRMOAokkde0v8QOuFsrWHGLFDDxgNET ndbWoiv+Dy13+bPcyMT2nGJgMjzSoX2HEeQTCZFE= X-Authentication-Warning: raven.nostrum.com: Host mobile-166-171-58-118.mycingular.net [166.171.58.118] claimed to be [172.20.10.2] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_015E5569-B3BA-45EF-8DD7-0EF6ECEDB63C" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: Date: Wed, 6 Nov 2019 15:04:03 -0500 Cc: Mary Barnes , ART ADs To: dispatch@ietf.org X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [dispatch] Draft Agenda for IETF106 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 20:04:17 -0000 --Apple-Mail=_015E5569-B3BA-45EF-8DD7-0EF6ECEDB63C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Everyone, A draft agenda for the IETF106 DISPATCH meeting is available at = https://datatracker.ietf.org/meeting/106/materials/agenda-106-dispatch-01 = , and copied below for convenience. Please send any omissions, = updates, or other comments to the chairs and the dispatch list as soon = as possible. Thanks! Ben. ---------=09 # DRAFT Agenda DISPATCH @IETF-106 - v2 DISPATCH Meeting=20 ---------------- ### Status and Agenda Bash - Chairs and ADs (15 min) ### Real Time Internet Peering Protocol (RIPP) - Cullen Jennings (30 = min) = [Draft](https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ripp-= 03) ### Automatic Peering for SIP Trunks - Kaustubh Inamdar/Sreekanth = Narayanan(30 min) = [Draft](https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-= 00) ART AREA Meeting=20 ---------------- ### BoFs and meetings of interest - ADs and BoF Chairs (15 min) ### Web Push for IMAP/CalDAV/CardDAV - Bron Gondwana (10 min) = [Discussion](https://mailarchive.ietf.org/arch/msg/dispatch/gU2cWDGgxc-1O1= xAubdIxNeeo58) =20 [Web Push for = CalDAV/CardDaV](https://datatracker.ietf.org/doc/draft-gajda-dav-push/) =20= [Pre-draft IMAP = proposal](https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md= ) ### HTTP Request Signing - Justin Richer - (5 min) Quick description of work. Full discussion to be held in SECDISPATCH = (Tuesday 17:10 Padang) =20 [Draft](https://tools.ietf.org/html/draft-cavage-http-signatures) ### AOB --Apple-Mail=_015E5569-B3BA-45EF-8DD7-0EF6ECEDB63C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Everyone,

A draft = agenda for the IETF106 DISPATCH meeting is available at https://datatracker.ietf.org/meeting/106/materials/agenda-106-d= ispatch-01 , and copied below for convenience. Please send any = omissions, updates, or other comments to the chairs and the dispatch = list as soon as possible.

Thanks!

Ben.


--------- =

# DRAFT Agenda DISPATCH @IETF-106 - v2
DISPATCH Meeting 
----------------

### Status and Agenda Bash - Chairs and ADs (15 = min)

### Real = Time Internet Peering Protocol (RIPP) - Cullen Jennings (30 = min)

[Draft](https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ri= pp-03)

### = Automatic Peering for SIP Trunks - Kaustubh Inamdar/Sreekanth = Narayanan(30 min)

[Draft](https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-pe= er-00)

ART = AREA Meeting 
----------------

### BoFs and meetings of = interest - ADs and BoF Chairs (15 min)

### Web Push for IMAP/CalDAV/CardDAV - = Bron Gondwana (10 min)

[Discussion](https://mailarchive.ietf.org/arch/msg/dispatch/gU2cWDGgxc-1O1xA= ubdIxNeeo58)  
[Web Push for = CalDAV/CardDaV](https://datatracker.ietf.org/doc/draft-gajda-dav-push/) =  
[Pre-draft IMAP proposal](https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.m= d)

### = HTTP Request Signing - Justin Richer - (5 min)

Quick description of work. Full = discussion to be held in SECDISPATCH (Tuesday 17:10 Padang) =  
[Draft](https://tools.ietf.org/html/draft-cavage-http-signatures)

### = AOB

= --Apple-Mail=_015E5569-B3BA-45EF-8DD7-0EF6ECEDB63C-- From nobody Mon Nov 11 12:37:08 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460E4120119; Mon, 11 Nov 2019 12:37:06 -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, KHOP_HELO_FCRDNS=0.4, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 r1unp1ipyaY2; Mon, 11 Nov 2019 12:37:05 -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 E270C120046; Mon, 11 Nov 2019 12:37:04 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xABKZbVF016458 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Nov 2019 14:37:02 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1573504623; bh=8Dj1K3lR6tz7V/eh3LwDHIAq+j4uoZC2KulY54d8I3A=; h=From:Subject:Date:Cc:To; b=hy4LGHSKOY/w2a/O+JDtSlEAu80s450srs+hOvXZ3KM1prU+MHVpFg83QWQ5gh1c2 HL4mqJZoRZ6RdWfp8lOUS91TTRrQF6EfoKWGp4qyx/nokEuAYpLJp5kIvbo0bkP9gM mGSz34rjxMZMwnrfuo3RcL5SOAncRMK2b9Apu3r8= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <97CAC086-BCB1-4077-99C3-7BE98E374ED2@nostrum.com> Date: Mon, 11 Nov 2019 14:37:01 -0600 Cc: Mary Barnes , ART ADs To: dispatch@ietf.org X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [dispatch] Final Dispatch Agenda for Singapore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 20:37:06 -0000 Hi, The final(ish) DISPATCH agenda is available at = https://datatracker.ietf.org/meeting/106/materials/agenda-106-dispatch-03.= I=E2=80=99ve copied it below for your convenience. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 # Agenda DISPATCH @IETF-106 - v3 DISPATCH Meeting=20 ---------------- ### Status and Agenda Bash - Chairs and ADs (15 min) ### Real Time Internet Peering Protocol (RIPP) - Cullen Jennings (30 = min) = [Draft](https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ripp)= ### Automatic Peering for SIP Trunks - Kaustubh Inamdar/Sreekanth = Narayanan(30 min) = [Draft](https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer)= ART AREA Meeting=20 ---------------- ### BoFs and meetings of interest - ADs and BoF Chairs (15 min) ### Web Push for IMAP/CalDAV/CardDAV - Bron Gondwana (10 min) = [Discussion](https://mailarchive.ietf.org/arch/msg/dispatch/gU2cWDGgxc-1O1= xAubdIxNeeo58) =20 [Web Push for = CalDAV/CardDaV](https://datatracker.ietf.org/doc/draft-gajda-dav-push/) =20= [Pre-draft IMAP = proposal](https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md= ) ### HTTP Request Signing - Justin Richer - (5 min) Quick description of work. Full discussion to be held in SECDISPATCH = (Tuesday 17:10 Padang) =20 [Draft](https://tools.ietf.org/html/draft-cavage-http-signatures) ### AOB From nobody Wed Nov 13 19:19:55 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B0C12007A; Wed, 13 Nov 2019 19:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 LJbrJEUQDmI6; Wed, 13 Nov 2019 19:19:51 -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 3860F12006B; Wed, 13 Nov 2019 19:19:51 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAE3JmrS041378 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Nov 2019 21:19:49 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1573701589; bh=F9z2CFYHIO+HmAo+YBKv86GklHkac5JYc06yiAAiwqQ=; h=From:Subject:Date:Cc:To; b=mk1MtABk8HwgJIyCV4O1rMUey3b+TQn1bv/kb8QQANaOTh6BflJQTYbSanfoIxyIt JHY73KbCtMb07yFpZkmkdZWskltuG2Ox8KvSPN5v+Pcr3ZTx0eXJIx0/VMV+eICpnc p1KOPsYS64EgjNS+ak62gDdFXyla1jfsedqLx3W0= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <4585BAF9-62FB-40E1-AC84-83558D2E9354@nostrum.com> Date: Wed, 13 Nov 2019 21:19:42 -0600 Cc: dispatch-chairs@ietf.org To: dispatch@ietf.org X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [dispatch] Note Takers/Jabber Relay X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 03:19:53 -0000 Hi, DISPATCH will meet in the first regular slot on Monday morning. So that = we can get things started on time, it would be extremely helpful if we = can get some volunteers in advance of the meeting. We need at least one, = and preferably 2 volunteers to take notes, and 1 to act as Jabber relay. For notes, we mainly need to capture decisions and action items. Any = further details are at the note taker=E2=80=99s discretion. For the Jabber relay, we need someone to bring any questions/comments = from the chatroom to the microphone. It can sometime be helpful to = identify speakers. These days, most people seem to use MeetEcho, so = there=E2=80=99s not as many Jabber room comments as there used to be. Volunteers will be rewarded with our undying gratitude. Thanks in advance! Ben. From nobody Sun Nov 17 06:37:59 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092AA12006D; Sun, 17 Nov 2019 06:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Kxy6unvOjGt4; Sun, 17 Nov 2019 06:37:56 -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 794461200FA; Sun, 17 Nov 2019 06:37:56 -0800 (PST) Received: from dhcp-9ac2.meeting.ietf.org (dhcp-9ac2.meeting.ietf.org [31.133.154.194]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAHEbq6v062590 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 17 Nov 2019 08:37:54 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1574001475; bh=twkknCDHrGbfH/EzP6/xAEB8iH3z8yquZkgRVXzQt1Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GLVUDolx+/68xmuDIq8FVb1f/Tss/uMgI/tM8SL+tb7T127W7w5ASyjW9LQNZNLkF 2ZsO7hQUc5M+3/my0Tjw/63sFn9mqYZZ8Fj9a7EyeXPQDKAP4vIHuINtANJLi26jH1 83LL0fJb5vp1GrCDbg95yywqNIpMs8y8o1cOV56I= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Ben Campbell In-Reply-To: <4585BAF9-62FB-40E1-AC84-83558D2E9354@nostrum.com> Date: Sun, 17 Nov 2019 22:37:45 +0800 Cc: dispatch-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <70063FDD-FEA2-4562-A5BE-0BD2862B1EC7@nostrum.com> References: <4585BAF9-62FB-40E1-AC84-83558D2E9354@nostrum.com> To: dispatch@ietf.org X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [dispatch] Note Takers/Jabber Relay X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 14:37:58 -0000 Pretty please? Ben. > On Nov 14, 2019, at 11:19 AM, Ben Campbell wrote: >=20 > Hi, >=20 > DISPATCH will meet in the first regular slot on Monday morning. So = that we can get things started on time, it would be extremely helpful if = we can get some volunteers in advance of the meeting. We need at least = one, and preferably 2 volunteers to take notes, and 1 to act as Jabber = relay. >=20 > For notes, we mainly need to capture decisions and action items. Any = further details are at the note taker=E2=80=99s discretion. >=20 > For the Jabber relay, we need someone to bring any questions/comments = from the chatroom to the microphone. It can sometime be helpful to = identify speakers. These days, most people seem to use MeetEcho, so = there=E2=80=99s not as many Jabber room comments as there used to be. >=20 > Volunteers will be rewarded with our undying gratitude. >=20 > Thanks in advance! >=20 > Ben. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Nov 17 19:51:25 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BC8120875 for ; Sun, 17 Nov 2019 19:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-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=DijE+bWY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Pv4kO4Dm 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 5IQDkvs6EvHV for ; Sun, 17 Nov 2019 19:51:16 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FBC120855 for ; Sun, 17 Nov 2019 19:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=134; q=dns/txt; s=iport; t=1574049076; x=1575258676; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0mAzfZuOkMSQii63hhdwCB8+cX6eYPbBkj8zJJPKV+k=; b=DijE+bWYoFxGQwWSX7GvYZtEF67dWDLy7F+xQNHyOAcLTqnp5IMVpDUA vBlrXkkehgYCULgZgHXftohACXkvUHVt3GeuoDZy69PACwk4uwsWsdqRt u/x33ZplujmNVuuyLF4sKrDWiEkWTdJw5VinAR3BaSoTDJmPqIAJ+jvee k=; IronPort-PHdr: =?us-ascii?q?9a23=3AtAN36ByWdm/0PMbXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuLDVD1Iu/CZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAADiFNJd/4gNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYFqCAELAYFKUAWBRCAECyqHcAOEWoYVTpoQgS6BJANUCQEBAQwBAS0CAQG?= =?us-ascii?q?GZSQ0CQ4CAwsBAQQBAQECAQUEbYU3AQuFaigGAQE4EQE9AUInBDWDAIJHAy4?= =?us-ascii?q?BogoCgTiIYIIngn4BAQWCSYI0GIIXCYE2AYwUGIF/gREnH4MKiAeCLK4tCoI?= =?us-ascii?q?qlU8bgi4Bl2KOSJZsgxwCBAIEBQIOAQEFgVI5gVhwFWUBgkE+EhEUkRqDc4p?= =?us-ascii?q?TdIEojTgBAQ?= X-IronPort-AV: E=Sophos;i="5.68,318,1569283200"; d="scan'208";a="666779225" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2019 03:51:15 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xAI3pFGq022017 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 Nov 2019 03:51:15 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Nov 2019 21:51:14 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Nov 2019 21:51:14 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 17 Nov 2019 21:51:14 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TQ7QkCY8DwKYiII08SzvNy+4WqCpGU/T16/miqoeFOOzNbKCgA/Dz1no+oiGYMdUT2VAVaRgFvy2hbk9forvxEKROHZit07G4snamGs7TMY8uPpUebAorsYBgPxUKVxOPiZPYSsWbxzRdEKMG26Fmo7u5Kwhd/h+NFwc+lGZOsi9a1SfxRRCwSjwl7ZNtTWqGfCpFQnbHlKaWTZ7YhmoekUH+gyHFj0hQYVUgY9ZeUjUPgeIzBpQI1EwiQafaul7n0bTAIQG/87aMGnDDqD5VHXY9qJ6KG4Lqbafbbq64Stz5Rr4cXknN4QAkt/Q8czEbm4B9HonPwGVnrxsRswLqQ== 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=0mAzfZuOkMSQii63hhdwCB8+cX6eYPbBkj8zJJPKV+k=; b=ddVIcctKgAsq9KrSO/KZF3+wyNFzU1k58zx2mQ/ODDvSrdp0V1+9buxGmBwbqeNLOv8hI9OQDp6IoPsb00/g5VdieZ8EwdfdrXoFrDAFuErqjFf2vrDTVhfJ4KnCLqCVud0Ad4pMoiTpv7/I3/uCLFdB2VPWsExsaJlYReaG4YAEhKPuWx4MSh0LgUG447xPNKQM0fHmf28Sz57j6Oy4t8AyIwQXJJqTYdiEySiJmic4jWIjpSxr394DPrZyyp2jftsPB6Ivnqhss9vfef5sT1rvrZ5SUly5qn5TRbV9yYCJMGJF2EdyLq+G9K0oINhipZGDP4NqSrOIvi+BHFXrkw== 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=0mAzfZuOkMSQii63hhdwCB8+cX6eYPbBkj8zJJPKV+k=; b=Pv4kO4Dmeu0SELC4zCMOuC6xOohPUfGdUL+RPHkYadkztY8WaSDSvCxHzbQrBtpioNBTqGCE8sI94axnV8kvxBo25wlf/OcUdM0Xfoikn+5P8nMmqMrUU5pIYrK2TJyc/C6pqTBtR4KGH31KgGHJgP40rkXw43eq/lPUip/REjY= Received: from MWHPR11MB1565.namprd11.prod.outlook.com (10.172.54.21) by MWHPR11MB1999.namprd11.prod.outlook.com (10.169.232.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Mon, 18 Nov 2019 03:51:13 +0000 Received: from MWHPR11MB1565.namprd11.prod.outlook.com ([fe80::316e:f8ab:db77:40f3]) by MWHPR11MB1565.namprd11.prod.outlook.com ([fe80::316e:f8ab:db77:40f3%10]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 03:51:13 +0000 From: "Cullen Jennings (fluffy)" To: "dispatch@ietf.org" Thread-Topic: RIPP Side Meeting Thursday at 8:30 Sophia Thread-Index: AQHVncNrYj0+Ka3GkUGV6B0K1Z4CPA== Date: Mon, 18 Nov 2019 03:51:13 +0000 Message-ID: <14B97086-B1BC-4A84-AF6A-0C64A0C3D8F2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.11) authentication-results: spf=none (sender IP is ) smtp.mailfrom=fluffy@cisco.com; x-originating-ip: [2001:420:c0d4:1001::13c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 690751e0-6e79-4824-4c43-08d76bda8e8a x-ms-traffictypediagnostic: MWHPR11MB1999: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(396003)(39860400002)(136003)(189003)(199004)(256004)(486006)(6486002)(33656002)(2501003)(46003)(25786009)(478600001)(66476007)(50226002)(5640700003)(5660300002)(6436002)(476003)(102836004)(6512007)(6506007)(2906002)(1730700003)(66946007)(66446008)(64756008)(66556008)(81166006)(8936002)(2616005)(81156014)(8676002)(71190400001)(6116002)(305945005)(7736002)(91956017)(76116006)(6916009)(71200400001)(186003)(99286004)(558084003)(36756003)(14454004)(86362001)(2351001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1999; H:MWHPR11MB1565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: ivhS9uGCMbgV6nBhqgL8T4yVoM/THRVKSVzvFRIK83iN3Jfk4cuQcdKfewV8kmCpkWfXA1yrepYZ5WQ3WaJwFYGrFh06XF6IaYDP+oe7T0bKelshUNR2wN/7I1SexA7vUAQGDDvOb2uHufH0+HBHaHi8vjZvTe55Dm2WBfnyUz+84PmCBTv6lXA8Utbg7AFDm+PzOctIEGU7I+XimzRJLUzj5NwaDaYKJ+S5i6qVrTYhWitXphvZpOal6B49PgZeQqR1T0c63awI3hrfAORy1Z/jyuQYj4ECBeB3l3I3OrgGt9C1NgGe7mwOoRr18+vlNA+druCKUM61pfXE9M/BLkegn0vhumze6Asvi4jvfnoGVBmWNRje08tsZin8MxqeextC5nyYrm/jY4fBu0z93ebuCae6cd2siJtS+nJ8uddts9sy8CdNGzjDz5IqBQKI Content-Type: text/plain; charset="us-ascii" Content-ID: <81C706357CD4684A982DA811C3655B4E@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 690751e0-6e79-4824-4c43-08d76bda8e8a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 03:51:13.4075 (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: EHZ1wbAIS/T7ZFLeEksGgtrCjV10s+LslbtNijmAYjHNU6Zow/xm7rN9xea9ZEvqBgfaXkF8alfQgQiys0ZoYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1999 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: [dispatch] RIPP Side Meeting Thursday at 8:30 Sophia X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 03:51:25 -0000 We can meet 8:30 Thursday in Sophia room to talk more about what should be = in a charter for the RIPP work.=20 Thanks, Cullen From nobody Tue Nov 19 19:25:55 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C552120271 for ; Tue, 19 Nov 2019 19:25:53 -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, 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 HI0VzbdxwnPM for ; Tue, 19 Nov 2019 19:25:50 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E391202A0 for ; Tue, 19 Nov 2019 19:25:50 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id d29so13117095plj.8 for ; Tue, 19 Nov 2019 19:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=n0BdvvVhnxjgZkXK0aQC32F3fK2+MCU0fVQApSmRpdw=; b=kyVtNEiZUa1BNv1C/Qrf6sMyeiKuo0n+UWCmsF/r23lwh4KTCX2MwxOEtClZ4KqnH5 ivFNEHz6nf+Zd4ztE+5ayy8n4kVDQFTKAbKWeX9Ob6hnNNlEiXmSXvj4LhWdzH0YqKEe CrczEyN8ArMBpWn4xTHvEXeae/ofzVI0JJ4+Ih/ZB7NWQkqWahXq8BYzX5jYuVIyyNdw 9p2SNKOumnE68zEac7Q2OAgcW56i5wZVfdfIlH1GkYrRUC8yiHLPUsI43myCgODsem/T hHJLIKxBWnih5i7Lz2OZugRcFi/WQUiI1OMRaLdL2yQFly2OvpGTheSC77ZCKfNmLlVl Rcuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=n0BdvvVhnxjgZkXK0aQC32F3fK2+MCU0fVQApSmRpdw=; b=etKuiBOUtp5g98UlqATrFNP7VjEHCersv3Dr/37oYDBtGNzRJmz2lGqUEcEmRxZtvo YMfdDhww5bn0OMaAdxokNykQefo2HdIHsn1RFOtfW7FuybuM5/KaMlYp6E7rT09H4l6Q IWDd7kyoancShbQ9omRn3WvWmzJKvWJOvnXD1ppmF1h7d0Wl9JoJmT14F2yNfrf/HlSy bs36e6wh9HiI0A1lYS3Jkz1DWC69jV2n92oxdQ9wYUENdZ7KhRIJxibf/t1zXGxKyegp /YmMyJiyAL92ysaTorOB+s+XoUtkFkQJ+S22wI8K2ic36yWsZNF8yk3uFnsYxzbg0HjT VX/g== X-Gm-Message-State: APjAAAUn8U2RzhS/QpH3Ep3YbRVkfi5tg0sQvqm3mXTvwVD7fzXwcpau IK8Jt/pDmkPZQ5GD4qg9OxdhGt13 X-Google-Smtp-Source: APXvYqy1TO5GB5OpnlGgdq4AsMROePm017kTMzOffV4YV6Au3C2rVQP5jIiQ9Ip5WVgar/Wq/QdCmw== X-Received: by 2002:a17:902:7893:: with SMTP id q19mr677689pll.130.1574220349998; Tue, 19 Nov 2019 19:25:49 -0800 (PST) Received: from [172.16.103.176] (c-71-202-89-74.hsd1.ca.comcast.net. [71.202.89.74]) by smtp.gmail.com with ESMTPSA id a66sm28052540pfb.166.2019.11.19.19.25.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Nov 2019 19:25:49 -0800 (PST) From: Michael Toomim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 19 Nov 2019 19:25:48 -0800 To: HTTP Working Group , dispatch@ietf.org, Braid-HTTP Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dispatch] Fresh Braid Release! X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 03:25:53 -0000 Hey Singapore-- I'm stoked to announce a new version of the Braid spec! There was considerable interest in draft-toomim-braid-00 in Montreal, = which helped illuminate some issues while attracting new contributors. = Together we have now rewritten the spec, and addressed the issues! We = want to hear what you think! Braid is a set of extensions that generalize HTTP [RFC7230] from a state = *Transfer* to a state *Synchronization* protocol: Braid-HTTP: = https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http Range Patch: = https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-range-patch Merge-Types: = https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-merge-types The Braid extensions add these features: 1. Versioning for resources 2. Subscriptions for GET requests 3. Patches built on Range Requests 4. Merge-Types that specify OT or CRDT behavior These features enable: =E2=80=A2 Realtime updates via dynamic proxies =E2=80=A2 Offline mode =E2=80=A2 Collaborative editing =E2=80=A2 Version-control =E2=80=A2 Eventual consistency under multiple writers The new Braid draft builds on existing HTTP features -- a big = improvement, IMO. It turns out that HTTP [RFC7230] through [RFC7234] is = very close to synchronization already -- it just needs a few things. = The Braid extensions complete synchronization with 5 new headers, 1 new = response code, 2 range units, and 1 new registry. In the process, it = generalizes Range Requests [RFC7234] in a cool way, creating a uniform = patch format for any existing Range Unit. And guess what? Well, it = turns out that Julian Reschke and others had this idea in 2008: = https://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0304.html, = and Austin Wright had a complementary idea -- using Range Requests to = upload large files with resume support -- just this last summer: = https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0066.html. = Braid supports both situations. The group of Braid contributors is growing. Seph Gentle designed the = initial architecture, with help from Sarah Allen. Mitar Milutinovic = wrote the Range Patch spec, and gave great reviews for all specs. Bryn = Bellomy fleshed out key details, such as OPTIONS. The work was inspired = by feedback from Austin Wright, Martin Thomson, Eric Kinnear, Duane = Johnson, and recently Julian Reschke. Thank you guys! Many people are joining us from the distributed web community. In the = big picture, I see Braid as an effort to transfer the people and ideas = of the distributed web into the existing web. Together, we synchronize! = https://braid.news Michael Toomim **P.S. I am excited for everyone in Singapore! I had to cancel my trip = at the last minute with the flu. But remote participation works great! **P.P.S. I've been very impressed by this community, and by how = productive the HTTP working group is. This is cool, especially = considering how important HTTP is.= From nobody Tue Nov 19 22:09:20 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8162D120274 for ; Tue, 19 Nov 2019 22:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 vtjYkAYjTAM5 for ; Tue, 19 Nov 2019 22:09:18 -0800 (PST) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24472120815 for ; Tue, 19 Nov 2019 22:09:18 -0800 (PST) X-Auth-ID: fluffy@iii.ca Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C7747C008C; Wed, 20 Nov 2019 01:09:16 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from dhcp-890a.meeting.ietf.org (dhcp-890a.meeting.ietf.org [31.133.137.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 20 Nov 2019 01:09:17 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Cullen Jennings In-Reply-To: <14B97086-B1BC-4A84-AF6A-0C64A0C3D8F2@cisco.com> Date: Wed, 20 Nov 2019 14:09:13 +0800 Cc: "dispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3D479757-FFBC-4C4B-A7FC-DCC92EE22A8B@iii.ca> References: <14B97086-B1BC-4A84-AF6A-0C64A0C3D8F2@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] RIPP Side Meeting Thursday at 8:30 Sophia X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 06:09:20 -0000 There is a start of charter at=20 = https://docs.google.com/document/d/1XOIy0Rw9b7_xpXZ5rKKSSUAfXqXNyrgzQ1IjS5= 1my8M/edit?usp=3Dsharing Please add changes in comments > On Nov 18, 2019, at 11:51 AM, Cullen Jennings (fluffy) = wrote: >=20 >=20 > We can meet 8:30 Thursday in Sophia room to talk more about what = should be in a charter for the RIPP work.=20 >=20 > Thanks, Cullen >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Nov 25 12:32:15 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DAC120F61 for ; Mon, 25 Nov 2019 12:32:13 -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 K_g1NIZg7F73 for ; Mon, 25 Nov 2019 12:32:10 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 9722B120F38 for ; Mon, 25 Nov 2019 12:32:07 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id t5so17513860ljk.0 for ; Mon, 25 Nov 2019 12:32:07 -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=TClNfYEbnNrZnH1lFfdmlAbiAdPZNvzCfRAWwgCGDM8=; b=HMtDCBGwhVxPa/v0CnRhFQVYglfsZI7FFHWduSoUQ4pWznmm8CEVHylo0vKIj7Mkyz x5gXL2max0A9BVS806STExzqTc6+Lcc59qK5cku4uTdaCNB5ZsvI82g3l+T6Vkr/EYP3 KXrQQkQhOrX171dkAW9Y780qtNf9nmGvV5c3M/Inyvn4pwDKZLkEpxPWom11akHszg9+ gs1e2m3WPf8YinLQ1uQkJfVmsC8p9NpfI0nXTFQG3bHc0vnPb69hUsK2ny3GSdfEpZzo eZiirSPz7Rx0R3/3Xuai1YGVfK/+y1FGr3T4iepDT9nras3SxZLq8rMRuq4Nbh3EeDvp z8vQ== 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=TClNfYEbnNrZnH1lFfdmlAbiAdPZNvzCfRAWwgCGDM8=; b=brftX0bjILqx3AORXgqedgP9VPTQuyZ93nxgL91w7mhopdBBRrSuMd38I7UXCXHJTa LynpjpOO2VJ3BO4hqtzUzvSx3tlJVAspx3jN2mCJJMeX6MFujo54dh+2EM8VKWvymA0v iSJwhyjUbhiHL8XePBeSIA/v8iDTUQAhyMiQuoP0slvODx0Zpsl3+0EGrNnTEPG9NguN KaPLPxYpcuSDHdfRIZNgA6dQoJsHoRTRZL1VENkHsTrbZd6cBfN+8YnEE0HmijBIGejt goa68Dp7tvFLzJV9Gb3O2EpMAXQwDzqPjeB4yn087SIvKpAcdXiStOIl9BlIH69N6+uB nbCQ== X-Gm-Message-State: APjAAAWhV0qIgP7MLFIP8XIcGomaebGc19S0menIV9scr+U0imLtJOJD 11BB9dIUUjepKhA6kVoFwkznHPBHpenVSk98crw= X-Google-Smtp-Source: APXvYqx/FH5cRdS48Y3uSEOaX1nDMAmtB43MaxCzznt4fqCrXUFHlPkQCYstcKG4wn+Glta/cPx0nSD19C4zPgAxx8c= X-Received: by 2002:a05:651c:1025:: with SMTP id w5mr23957587ljm.68.1574713925361; Mon, 25 Nov 2019 12:32:05 -0800 (PST) MIME-Version: 1.0 References: <14B97086-B1BC-4A84-AF6A-0C64A0C3D8F2@cisco.com> <3D479757-FFBC-4C4B-A7FC-DCC92EE22A8B@iii.ca> In-Reply-To: <3D479757-FFBC-4C4B-A7FC-DCC92EE22A8B@iii.ca> From: Spencer Dawkins at IETF Date: Mon, 25 Nov 2019 14:31:38 -0600 Message-ID: To: Cullen Jennings Cc: "Cullen Jennings (fluffy)" , "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000024e6ce059831a841" Archived-At: Subject: Re: [dispatch] RIPP Side Meeting Thursday at 8:30 Sophia X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 20:32:13 -0000 --00000000000024e6ce059831a841 Content-Type: text/plain; charset="UTF-8" Hi, Cullen, Do you perhaps have an update on a mailing list yet? Spencer On Wed, Nov 20, 2019 at 12:09 AM Cullen Jennings wrote: > > There is a start of charter at > > > https://docs.google.com/document/d/1XOIy0Rw9b7_xpXZ5rKKSSUAfXqXNyrgzQ1IjS51my8M/edit?usp=sharing > > Please add changes in comments > > > > On Nov 18, 2019, at 11:51 AM, Cullen Jennings (fluffy) > wrote: > > > > > > We can meet 8:30 Thursday in Sophia room to talk more about what should > be in a charter for the RIPP work. > > > > Thanks, Cullen > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000024e6ce059831a841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Cullen,

Do you per= haps have an update on a mailing list yet?

Spencer=

On Wed, Nov 20, 2019 at 12:09 AM Cullen Jennings <fluffy@iii.ca> wrote:

There is a start of charter at

ht= tps://docs.google.com/document/d/1XOIy0Rw9b7_xpXZ5rKKSSUAfXqXNyrgzQ1IjS51my= 8M/edit?usp=3Dsharing

Please add changes in comments


> On Nov 18, 2019, at 11:51 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:<= br> >
>
> We can meet 8:30 Thursday in Sophia room to talk more about what shoul= d be in a charter for the RIPP work.
>
> Thanks, Cullen
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000024e6ce059831a841-- From nobody Mon Nov 25 14:32:59 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2078120F44 for ; Mon, 25 Nov 2019 14:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 7J6W8vM4t5Hu for ; Mon, 25 Nov 2019 14:32:56 -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 3124B12091A for ; Mon, 25 Nov 2019 14:32:55 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAPMWoGj028615 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Nov 2019 16:32:52 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1574721173; bh=nH/Yc1jxDWZOhwkzSbbvfBQCM9Uq7wOSh74v9gQdL9o=; h=From:Subject:Date:Cc:To; b=a/aXmrPmjaTQWiHMSZDcE3qb2LAuOi9/TwHdR6BHCGZ13V0hy7rX7PinkH7Qv0P4s SDehDrktf4tsF7ZBnedw/mk58tdm+gGZyH/6YQhVSmRXvnj5HvlNtXKAuEtb2jsbJh B37sbVHzXd/Ldx2OVrQMSDrCbQusSlRSfslLA7ms= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_BDB143A8-80A4-4831-B224-C5D14B778B76" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <8C25373D-F25C-4320-BE1E-AB3AB857A770@nostrum.com> Date: Mon, 25 Nov 2019 16:32:44 -0600 To: dispatch@ietf.org X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [dispatch] Draft Minutes from Singapore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 22:32:58 -0000 --Apple-Mail=_BDB143A8-80A4-4831-B224-C5D14B778B76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, The draft minutes from the dispatch meeting at IETF106 (Singapore) are = available at = https://datatracker.ietf.org/meeting/106/materials/minutes-106-dispatch-00= = . Please review at your earliest convenience and send any additions or = corrections to the chairs and the dispatch list. Thanks! Ben.= --Apple-Mail=_BDB143A8-80A4-4831-B224-C5D14B778B76 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi everyone,

The draft minutes from the dispatch meeting at IETF106 (Singapore) are available at https://datatracker.ietf.org/meeting/106/materials/minutes-106-dispatch-00. Please review at your earliest convenience and send any additions or corrections to the chairs and the dispatch list.

Thanks!

Ben.
--Apple-Mail=_BDB143A8-80A4-4831-B224-C5D14B778B76-- From nobody Mon Nov 25 15:04:36 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA66120FF7 for ; Mon, 25 Nov 2019 15:04:31 -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=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 30INuyeRYQ-Y for ; Mon, 25 Nov 2019 15:04:29 -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 3236612003E for ; Mon, 25 Nov 2019 15:04:28 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id j6so8867574lja.2 for ; Mon, 25 Nov 2019 15:04:28 -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=GMMiu7GshkxhEkWPkxlmUrDeFfkro2Zj/zFZHY+84t8=; b=wWLRIVcococcjXqTY1HUgxMikz3g3TM3pOf/OgyEe0COAiYAHA3ge/AL0JaSOh+soK uMdwvZUvrbpZGR45V2p39XsbEifv5QqAukDbe/+wHbFlMO0B53KiS5Aarw544BwyFOXT OFwgC9fzvj3ILAXW3+1eLYuASZDOvf5WqA8zoQ/L7L6EfyMzJtTkbDHQLOqBweBVl24g M01KV9akir+71Ko6jV70etFKPOSdIH07JWQ6WmLkr4vQ8vigsUEY1moJSjit7Dy68b5H 85O7NziC1QwGDhYtShKHI3OyYqr/E8fXxgc1lTWMHVHTGQRqmbCjNBNQxMq3cbiWJogW QM9Q== 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=GMMiu7GshkxhEkWPkxlmUrDeFfkro2Zj/zFZHY+84t8=; b=BQBkou+5UIGBF2fXmROI82kEPDzSplV++y3WIixIa39SqoYfQ03rjGqdnNEhU8EhAT mj9XHbUbYTBaUAdhFCOQ1DWc9uvuniGhlFeoND+8uO/e1JR4TSlUhQgL17YyhzK7ltHE caxj6ymIZ2Ri3jKOUgFmlUw/KrtF6txOl+QWkcopI2SqwPHk+VfuuZExieoMIFyMhLkC ALvs0hwKdsvOGGGeTj3zwq4FpQK/f/IQRu9HSrspm8rkPkeuzyRkxvLydtxbU4QyBbXc TmfivTHemAnqP991+8/OONGtxctuT3caiCv6U8qQv9JwSifcGXtLuNVwVuuRL3iE3tSG OTkA== X-Gm-Message-State: APjAAAWfVdS+MSBNIRT4GRYPSMYcQf0Wi9x/O5icsiN58XeW+wN+ej21 uwclMbZacyNW2RVifaV0IMzp3of5grgNT24FFZABKau+wQ0= X-Google-Smtp-Source: APXvYqx6vEeIpnzZ/qIHMZp9zGc4086HiKa1tGLzyhZ6MT8AQJr+C+bM7MnFGhETuMVUew6bl+x94jViYd0hUbgXFXc= X-Received: by 2002:a2e:3a12:: with SMTP id h18mr17847087lja.217.1574723066338; Mon, 25 Nov 2019 15:04:26 -0800 (PST) MIME-Version: 1.0 References: <8C25373D-F25C-4320-BE1E-AB3AB857A770@nostrum.com> In-Reply-To: <8C25373D-F25C-4320-BE1E-AB3AB857A770@nostrum.com> From: Eric Rescorla Date: Mon, 25 Nov 2019 15:03:50 -0800 Message-ID: To: Ben Campbell Cc: DISPATCH Content-Type: multipart/alternative; boundary="000000000000fd3818059833c890" Archived-At: Subject: Re: [dispatch] Draft Minutes from Singapore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 23:04:35 -0000 --000000000000fd3818059833c890 Content-Type: text/plain; charset="UTF-8" On the topic of RIPP " Conclusion: Organize a (possibly virtual) BoF. We want to progress more quickly than has been common. Cullen to organize a side-meeting Thursday morning. " I'm not sure that this is really correct. The conclusion was that there would need to be a BOF and the proponents would like to move more quickly. I don't believe there was consensus that the community wanted to move more quickly. Or, at all, for that matter. -Ekr On Mon, Nov 25, 2019 at 2:33 PM Ben Campbell wrote: > Hi everyone, > > The draft minutes from the dispatch meeting at IETF106 (Singapore) are > available at > https://datatracker.ietf.org/meeting/106/materials/minutes-106-dispatch-00. > Please review at your earliest convenience and send any additions or > corrections to the chairs and the dispatch list. > > Thanks! > > Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000fd3818059833c890 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the t= opic of RIPP
=
" 
Conclusion: Organiz=
e a (possibly virtual) BoF. We want to progress more quickly than has
been common. Cullen to organize a side-meeting Thursday morning.
"

I'm not sure that this is really correct. The conclusion was that the=
re would need to be a BOF and the proponents would like to move more quickl=
y. I don't believe there was consensus that the community wanted to mov=
e more quickly. Or, at all, for that matter.

-Ekr


=
On Mon, No= v 25, 2019 at 2:33 PM Ben Campbell <b= en@nostrum.com> wrote:
Hi everyone,
The draft minutes from the dispatch meeting at IETF106 (Singap= ore) are available at=C2=A0https://datatracke= r.ietf.org/meeting/106/materials/minutes-106-dispatch-00. Please review= at your earliest convenience and send any additions or corrections to the = chairs and the dispatch list.

Thanks!
Ben.
______________________________________________= _
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000fd3818059833c890-- From nobody Mon Nov 25 15:20:24 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0B5120F9F for ; Mon, 25 Nov 2019 15:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 t1BoOX2rqTVj for ; Mon, 25 Nov 2019 15:20:20 -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 BF604120024 for ; Mon, 25 Nov 2019 15:20:20 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAPNKI4q099449 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Nov 2019 17:20:19 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1574724020; bh=3PEp8e2A1ikC62AG6gJncJsZGXJ9u76vDlpLHAQNkXo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Rc++/pZMW1n8HLiAPKRVeI3MheSWgS/flW35KvzGwlaeVTDdBsbGEFzdESBG19LJz aOZWgTiG3p/rRO9A3ON1qXxA0gOKoiBxhejUEFClU0AFx9jMsciNGLqt7VcDJutRos SnIToKTzTzL3DC5XCgKCPEqHyiHMAB1YGL7milYw= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: <384C5D8F-AC83-4146-A06E-79C9CADBC5EA@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_56AC48F4-10D1-4418-A119-F9506DBAC6B5" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 25 Nov 2019 17:20:11 -0600 In-Reply-To: Cc: DISPATCH To: Eric Rescorla References: <8C25373D-F25C-4320-BE1E-AB3AB857A770@nostrum.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [dispatch] Draft Minutes from Singapore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 23:20:22 -0000 --Apple-Mail=_56AC48F4-10D1-4418-A119-F9506DBAC6B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with your interpretation. We will update the minutes shortly to = reflect it. Thanks! Ben. > On Nov 25, 2019, at 5:03 PM, Eric Rescorla wrote: >=20 > On the topic of RIPP >=20 > " > Conclusion: Organize a (possibly virtual) BoF. We want to progress = more quickly than has > been common. Cullen to organize a side-meeting Thursday morning. > " >=20 > I'm not sure that this is really correct. The conclusion was that = there would need to be a BOF and the proponents would like to move more = quickly. I don't believe there was consensus that the community wanted = to move more quickly. Or, at all, for that matter. >=20 > -Ekr >=20 >=20 > On Mon, Nov 25, 2019 at 2:33 PM Ben Campbell > wrote: > Hi everyone, >=20 > The draft minutes from the dispatch meeting at IETF106 (Singapore) are = available at = https://datatracker.ietf.org/meeting/106/materials/minutes-106-dispatch-00= = . Please review at your earliest convenience and send any additions or = corrections to the chairs and the dispatch list. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_56AC48F4-10D1-4418-A119-F9506DBAC6B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = agree with your interpretation. We will update the minutes shortly to = reflect it.

Thanks!

Ben.

On Nov 25, 2019, at 5:03 PM, = Eric Rescorla <ekr@rtfm.com> wrote:

On the topic of RIPP

" 
Conclusion: Organize a (possibly virtual) BoF. We want to =
progress more quickly than has
been common. Cullen to organize a side-meeting Thursday morning.
"

I'm not sure that this =
is really correct. The conclusion was that there would need to be a BOF =
and the proponents would like to move more quickly. I don't believe =
there was consensus that the community wanted to move more quickly. Or, =
at all, for that matter.

-Ekr

On Mon, Nov = 25, 2019 at 2:33 PM Ben Campbell <ben@nostrum.com> wrote:
Hi everyone,

The draft minutes from the dispatch = meeting at IETF106 (Singapore) are available at https://datatracker.ietf.org/meeting/106/materials/minutes-106-= dispatch-00. Please review at your earliest convenience and send any = additions or corrections to the chairs and the dispatch list.

Thanks!

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

= --Apple-Mail=_56AC48F4-10D1-4418-A119-F9506DBAC6B5-- From nobody Mon Nov 25 17:12:58 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A25B120FD5 for ; Mon, 25 Nov 2019 17:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=fastmailteam.com header.b=WEZsSM2+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CujUbkjY 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 b0xkJys8S6Hl for ; Mon, 25 Nov 2019 17:12:55 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E4F120FCC for ; Mon, 25 Nov 2019 17:12:53 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DCE64994 for ; Mon, 25 Nov 2019 20:12:52 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Mon, 25 Nov 2019 20:12:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=0drPh44 LJ1LXBnI7xwcvGgZ22szhS/6SSNmPFfJ5jD0=; b=WEZsSM2+3aFMGmopp6R5GEU NlPtW2ENPvW1VGmZsP/O8qUS9vZfMKEYmwiQxrLl5tc1Ij3rXM+kpuUvrDeP+uBj SxoQE/YhZXcULi6DNDJE0qNqEU8nADPc7MoZeCSMTrWuqDi37I7yqS9GpGsQ0IeO G0Pj74+96KnOPaeab2q15SxkJZI5pnbDdTjTRZMrFsh/b4UdhuY+7Ly4bewq5Hut jS/xO5gUff31BIen/gWAz35HJq0F/OHSCX352wX2Qx5DEbPwLEgO4UEYrKI/2ZLc ynZjnIGTu100H5s7mh235ManWxJACCDoe8KUkK5n4tuL6okqk8iT0EnMo2chZPQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0drPh4 4LJ1LXBnI7xwcvGgZ22szhS/6SSNmPFfJ5jD0=; b=CujUbkjYmCu8pAqllA3/+X KkjxfjpsQ4FeIJKc6AaH/QOyAa0pJapNgtwEX14xOqTj+7tXxHsd+IoSDZ09U+3f +hR3tqoAp64iFheSgTcHBixb0a7nigXarQHRNfyldTtkD9bbp8/7NSx7yZasZkaI bN3yTUBinOvGzgSSaigw+eG8+Mf9fd2sYCS/z+Ui62ktAbqquUb4q0aZBtzHSgmj znxkqXvH5LQhpREbXujOOXlPEfVwHBSUaA63i6Apg7Q8eXj3rnn8WLD3DMw31UL3 CpDJiUlFypp64dkTmHAkMdP7AuxvVTQeHQaP3PcSS0zt4R3t+Qsmoi6cs2qdaFlQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeivddgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A29A30618B; Mon, 25 Nov 2019 20:12:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <3507c322-78bb-4f55-b498-63cac6e23f5f@beta.fastmail.com> In-Reply-To: <8C25373D-F25C-4320-BE1E-AB3AB857A770@nostrum.com> References: <8C25373D-F25C-4320-BE1E-AB3AB857A770@nostrum.com> Date: Tue, 26 Nov 2019 12:12:31 +1100 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=192bb604cf164b00aa113a732cfaef9b Archived-At: Subject: Re: [dispatch] Draft Minutes from Singapore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 01:12:56 -0000 --192bb604cf164b00aa113a732cfaef9b Content-Type: text/plain worl -> work at the end of my PUSH discussion, otherwise that's accurate (both the summary and the detail) for my bit. On Tue, Nov 26, 2019, at 09:32, Ben Campbell wrote: > Hi everyone, > > The draft minutes from the dispatch meeting at IETF106 (Singapore) are available at https://datatracker.ietf.org/meeting/106/materials/minutes-106-dispatch-00. Please review at your earliest convenience and send any additions or corrections to the chairs and the dispatch list. > > Thanks! > > Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --192bb604cf164b00aa113a732cfaef9b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
worl -> work at the end of my PUSH discussion, otherwis= e that's accurate (both the summary and the detail) for my bit.



On Tue= , Nov 26, 2019, at 09:32, Ben Campbell wrote:
Hi everyone,

The draft minutes from = the dispatch meeting at IETF106 (Singapore) are available at https://datatracker.ietf.org/meeting/106/material= s/minutes-106-dispatch-00. Please review at your earliest convenienc= e and send any additions or corrections to the chairs and the dispatch l= ist.

Thanks!

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

=

--
  Bron Go= ndwana, CEO, Fastmail Pty Ltd
  b= rong@fastmailteam.com

=

--192bb604cf164b00aa113a732cfaef9b-- From nobody Mon Nov 25 18:47:24 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C3120154 for ; Mon, 25 Nov 2019 18:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 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.4, MAY_BE_FORGED=0.001, 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 jEMv0qtBGb1t for ; Mon, 25 Nov 2019 18:47:22 -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 3896D12013F for ; Mon, 25 Nov 2019 18:47:21 -0800 (PST) Received: from [192.168.127.239] (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAQ2lCGD047691 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Nov 2019 20:47:14 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1574736436; bh=wRmJ1zYyBKl+3zleBOAx6ylA+LAAf2WSCVx0PQHPkU4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=m/XuFWrWwk+o6aeLGHBTEUjKP70ZZfyHBKoiRUcjGqEKqhGXSLiff2U+QjC9yo7uK Jsa8QiZrmpWdAVyA0GxNYMmFIl53bFq2hd+/rxJOYTRbzzL1IJTD8ZNE7exSPwTQro HKSAcy6M9pe5Kh0OKkHhTPQHXnDYNp+2xkXQG+Wk= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be [192.168.127.239] From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AC1568CD-F925-43F9-8463-447F9A7BECB4" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 25 Nov 2019 20:47:06 -0600 In-Reply-To: <3507c322-78bb-4f55-b498-63cac6e23f5f@beta.fastmail.com> To: DISPATCH References: <8C25373D-F25C-4320-BE1E-AB3AB857A770@nostrum.com> <3507c322-78bb-4f55-b498-63cac6e23f5f@beta.fastmail.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [dispatch] Draft Minutes from Singapore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 02:47:23 -0000 --Apple-Mail=_AC1568CD-F925-43F9-8463-447F9A7BECB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I uploaded an update with corrections from Ekr and Bron. Thanks! Ben. > On Nov 25, 2019, at 7:12 PM, Bron Gondwana = wrote: >=20 > worl -> work at the end of my PUSH discussion, otherwise that's = accurate (both the summary and the detail) for my bit. >=20 >=20 >=20 > On Tue, Nov 26, 2019, at 09:32, Ben Campbell wrote: >> Hi everyone, >>=20 >> The draft minutes from the dispatch meeting at IETF106 (Singapore) = are available at = https://datatracker.ietf.org/meeting/106/materials/minutes-106-dispatch-00= = . Please review at your earliest convenience and send any additions or = corrections to the chairs and the dispatch list. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_AC1568CD-F925-43F9-8463-447F9A7BECB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = uploaded an update with corrections from Ekr and Bron.

Thanks!

Ben.

On Nov = 25, 2019, at 7:12 PM, Bron Gondwana <brong@fastmailteam.com> wrote:

worl -> work = at the end of my PUSH discussion, otherwise that's accurate (both the = summary and the detail) for my bit.



On Tue, Nov 26, 2019, at 09:32, Ben Campbell wrote:
Hi everyone,

The draft minutes from the dispatch meeting at IETF106 = (Singapore) are available at https://datatracker.ietf.org/meeting/106/materials/minutes-106-d= ispatch-00. Please review at your earliest convenience and send any = additions or corrections to the chairs and the dispatch list.

Thanks!

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


--
  Bron Gondwana, CEO, = Fastmail Pty Ltd
  brong@fastmailteam.com


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

= --Apple-Mail=_AC1568CD-F925-43F9-8463-447F9A7BECB4--