Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 16 Dec 2019 14:02:06 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-ace-coap-est-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 4.  Per “the DTLS connections SHOULD only be kept alive for EST
messages that are relatively close to each other”, I think the text means that
some EST messages are more likely to occur one after another.  It would be
worth being clearer what these would be.

* Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does
Table 1 imply that when using EST-coaps the “longer names” from RFC7030
wouldn’t be valid?

* Section 5.2  Per “The latter ones are deemed to expensive …”, was difficult
to parse as the sentence prior has three things (instead of two).  Is this
sentence referring to the “not specified functions” only?

* Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite
this metric, please do.

* Section 5.8.  Per “In summary, the symmetrically encrypted key is included in
the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in
a server-side key generation scenario, where is the client getting the key to
decrypt the server computed key material?  Should the DecryptKeyIdentifier/
AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections
4.4.1.1/4.4.1.2 of RFC7030?

* Section 10.1.  Per “When server-side key generation is used, the constrained
device depends on the server to generate the private key randomly, but it still
needs locally generated random numbers for use in security protocols, as
explained in Section 12 of [RFC7925].”, is the “security protocols” referenced
here anything beyond DTLS?

* Section 10.1.  Per “In such occasions, checking the certificate revocation
status or authorizing the client using another method is important for the
server to ensure that the client is to be trusted.”

-- does this text suggest that expired+revoked certificates should not be used?

-- to word-smith:
s/for the server to ensure that the client is to be trusted/for the server to
raise its confidence that the client can be trusted/

* Section 10.1.  Per “More information about recommendations of TLS and DTLS
are included in   [BCP195]”, thanks for referencing BCP195.  Could you please
clarify with normative language if these recommendations SHOULD/MUST be
followed?

* Editorial
- Section 4.  Per “Authenticating and negotiating DTLS keys requires resources
on low- end endpoints and consumes valuable bandwidth”, I’m not sure this
sentence is needed.  Technically, “authenticating and negotiating DTLS keys
requires resources” on any endpoint.

- Section 4.
OLD: Given that after a successful enrollment, it is more likely that a new EST
transaction will take place after a significant amount of time, NEW: Given that
after a successful enrollment, it is more likely that a new EST transaction
will not take place for a significant amount of time,

- Section 5.5. Typo.  s/successfull/successful/

- Section 5.8.  s/Such scenarios could be when it is …/Such scenarios apply
when it is …/

- Section 5.8.  s/ client, or when the resources/client, when the resources/

- Section 5.8. s/Then the private key/The private key/

---

From: Jim Schaad <[email-masked]>
Date: Thu, 19 Dec 2019 17:32:29 -0800

A couple of comments below.  See [JLS]

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Monday, December 16, 2019 2:02 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Jim Schaad <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

* Section 4.  Per “the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other”, I think the text means that some EST messages are more likely to occur one after another.  It would be worth being clearer what these would be.

* Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does Table 1 imply that when using EST-coaps the “longer names” from RFC7030 wouldn’t be valid?
[JLS] This is being addressed via Alexey's discuss I think.

* Section 5.2  Per “The latter ones are deemed to expensive …”, was difficult to parse as the sentence prior has three things (instead of two).  Is this sentence referring to the “not specified functions” only?

* Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite this metric, please do.
[JLS] Do you really need a metric on the difference between the size of raw binary vs base6 encoded binary?  It is just 3 bytes vs 4 bytes (i.e  4/3)

* Section 5.8.  Per “In summary, the symmetrically encrypted key is included in the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in a server-side key generation scenario, where is the client getting the key to decrypt the server computed key material?  Should the DecryptKeyIdentifier/ AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections
4.4.1.1/4.4.1.2 of RFC7030?
[JLS] That would be the discussion of these attributes in paragraph 3 (about the middle)?  Or are you looking for something more?

* Section 10.1.  Per “When server-side key generation is used, the constrained device depends on the server to generate the private key randomly, but it still needs locally generated random numbers for use in security protocols, as explained in Section 12 of [RFC7925].”, is the “security protocols” referenced here anything beyond DTLS?

* Section 10.1.  Per “In such occasions, checking the certificate revocation status or authorizing the client using another method is important for the server to ensure that the client is to be trusted.”

-- does this text suggest that expired+revoked certificates should not be used?
[JLS] Yes, a revoked certificate would most likely not be used.  However, my personal expectation is that this would map more directly to a database associated with the CA as it is possible that the manufacturer could have gone under and not be doing CRLs in any event.

Jim Schaad

-- to word-smith:
s/for the server to ensure that the client is to be trusted/for the server to raise its confidence that the client can be trusted/

* Section 10.1.  Per “More information about recommendations of TLS and DTLS
are included in   [BCP195]”, thanks for referencing BCP195.  Could you please
clarify with normative language if these recommendations SHOULD/MUST be followed?

* Editorial
- Section 4.  Per “Authenticating and negotiating DTLS keys requires resources on low- end endpoints and consumes valuable bandwidth”, I’m not sure this sentence is needed.  Technically, “authenticating and negotiating DTLS keys requires resources” on any endpoint.

- Section 4.
OLD: Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, NEW: Given that after a successful enrollment, it is more likely that a new EST transaction will not take place for a significant amount of time,

- Section 5.8.  s/Such scenarios could be when it is …/Such scenarios apply when it is …/

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 23 Dec 2019 04:41:04 +0000

Hi Roman,

Thank you for the thorough review. 

Please check the response to your feedback in https://github.com/SanKumar2015/EST-coaps/issues/154 There we include the fixes we will make and our thoughts on a couple of your comments. 

Please let us know if you have any further objections.

Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Roman Danyliw via Datatracker
Sent: Monday, December 16, 2019 5:02 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

-- to word-smith:

* Editorial

- Section 4.

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 24 Dec 2019 15:42:29 +0000

Hi Roman, 

This commit https://github.com/SanKumar2015/EST-coaps/commit/222879c5d8fab836a7cb1d35cb128821ca790370 tries to address your feedback. The full discussion is in https://github.com/SanKumar2015/EST-coaps/issues/154 

Let us know if it does not make sense. 

Rgs,
Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Sunday, December 22, 2019 11:41 PM
To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

Hi Roman,

Panos

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Roman Danyliw via Datatracker
Sent: Monday, December 16, 2019 5:02 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)

-- to word-smith:

* Editorial

- Section 4.