Subject: [Rats] I-D Action: draft-birkholz-rats-uccs-01.txt

From: Laurence Lundblade <[email-masked]>
Date: Wed, 3 Jun 2020 12:24:20 -0700

Perfectly in favor of the UCCS tag.

The security discussion in this seems like the tail wagging the dog. UCCS is the tail. Conveyance Security is the dog. 

I think this draft should only say it is up to you to attach a dog to this tail.  CWT’s are a dog+tail so you don’t have to worry. UCCS is tail-only so you do. Your choice of dog is of course up to you. Choose wisely.  

Note also that UCCS is useful if you don’t like the type of dog that CWT comes with. It allows you use different types of dogs with a CWT-style tail.

:-)

Or said another way, I’m not so much in favor of section 3. Anything about RATS / EAT security should be in RATS / EAT docs, not here. Would like the draft to say simply “Be warned. UCCS does not have the security that CWT does. If you use UCCS, you should add security”.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 4 Jun 2020 12:11:12 -0700

At least one private response seems to have misunderstood my intent. Let me try again.

I am saying that most security discussion should be moved out of UCCS and into use case specific documents and contexts:
- UCCS as RATS claims
- UCCS as RATS endorsements
- UCCS as RATS attestation results
- UCCS in GlobalPlatform
- UCCS in ACE
- UCCS in future unanticipated use case #1 that has nothing to do with RATS or ACE
- UCCS in future unanticipated use case #2 that has nothing to do with RATS or ACE

It seems better factoring to associate the security model with the use cases than with the data structure format. It seems hard to anticipate the security models needed for future use cases.

In the three RATS uses of UCCS (claims, endorsements, results), the characteristics of the security needed vary a lot and all three are not all covered here.

The text doesn’t seem to anticipate securing UCCS with CMS or a TPM-based signing scheme. It focuses on TLS / Secure Channels. 

The security of nested EATs seems better discussed in EAT.

CWT is part of the establishment of the Verifier’s trust in an Attester. That topic requires Endorsements and seems better in the context of RATS architecture or related. 

All that said, I don’t think the section 3 security discussion is harmful, just that it may become outmoded and necessarily bypassed as the use cases fill in.

LL

> On Jun 3, 2020, at 12:24 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jun 2020 13:53:57 +0200

Hi Laurence,

> It seems better factoring to associate the security model with the use cases than with the data structure format.

There are many ways to (insert vegan version of “skin this cat”).

Generally, the IESG has not been happy with defining protocols without discussing their security, so UCCS will need some security considerations.  The pure admonition “write up your security considerations” makes a bad security considerations section.  Picking one use case (here: the one that motivates us to write this document now) seems like a good way to evoke the kinds of security considerations other application environments will have.

> It seems hard to anticipate the security models needed for future use cases.

Right, that’s why the text focuses on one usage environment.

> In the three RATS uses of UCCS (claims, endorsements, results), the characteristics of the security needed vary a lot and all three are not all covered here.

I don’t think we need to go as far as defining the security characteristics of those areas — we do need to explain how adding UCCS to these areas adds/changed security considerations.

> The text doesn’t seem to anticipate securing UCCS with CMS or a TPM-based signing scheme. It focuses on TLS / Secure Channels. 

Yes, that would be the one usage environment we are focusing on.

> The security of nested EATs seems better discussed in EAT.

That may very well be.
The main point here is that, for something communicated over the secure channel to inherit the authentication and authorization properties of that channel requires a strong relationship.  There is a difference between saying “I saw Bob buy an apple” and “My neighbor told me he saw Bob buy an apple” — the EAT encapsulation is the equivalent of “My neighbor told me”.

> CWT is part of the establishment of the Verifier’s trust in an Attester. That topic requires Endorsements and seems better in the context of RATS architecture or related. 

I’m sure that some form of architecture document can provide a refined view of this.

> All that said, I don’t think the section 3 security discussion is harmful, just that it may become outmoded and necessarily bypassed as the use cases fill in.

But that is true: the security considerations here are like the package insert for some medication — you should read this, but you should also heed the instructions from your doctor (i.e., the standard that specified usage of UCCS in a specific usage environment) and read up on additional information, in particular about side effects with other medication (EAT, CMS, TPM).

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 12 Jun 2020 13:34:40 -0700

Still seems like standardizing tails generally and then going into detail on how to use a tail with poodles when there are many other kinds of dogs out there.  And because of lack of context (lack of normative reference to EAT and RATS architecture) it is not the best description of the poodle use case.

Note there is use of RATS architecture terms in this UCCS document (attesting environment, endorsement).

> On Jun 10, 2020, at 4:53 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Laurence,
> 

CWT has pretty minimal security considerations. UCCS goes into security discussion beyond CWT, like the use of the TEE to protect keys.

> I don’t think we need to go as far as defining the security characteristics of those areas — we do need to explain how adding UCCS to these areas adds/changed security considerations.

So, the one use case that is the focus of this document is RATS attester->verify conveyance? That should be stated explicitly and the lack of coverage for the use with endorsements and attestation results should be called out. 

> Yes, that would be the one usage environment we are focusing on.

So maybe call out this narrow focus and lack of coverage for CMS and such?

> I’m sure that some form of architecture document can provide a refined view of this.

So should UCCS discuss Endorsements as that is a key part of securing conveyance from attester->verifier?

> But that is true: the security considerations here are like the package insert for some medication — you should read this, but you should also heed the instructions from your doctor (i.e., the stan…

I think I’d call EAT and RATS diseases for which UCCS is a medication. :-)

UCCS usually needs pairing with meds like TLS, IPsec, CMS and TPM signing.

(Not really sure which disease CWT was invented for as I’m not so familiar with ACE, OAuth and such)

So the package insert is for one specific disease when the medication is good for others we know of today. The insert is only partial information for that disease and you must talk Dr. Birkholz before you take it.

I think I’ve said pretty much everything I have to say on this and still think same - it is not harmful, but likely to be outmoded.

LL

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 14 Jun 2020 14:27:34 -0700

> Generally, the IESG has not been happy with defining protocols without discussing their security, so UCCS will need some security considerations.  The pure admonition “write up your security consid…

Depending on the IESG, you may also get asked to mention situations that
could cause big problems in use cases other than the one being considered,
even if they are non-issues for the specific use case in question, as a way
to avoid potential "gotcha"s for the future documents that provide
alternative use cases/analyses.

-Ben