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

[Laurence Lundblade <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.

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

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

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. 

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

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

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

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

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

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