Re: [Rats] comments on draft-birkholz-rats-uccs

Hi,

Of course Jim knows where work should be in IETF.

I also concur that ACE, but *not* COSE, could be a reasonable
alternate home for UCCS.

Cheers.
- Ira

*Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted
Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: blueroofmusic@gmail.com
<blueroofmusic@gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Mon, Aug 17, 2020 at 4:14 PM Jim Schaad <ietf@augustcellars.com> wrote:

>
>
> -----Original Message-----
> From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
> Sent: Monday, August 17, 2020 3:49 AM
> To: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>; rats@ietf.org
> Cc: Jessica Fitzgerald-McKay <jmfitz2@cyber.nsa.gov>; Jim Schaad <
> ietf@augustcellars.com>; draft-birkholz-rats-uccs@ietf.org
> Subject: Re: [Rats] comments on draft-birkholz-rats-uccs
>
> Thanks Jess!
>
> the discussion on where this is incubated was deliberately scoped down to
> provide:
>
> * a finite and still useful set of Security/Privacy considerations, and
> * relatively specific guidance and context on how prerequisites for usage
> look like.
>
> The concept of an UCCS tag goes beyond RATS, of course. The usage of an
> UCCS tag alas requires some application-specific "rules".
>
> That said, we will discuss this topic specifically asap. Also, Jim is now
> in CC (Hi Jim) and maybe he can weigh in on this topic?
>
> With respect to your technical comments, please give us some time to come
> back with well-formed answers. I do not want to barge ahead with half-baked
> replies :-)
>
> Viele Grüße,
>
> Henk
>
> On 07.08.20 16:01, Jessica Fitzgerald-McKay wrote:
> > Hi, UCCS authors,
> >
> > Mike Jenkins and I reviewed the UCCS draft. Our comments are below.
> > Happy to talk through any of them with the group.
> >
> > Thanks,
> > Jess
> >
> > The intent of this draft is similar to the key concept of EST - use
> > the authentication of the secure session connection. Most schemes
> > build on this concept leave a lot of banana peels laying around, some
> > of which we describe here. In general, this does not seem appropriate
> > to the scope of RATS. We feel that COSE might be a more appropriate
> > work group to think these issues through.
>
>
> [JLS] To me COSE is exactly the wrong place to do this.  If it is not done
> in RATS then ACE would be the appropriate location.  Doing it in COSE would
> be something along the lines of "If you don't use the core technology of
> this group then you should?"
>
> >
> > - If you're using a static symmetric key for authentication (as one
> > might with highly-constrained devices), you can only authenticate a
> > net, not an entity. The receiver cannot differentiate between
> > authenticating the sender and authenticating itself.
>
> [JLS] I don't see this as being interesting for this document  The exact
> same set of problems exist if you use HMAC or symmetric encryption with
> COSE where a static symmetric key is used.  The thing that might be
> interesting would be to talk about correspondences of the secure channel
> security and the equivalent COSE objects.
>
> >
> > - The authentication happens at the secure channel termination, not in
> > the channel-contents-using application. It's important how the
> > termination process vouches the authentication to the application. (In
> > EST, this question is how the EST server vouches the requestor's
> > identity to the CA server.)
> >
> > - A TEE only helps if the TEE application can punch through the REE
> > and set up the secure channel completely on its own. If the TEE relies
> > on the REE to set up the secure channel, you might as well just
> > operate in the REE.
> >
> > - There is a comment at the end of the introduction (!) about
> > transitioning back and forth between self-protected and
> > channel-protected CWT, "in a well-defined scope". Define the security
> > characteristics of that scope or get rid of the comment. You're
> > handing someone an awful lot of rope there.
> >
> > - The claims set should be treated as ephemeral by the recipient. It
> > shouldn't be stored, and can't be forwarded except as data originated
> > by the recipient. As soon as it emerges from the secure channel, it's
> > no more valid or meaningful than any other piece of unprotected data
> > in the application environment.
> >
> > _______________________________________________
> > RATS mailing list
> > RATS@ietf.org
> > https://www.ietf.org/mailman/listinfo/rats
> >
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>