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

From: Jessica Fitzgerald-McKay <[email-masked]>
Date: Fri, 7 Aug 2020 10:01:07 -0400

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.

- 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.

- 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.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 7 Aug 2020 09:46:12 -0700

Seems to me that one of these is also characteristic of CWT/COSE (character of symmetric keys) and the rest are potentially true of CWT/COSE.

Personally, I don’t think it is the IETF’s job to explain to implementers how to correctly use a TEE, SE, HSM or other restricted operating environments. That’s not a job that can be completed in a protocol document. Most implementers working with TEEs and similar already have the rope and we can’t really take it away from them. When I went to intro to writing security considerations session at the last Montreal IETF, one of the main points was that IETF can’t really control what implementers do.

That said, I do think it is the job of the IETF to create protocols that can make use of TEE’s and the like.

As I’ve mentioned before, I think UCCS should have a very minimal discussion on security in-the-absence-of-CWT/COSE because it’s not really possible to cover it well. There’s too many implementation environment and use case specific issues. Jessica’s comment is an illustration of that.

LL

> On Aug 7, 2020, at 7:01 AM, Jessica Fitzgerald-McKay <[email-masked]> 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.
> 
> - 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.
> 
> - 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 17 Aug 2020 12:48:47 +0200

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
> 
> 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.
> 
> - 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.
> 
> - 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 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.
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 17 Aug 2020 13:13:50 -0700

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Monday, August 17, 2020 3:49 AM
To: Jessica Fitzgerald-McKay <[email-masked]>; [email-masked]
Cc: Jessica Fitzgerald-McKay <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
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:
> 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?"

> 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.
 
> - 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.
> 
> characteristics of that scope or get rid of the comment. You're 
> handing someone an awful lot of rope there.
> 
> 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.
>

---

From: Ira McDonald <[email-masked]>
Date: Mon, 17 Aug 2020 18:22:37 -0400

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: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Mon, Aug 17, 2020 at 4:14 PM Jim Schaad <[email-masked]> wrote:

> Cc: Jessica Fitzgerald-McKay <[email-masked]>; Jim Schaad <
> [email-masked]>; [email-masked]
> 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
>
> [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?"
>
> >
> [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.
>
> >