Subject: Re: [Rats] AD review of draft-ietf-rats-yang-tpm-charra-11

From: Roman Danyliw <[email-masked]>
Date: Mon, 10 Jan 2022 22:59:28 +0000

Hi Eric!

Thanks for the detailed explanation.  For easier tracking, I've pruned thread down to the issues that require further commentary.  If my original text/your response is not below, please consider the matter resolved per your recommended edits or thanks for your explanation/no action required.

When ready, please publish a -12 out of the github repo.

More inline ...

> -----Original Message-----
> From: Eric Voit (evoit) <[email-masked]>
> Sent: Tuesday, November 16, 2021 9:48 AM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; Guy Fedorkow <[email-masked]>; Birkholz, Henk
> <[email-masked]>
> Subject: FW: AD review of draft-ietf-rats-yang-tpm-charra-11
> 
> Hi Roman,
> 
> Thanks for the detailed questions and recommendations.  Several of us
> authors have gotten together on a joint response with comments coordinated
> across this document, and the RIV document.  Details below....
> 
> > Hi!
> >
> > I performed an AD review on draft-ietf-rats-yang-tpm-charra-11.  Thanks
> for this
> > document.  My comments are below.

[snip]

> > ** There are eight authors.  Customarily (per RFC7322), the total number
> of
> > authors/editors on the first page is limited to five.  Could I have a
> write-
> > up/confirmation on why this current arrangement makes sense.
> 
> The initial YANG model was pieced together from the submissions of many
> vendor YANG models.  Reflecting the broad contributions of many in the
> industry seemed important as YANG model leadership far too often driven by
> too small a group.  And we wanted the Engineering organizations of lots of
> vendors to contribute parts.  And we wanted the security organizations to
> also contribute on the operations of the TPM.
>

Understood.

Nancy  (as document shepherd): can you please add this to the shepherd write-up.  This question will be asked during IESG review.

> > ** Section 2.  Per "A fresh nonce with an appropriate amount of entropy
> MUST
> > be supplied ...", where can the guidance that characterizes "an
> appropriate
> > amount of entropy" be found?
> 
> I have included a new reference to the NIST publication "True Randomness
> Can't be Left to Chance: Why entropy is important for
> information security"
> https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=915121

Thanks for the reference.  I wasn't clear.  The real issue poking was what is an appropriate sized nonce?  Is there a minimum size we want to specify here or defer to the existing TPM2 guidance (as done later in the YANG module)

> 
> > -- Per the existing text in about verifying the appropriateness of the AK.
> Is there
> > a reference for that?
> 
> Could you provide more context, we don't understand this question.

Per the following text:

   RPC 'tpm20-challenge-response-attestation':  It must be verified that
      the certificate is for an active AK, i. e. the certificate
      provided is able to support Attestation on the targeted TPM 2.0.

My line of question was around how one verifies the relationship between the AK and the certificate, but after re-reading the text, I believe the answer is that the AK is the private key associated with the certificate.

Regards,
Roman

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 13 Jan 2022 20:48:50 +0000

Hi Roman,

Thanks for the comments.  In-line

> Hi Eric!
> 
> Thanks for the detailed explanation.  For easier tracking, I've pruned
thread
> down to the issues that require further commentary.  If my original
text/your
> response is not below, please consider the matter resolved per your
> recommended edits or thanks for your explanation/no action required.
> 
> > Cc: [email-masked]; Guy Fedorkow <[email-masked]>; Birkholz,
> > Henk <[email-masked]>
> > authors have gotten together on a joint response with comments
> > coordinated across this document, and the RIV document.  Details
below....
> > The initial YANG model was pieced together from the submissions of
> > many vendor YANG models.  Reflecting the broad contributions of many
> > in the industry seemed important as YANG model leadership far too
> > often driven by too small a group.  And we wanted the Engineering
> > organizations of lots of vendors to contribute parts.  And we wanted
> > the security organizations to also contribute on the operations of the
TPM.
> >
> 
> Understood.
> 
> Nancy  (as document shepherd): can you please add this to the shepherd
write-
> up.  This question will be asked during IESG review.
> 
> > I have included a new reference to the NIST publication "True
> > Randomness Can't be Left to Chance: Why entropy is important for
> > information security"
> Thanks for the reference.  I wasn't clear.  The real issue poking was what
is an
> appropriate sized nonce?  Is there a minimum size we want to specify here
or
> defer to the existing TPM2 guidance (as done later in the YANG module)

Not taking a position beyond TPM vendor guidance is preferred.  The main
reason is that the speed of processing a TPM Quote is hardware specific.
Some chips can only do one per second.  On the other hand, it is quite
possible to create hardware which could run three or four order magnitudes
faster.  Or more.   Nonce size should be a function of how many values could
legitimately be generated, stored, and replayed back as part of an attack.

> My line of question was around how one verifies the relationship between
the
> AK and the certificate, but after re-reading the text, I believe the
answer is that
> the AK is the private key associated with the certificate.

This is correct.  I have tweaked the Security Consideration text to say: "It
must be verified that the certificate is for an active AK, i.e., the quote
signature associated with RPC response has been generated by an entity
legitimately able to perform Attestation on the targeted TPM 2.0."

Eric

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 13 Jan 2022 21:04:34 +0000

Hi Eric!

Thanks for the explanation.  To be explicit, based on what you said, the current text makes sense as is -- no action is required.  Please publish a revised draft with the previously discussed edits at your convenience and we can keep things moving.

Roman

> Sent: Thursday, January 13, 2022 3:49 PM
> Cc: Henk Birkholz <[email-masked]>; Guy Fedorkow
> <[email-masked]>; [email-masked]