Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF

From: Matthew Byington <[email-masked]>
Date: Wed, 02 Feb 2022 13:31:20 -0800

Hi John,

Thank you for your response. I am adding Francesca here to this thread.

When I first presented at Dispatch last year they helped guide me and the other proponents to the right place.

I don’t have prior IETF experience myself - I certainly place a lot of trust in the existing community for where this should live.

I should say, I’m not directly opposed to it living in the Security Area as long as the ADs in general agree.

Security does play a large role in our problem statement and considerations, to your point.

Perhaps this is something we could discuss during the BoF?

Matt

> On Jan 29, 2022, at 10:13 PM, John C Klensin <[email-masked]> wrote:
> 
> Hi.
> 
> I've read the thread to date but it seems more appropriate to
> respond to this message since this is not about the timing issue
> raised by others.
> 
> Having read the charter and other materials, including skimming
> the slides, I would like to better understand why this is being
> proposed in ART rather than in the Security Area.  The expertise
> is there (and not in ART except by happy accident) on most of
> the "primary goals" and requirements in the charter.  It is
> clear why an application or application protocol would want to
> use the credential-sharing protocol being proposed, but it does
> not seem to me that qualifies it as ART work (or, if it does,
> why a significant amount of other work in the Security Area does
> not belong in ART).
> 
> Just wondering...
>    john
> 
> 
> --On Tuesday, January 25, 2022 17:00 -0800 Matthew Byington
> <mbyington=[email-masked] <mailto:mbyington=[email-masked]>> 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 <[email-masked]>
>>> 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=[email-masked]
>>> <mailto:[email-masked] <mailto:[email-masked]>>> 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-tran <https://www.ietf.org/archive/id/draft-secure-credential-tran>
>>> 	sfer-03.html
>>> 	<https://www.ietf.org/archive/id/draft-secure-credential-tra <https://www.ietf.org/archive/id/draft-secure-credential-tra>
>>> 	nsfer-03.html>
>>> 
>>> Charter:
>>> 	https://github.com/dimmyvi/secure-credential-transfer/blob/m <https://github.com/dimmyvi/secure-credential-transfer/blob/m>
>>> 	ain/charter.md
>>> 	<https://github.com/dimmyvi/secure-credential-transfer/blob/ <https://github.com/dimmyvi/secure-credential-transfer/blob/>
>>> 	main/charter.md>
>>> 	
>>> BoF Request:
>>> 	https://datatracker.ietf.org/doc/bofreq-secure-credential-tr <https://datatracker.ietf.org/doc/bofreq-secure-credential-tr>
>>> 	ansfer-bof-request/
>>> 	<https://datatracker.ietf.org/doc/bofreq-secure-credential-t <https://datatracker.ietf.org/doc/bofreq-secure-credential-t>
>>> 	ransfer-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= <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= <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>
>>> 	<https://www.ietf.org/mailman/listinfo/secret <https://www.ietf.org/mailman/listinfo/secret>> 
>>> 
>>> Thanks,
>>> Matt
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>>> <https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>>

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 17:14:30 -0500

Matthew,

Thanks for the response.  For me, it makes perfectly good sense.
And, having participated in the DISPATCH discussion, I (and
perhaps others) didn't adequately understand how much the work
would depend on issues and topics in the Security area.. or we
were not paying enough attention.  I am actually surprised the
question was not raised by ekr or one of the others who spends
much more time on security issues than I do.

I think discussing this at the BOF would be fine but would
strongly encourage Francesca and the Security ADs to have a
conversation in advance, either to settle the issue and explain
it to those of us who have questions or to make the BOF, even if
informally, a joint ART-Security one to increase the odds of the
right people being part of that discussion.  

>From experience, the thing you definitely do not want is to get
a document finished and into IETF Last Call and only then have
people in the Security Area complain about things you have left
out or to which you have paid insufficient attention.  The
earlier such possibilities are identified and dealt with the
better.

thanks,
   john

--On Wednesday, February 2, 2022 13:31 -0800 Matthew Byington
<[email-masked]> wrote:

> When I first presented at Dispatch last year they helped guide
> me and the other proponents to the right place.
> 
> I don't have prior IETF experience myself - I certainly
> place a lot of trust in the existing community for where this
> should live.
> 
> I should say, I'm not directly opposed to it living in the
> Security Area as long as the ADs in general agree.
> 
>> respond to this message since this is not about the timing
>> issue raised by others.
>> 
>> Having read the charter and other materials, including
>> skimming the slides, I would like to better understand why
>> this is being proposed in ART rather than in the Security
>> Area.  The expertise is there (and not in ART except by happy
>> accident) on most of the "primary goals" and requirements in
>> the charter.  It is clear why an application or application
>> protocol would want to use the credential-sharing protocol
>> being proposed, but it does not seem to me that qualifies it
>> as ART work (or, if it does, why a significant amount of
>> other work in the Security Area does not belong in ART).
>> 
>> Just wondering...
>>    john
>> 
>> 
>> <mailto:mbyington=[email-masked]>> wrote:
>> 
>>> Hi Eric,
>>> 
>>>> <mailto:[email-masked]
>>>> <mailto:[email-masked]>>> wrote: Hi there,
>>>> 
>>>> 	https://www.ietf.org/archive/id/draft-secure-credential-tr
>>>> 	an
>>>> 	<https://www.ietf.org/archive/id/draft-secure-credential-t
>>>> 	ran> sfer-03.html
>>>> 	<https://www.ietf.org/archive/id/draft-secure-credential-t
>>>> 	ra
>>>> 	<https://www.ietf.org/archive/id/draft-secure-credential-t
>>>> 	ra> nsfer-03.html>
>>>> 
>>>> Charter:
>>>> 	https://github.com/dimmyvi/secure-credential-transfer/blob
>>>> 	/m
>>>> 	<https://github.com/dimmyvi/secure-credential-transfer/blo
>>>> 	b/m> ain/charter.md
>>>> 	<https://github.com/dimmyvi/secure-credential-transfer/blo
>>>> 	b/
>>>> 	<https://github.com/dimmyvi/secure-credential-transfer/blo
>>>> 	b/> main/charter.md>
>>>> 	
>>>> BoF Request:
>>>> 	https://datatracker.ietf.org/doc/bofreq-secure-credential-
>>>> 	tr
>>>> 	<https://datatracker.ietf.org/doc/bofreq-secure-credential
>>>> 	-tr> ansfer-bof-request/
>>>> 	<https://datatracker.ietf.org/doc/bofreq-secure-credential
>>>> 	-t
>>>> 	<https://datatracker.ietf.org/doc/bofreq-secure-credential
>>>> 	-t> ransfer-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=
>>>> 	<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=
>>>> 	<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>
>>>> 	<https://www.ietf.org/mailman/listinfo/secret
>>>> 	<https://www.ietf.org/mailman/listinfo/secret>> 
>>>> 
>>>> Thanks,
>>>> Matt
>>>> [email-masked] <mailto:[email-masked]>
>>>> <mailto:[email-masked] <mailto:[email-masked]>>
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>> <https://www.ietf.org/mailman/listinfo/dispatch>
>>>> <https://www.ietf.org/mailman/listinfo/dispatch
>>>> <https://www.ietf.org/mailman/listinfo/dispatch>>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Feb 2022 14:32:56 -0800

Hearing my name...

This actually was discussed at the meeting [0]. See the end where Richard
Barnes says:
"don’t think it belongs in sec - the interesting questions are around the
broader architecture. The details of the crypto needs to be arranged
properly, but we can bring in exepertise. The work belongs in ART not SEC."

I roughly agree with this. The crypto is fairly straightforward but the
architecture for moving the data around needs serious consideration.I don't
think it would be a disaster in SEC, but based on experience with, for
instance ACME, it would need a lot of apps input to avoid screwing that
side up.

-Ekr

[0]
https://datatracker.ietf.org/meeting/112/materials/minutes-112-dispatch-00.html

-Ekr

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 18:54:23 -0500

Ekr,

Then I'm really glad I mentioned your name :-)

I am not opposed to seeing this in ART if you, Richard, and
others with more expertise in Security than I have aspired to in
the last several decades are persuaded it is the right thing to
do... and as long as you (plural) will be sufficiently involved
to be sure that, if things drift off in the wrong directions
from a security technology standpoint, people are alerted --or,
paraphrasing your quote from Richard, that the details are
properly arranged and the right expertise is brought in at the
right points.

Fortunately or unfortunately, I don't know what happened with
ACME.

I still think that it would be useful to discuss this further at
the BOF so everyone who needs it gets a better understanding of
where the issues and boundaries lie and to, at least, get
agreement from the SEC ADs to help Francesca keep an eye on
developments of a WG and any document processing.

thanks,
   john

--On Wednesday, February 2, 2022 14:32 -0800 Eric Rescorla
<[email-masked]> wrote:

>> Thanks for the response.  For me, it makes perfectly good
>> sense. And, having participated in the DISPATCH discussion, I
>> (and perhaps others) didn't adequately understand how much
>> the work would depend on issues and topics in the Security
>> area.. or we were not paying enough attention.  I am actually
>> surprised the question was not raised by ekr or one of the
>> others who spends
>> 
> This actually was discussed at the meeting [0]. See the end
> where Richard Barnes says:
> "don't think it belongs in sec - the interesting questions
> are around the broader architecture. The details of the crypto
> needs to be arranged properly, but we can bring in exepertise.
> The work belongs in ART not SEC."
> 
> I roughly agree with this. The crypto is fairly
> straightforward but the architecture for moving the data
> around needs serious consideration.I don't think it would be a
> disaster in SEC, but based on experience with, for instance
> ACME, it would need a lot of apps input to avoid screwing that
> side up.
> 
> -Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 03 Feb 2022 11:29:19 +1100

> Fortunately or unfortunately, I don't know what happened with

The details were properly arranged and the right expertise was brought in at the right points.  At least from where I stand that was mostly OK.

What I think Ekr refers to there is that the work in ACME was overwhelmingly application-side to an extent that surprised some people back then. This made things a little more difficult as a result.  Hindsight suggests that this work might be similar.  (Ekr and Richard understand this specific proposal better than I do, but their read is similar to my own.)

My view here is that this is always going to be hard because a lot of the important work we're doing crosses the artificial boundaries we construct to keep the management manageable.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Feb 2022 17:58:20 -0800

> properly arranged and the right expertise is brought in at the

That seems like a question we would need to resolve at the BOF,
perhaps by cutting the BOF questions more finely ("how many
security people want to work on this...?")

> Fortunately or unfortunately, I don't know what happened with

As MT said, there was just a lot of apps-type work work.

> developments of a WG and any document processing.

I agree with this.

-Ekr

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 3 Feb 2022 02:25:04 +0000

Hi!

From: Eric Rescorla <[email-masked]>
Sent: Wednesday, February 2, 2022 8:58 PM
To: John C Klensin <[email-masked]>
Cc: Matthew Byington <[email-masked]>; DISPATCH <[email-masked]>; Security ADs <[email-masked]>; Francesca Palombini <[email-masked]>
Subject: Re: [dispatch] Secure Credential Transfer Charter & BoF

On Wed, Feb 2, 2022 at 3:54 PM John C Klensin <[email-masked]<mailto:[email-masked]>> wrote:

[Roman] We (SEC ADs) are in lock step with ART (Francesca) to ensure that this work gets the appropriate consideration during this formative times, and should it end up as a WG.  The BoF will help us tease out a number of things, to include an appropriate home.  If it advances, we have experimented with different leadership models for WGs.  For example, among the recently chartered WGs, we have various AD swaps (e.g., OHAI in SEC area but with an ART AD; SCIM in ART but with a SEC AD).

Regards,
Roman

thanks,
   john

--On Wednesday, February 2, 2022 14:32 -0800 Eric Rescorla
<[email-masked]<mailto:[email-masked]>> wrote:

> On Wed, Feb 2, 2022 at 2:14 PM John C Klensin
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Matthew,
>>

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Feb 2022 23:44:11 -0500

Roman,

Thanks _very_ much.  That completely addresses my concerns.

   john

--On Thursday, February 3, 2022 02:25 +0000 Roman Danyliw
<[email-masked]> wrote:

> Cc: Matthew Byington <[email-masked]>; DISPATCH
> <[email-masked]>; Security ADs <[email-masked]>;
> Francesca Palombini <[email-masked]>
> On Wed, Feb 2, 2022 at 3:54 PM John C Klensin
> I still think that it would be useful to discuss this further
> at the BOF so everyone who needs it gets a better
> understanding of where the issues and boundaries lie and to,
> at least, get agreement from the SEC ADs to help Francesca
> keep an eye on developments of a WG and any document
> processing.
> 
> [Roman] We (SEC ADs) are in lock step with ART (Francesca) to
> ensure that this work gets the appropriate consideration
> during this formative times, and should it end up as a WG.
> The BoF will help us tease out a number of things, to include
> an appropriate home.  If it advances, we have experimented
> with different leadership models for WGs.  For example, among
> the recently chartered WGs, we have various AD swaps (e.g.,
> OHAI in SEC area but with an ART AD; SCIM in ART but with a
> SEC AD).
> 
> Regards,
> Roman
> 
> 
> 
> thanks,
>    john
> 
>