Re: [dispatch] Secure Credential Transfer Charter & BoF
Matthew Byington <mbyington@apple.com> Fri, 28 January 2022 22:30 UTC
Return-Path: <mbyington@apple.com>
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 010ED3A15F6; Fri, 28 Jan 2022 14:30:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Level:
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 ytFiR4lXtEgH; Fri, 28 Jan 2022 14:30:34 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 A44E43A15F5; Fri, 28 Jan 2022 14:30:33 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 20SMIwgV029792; Fri, 28 Jan 2022 14:30:31 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=maNP2kzfDydua85cA3Y8d6nRlkYm230t8Z53RFdcR8w=; b=MHl8YkmdmGYL11Ek3Gi+QEASxOFsrUg66vpRZM9yjOytQw4xfyz3qHSB8a44IMTuPWrj Mcp7CPEmvOMyoUOFos+bFFIqgPEI0TCOoNcD5wljMHknCq/wWAGvur+hO9JaGFwqN/Oc pJT9STgz/dxyBcOleU0kL6/t6ZrpfzJZf43NrgsQzft2K7SuMXZ6NWK0drWnCIqpRHue v96JsOlU78zZDAgD0fMCbrWq5pfy9aT77j04KpdLYlfnCr35c9dLTop6h0vgIkb+valr BQeEo00LlTYZhXpXThKIA4AxpYdevnaSlXC8EAvIquCjHlZDIGdn18qwwOdjewJehRyC Pw==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3drht1n1et-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Jan 2022 14:30:31 -0800
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6F00BT6YITNPG0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 28 Jan 2022 14:30:29 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R6F00H00YDG6L00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 28 Jan 2022 14:30:29 -0800 (PST)
X-Va-A:
X-Va-T-CD: 7a77f9138d60728e010dfb6f2118f5e7
X-Va-E-CD: 1b2514d45a6cbacdd746d7feed02cb99
X-Va-R-CD: 21f245648979a34695bda2dc7cf5e7b6
X-Va-CD: 0
X-Va-ID: cf70b1d6-a2f6-4a08-90e6-c2164aaff461
X-V-A:
X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7
X-V-E-CD: 1b2514d45a6cbacdd746d7feed02cb99
X-V-R-CD: 21f245648979a34695bda2dc7cf5e7b6
X-V-CD: 0
X-V-ID: 90ab0fdc-9311-4d38-b0dd-32c44fcb08af
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-28_08:2022-01-28, 2022-01-28 signatures=0
Received: from smtpclient.apple (unknown [17.149.231.94]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6F00QIWYISC700@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 28 Jan 2022 14:30:28 -0800 (PST)
From: Matthew Byington <mbyington@apple.com>
Message-id: <60C1E0F0-57FD-4CAD-806A-844EC85DEB38@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_5E019FA5-9FC3-4ECE-9184-C05048B159F5"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 28 Jan 2022 14:30:28 -0800
In-reply-to: <6D19DF62-D6C0-42F3-A174-937E0C1E5E12@apple.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, Richard Barnes <rlb@ipv.sx>, DISPATCH <dispatch@ietf.org>, The IESG <iesg@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <FA7592B5-D8D4-413D-97B4-1044F29FC205@apple.com> <CABcZeBNzqSnd5eGwZOui980=BfFfywLRO6asm=BtxZEgAFnWMA@mail.gmail.com> <A3547720-3AD2-409D-8FC8-605D09D4941D@apple.com> <F0244118-AED2-41B1-AA57-95FF71EE2683@mnot.net> <CABcZeBMVG1Ho6YeA838UirkaY_UvUQBOdL0ccy6eghAPWy1PNQ@mail.gmail.com> <CAL02cgS7SwGNu7MwHmfVoUp4BRQAMcJ64aB7cat0Jy+PNngy7g@mail.gmail.com> <CALGR9oZrqa2MA_uge2MbmArf_2d7XF69VV2cRxBkvRiauL3dkg@mail.gmail.com> <CABcZeBPemgpLLyd2DOfFC8s4BpMsuhxH0AisHyLrfj9dnufXOA@mail.gmail.com> <6D19DF62-D6C0-42F3-A174-937E0C1E5E12@apple.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-01-28_08:2022-01-28, 2022-01-28 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/vDMKIp9FrfIA57m3RyvD9-D6eL0>
Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2022 22:30:39 -0000
Hello everyone, Happy Friday. We have created a set of slides that endeavors to answer some of the questions that have come up on this mailing list distribution. I am going to attach the slides in PDF format to this email - I hope that works for everyone to be able to open them. These are the slides that we will use to guide the BoF discussion. We will of course have additional color to add in the BoF discussion verbally but hopefully these are helpful in written format for now. Note that these slides are *not* final yet, but as promised I wanted to get some additional information to everyone ASAP given the feedback we received on this thread around timing. I also wanted to take a moment to thank everyone for their feedback thus far. By the way, @Mark, I too share your concern of waking up early - totally get it. When we presented at IETF 112 last year I had to get up at 3 AM for that and needless to say, many cups of coffee were consumed. The slides contain detail around the assumptions, requirements, use cases, and problem statement. Hope everyone has a great weekend. Thanks! Matt > On Jan 27, 2022, at 9:01 AM, Matthew Byington <mbyington@apple.com> wrote: > > Hi Eric, Lucas, > > Thank you very much for the feedback. It is really valuable to me as I am navigating IETF and BoFs in general to learn and better my understanding of how these things should work. > > Mark/Eric/Richard thank you as well for your input on timing and the fact that it is not being held at IETF week. I will circle back with Francesca to discuss, but I’m personally really looking forward to discussing the topic with the broader community sooner than IETF 113 so that we can continue the discussion. > > Eric/Lucas - I will type up some supplemental material in addition to the draft and charter that we published earlier this week to the mailing lists and I will respond here with that material by EOD tomorrow (Friday Jan 28) describing the problem statement in additional detail. > > In addition to responding here I’ll post it on our GitHub so that it is available to folks who aren’t on this list. > > Thanks, > Matt > >> On Jan 26, 2022, at 7:04 PM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote: >> >> At this point I'm going to repeat my ask (in my review when this was DISPATCHED) for some document which describes the problem and the assumed constraints. >> >> This protocol has a number of features which seem surprising, and without understanding the context it is essentially impossible to determine whether those are necessary or misfeatures. >> >> It would be extremely helpful if you posted this with sufficient time for people to read this *prior* to the BoF, say in the next week or so. >> >> -Ekr >> >> >> On Wed, Jan 26, 2022 at 6:08 PM Lucas Pardue <lucaspardue.24.7@gmail.com <mailto:lucaspardue.24.7@gmail.com>> wrote: >> Either way, there's not really much detail to help prepare for the BoF. With it being two weeks away I'd expect to see an agenda at least. >> >> Cheers, >> Lucas >> >> On Thu, Jan 27, 2022 at 1:39 AM Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx>> wrote: >> I have the opposite concerns from Eric and Mark. Holding a BoF outside the IETF week means less competition for peoples' attention. And in the era of easy, high-quality conferencing, it's ridiculous to delay work for months on the basis that we can only get the right group of people together three weeks a year. >> >> +1 for virtual BoFs >> >> --Richard >> >> On Wed, Jan 26, 2022 at 7:22 PM Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote: >> I share Mark's concerns about this BoF. Is there a reason this wasn't held during IETF week? >> >> -Ekr >> >> >> On Wed, Jan 26, 2022 at 4:17 PM Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>> wrote: >> I'm a little surprised to hear this. >> >> Holding BoFs during IETF weeks gives them elevated visibility during a period when IETF folks have already reserved their attention and time for IETF matters. Scheduling one out of an IETF week means that people need to accommodate it in their schedules, not only for the event but also for preparation work. >> >> Holding such a BoF virtually compounds that -- especially when there has been ZERO consultation with the broad community about timing. E.g, if I wanted to attend this BoF, I'd need to be up before 4am. >> >> The icing on the cake, though, is announcing it with only two weeks' notice -- a period of time shorter than many vacations. >> >> As a result, I have very little confidence that this BoF will reflect community consensus and input. Of course, you will confirm consensus on lists, etc., but holding the BoF in such a limited forum taints the outcome. >> >> IESG, this is a horrible precedent and while I won't specifically argue to cancel or delay this BoF, I do expect you to be much more thoughtful about these issues. >> >> Cheers, >> >> >> > On 26 Jan 2022, at 12:00 pm, Matthew Byington <mbyington=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote: >> > >> > Hi Eric, >> > >> > My understanding is that the BoF will be handled virtually (not in-person). It has also been scheduled outside of the normal IETF week. >> > >> > The BoF is working-group forming, yes. >> > >> > Matt >> > >> >> On Jan 25, 2022, at 11:38 AM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote: >> >> >> >> Can you clarify what the status of a "virtual BoF" is, here? I.e., is this in lieu of an actual BoF at the next IETF? Is this WG forming? >> >> >> >> -Ekr >> >> >> >> >> >> On Tue, Jan 25, 2022 at 11:36 AM Matthew Byington <mbyington=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote: >> >> Hi there, >> >> >> >> I wanted to send an email out communicating an upcoming virtual BoF meeting scheduled for Thursday February 10th. >> >> >> >> This is a follow-on to the initial presentation at IETF week 112 given last year. >> >> >> >> I am posting the information below to a few different IETF mailing lists, so apologies if you receive duplicate notifications on the subject. >> >> >> >> A big “thank you” to Francesca for helping us to get this scheduled and organized. >> >> >> >> Latest draft: >> >> https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html <https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html> >> >> >> >> Charter: >> >> https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md <https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md> >> >> >> >> BoF Request: >> >> https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-request/ <https://datatracker.ietf.org/doc/bofreq-secure-credential-transfer-bof-request/> >> >> >> >> Virtual BoF (Francesca is finalizing this schedule still, but this is the proposed date and time): >> >> Thursday February 10th 17:00-19:00 UTC (https://www.worldtimebuddy.com/?qm=1&lid=2673730,5,8,100&h=2673730&date=2022-2-10&sln=18-20&hf=1 <https://www.worldtimebuddy.com/?qm=1&lid=2673730,5,8,100&h=2673730&date=2022-2-10&sln=18-20&hf=1>) >> >> >> >> Mailing list: >> >> https://www.ietf.org/mailman/listinfo/secret <https://www.ietf.org/mailman/listinfo/secret> >> >> >> >> Thanks, >> >> Matt >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org <mailto:dispatch@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org <mailto:dispatch@ietf.org> >> > https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> >> >> -- >> Mark Nottingham https://www.mnot.net/ <https://www.mnot.net/> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org <mailto:dispatch@ietf.org> >> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org <mailto:dispatch@ietf.org> >> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> >
- [dispatch] Secure Credential Transfer Charter & B… Matthew Byington
- Re: [dispatch] Secure Credential Transfer Charter… Eric Rescorla
- Re: [dispatch] Secure Credential Transfer Charter… Matthew Byington
- Re: [dispatch] Secure Credential Transfer Charter… Mark Nottingham
- Re: [dispatch] Secure Credential Transfer Charter… Eric Rescorla
- Re: [dispatch] Secure Credential Transfer Charter… Richard Barnes
- Re: [dispatch] Secure Credential Transfer Charter… Lucas Pardue
- Re: [dispatch] Secure Credential Transfer Charter… Eric Rescorla
- Re: [dispatch] Secure Credential Transfer Charter… Matthew Byington
- Re: [dispatch] Secure Credential Transfer Charter… Matthew Byington
- Re: [dispatch] Secure Credential Transfer Charter… John C Klensin
- Re: [dispatch] Secure Credential Transfer Charter… worley
- Re: [dispatch] Secure Credential Transfer Charter… Matthew Byington
- Re: [dispatch] Secure Credential Transfer Charter… John C Klensin
- Re: [dispatch] Secure Credential Transfer Charter… Eric Rescorla
- Re: [dispatch] Secure Credential Transfer Charter… John C Klensin
- Re: [dispatch] Secure Credential Transfer Charter… Martin Thomson
- Re: [dispatch] Secure Credential Transfer Charter… Eric Rescorla
- Re: [dispatch] Secure Credential Transfer Charter… Roman Danyliw
- Re: [dispatch] Secure Credential Transfer Charter… John C Klensin