csosto-pk
commented
5 years ago
- End of Section 6: "If necessary, the EST-coaps-to-HTTP Registrar will support resouce discovery according to the rules in Section 5.1." -> what about (also added letter to 'resouce') "The EST-coaps-to-HTTP Registrar MUST support resource discovery according to the rules in Section 5.1."
Thx. Fixed.
- Section 9.1: "These have been registered provisionally in the Expert Review range (0-255)" -> "These have been registered provisionally in the IETF Review or IESG Approval range (256-9999)"
Thx, fixed.
- Section 10.1: A client that pipelines EST-coaps /crts request with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests. If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. -> does the last requirement mean new DTLS connections to the same EST server? Or, new DTLS connections to any EST server(s) in the future?
The same EST server. It refers to pipelined requests in the same DTLS connection which implies same client, same server, same ports.
-> it is also unclear here whether the updated Explicit TA needs to replace an existing configured Explicit TA (e.g. obtained from an ANIMA voucher or a previous /crts request. ). I would think not, especially given that the verification of it failed in above text?
In general, when doing an EST cacerts or EST-coaps /crts you get the new truststore (latest Explicit TA) that you are supposed to trust going forward. That is when when the previous TA was either Implicit or Explicit TA (configured or fetched).
-> I wonder why the client would trust a new Explicit TA, if the EST server itself cannot be authenticated using that TA. It will disconnect and then upon next DTLS connection to the same server the handshake will fail against the new TA. And the client can't perform EST anymore until factory reset. Or is the expectation that it somehow will use another EST server for a second try?
As you are pointing out, this is not a likely scenario because the cacerts response better include the root cert to authenticate the EST-coaps server going forward or the clients will be dead in the water. This text is added to address the RFC7030 (Section 4.1.1) language that explicitly says that the very first time you go from an implicit to an explicit TA you are supposed to teardown the connection after you get the cacerts response and start using the new TA going forward.
In some usecases we don't want to renegotiate DTLS in constrained heavily utilized mediums and establish a new connection for enrollment after a cacerts request, so I added this text to say that it is OK to keep the same connection but make sure you check that the server cert in this connection still validates against the just received cacerts.
- Section 10.1: "depend in" -> "depend on"
Thx fixed.
- Section 10.1: "especially since the practicality of such an attack would not expose any messages exchanged with EST-coaps." -> rather complex sentence, what about ""especially since a 3SHAKE attack does not expose messages exchanged with EST-coaps."
Thx fixed.
- Section 10.1: "Regarding the Certificate Signing Request (CSR), a CA is expected to be able to enforce policies to recover from improper CSR requests." -> should be "an EST-coaps server is expected to" ? Because this specification and 10.1 describes the EST-coaps server, not a CA.
Thx fixed.
- Sections 5.1, 5.7, 10.2 : word "he" is used to refer to client or server. Maybe this should become "it" (not a person).
I went and made the sentences throughout the draft referring to client as "she" and the server "he". Better to be able to distinguish like that because "it" can be confusing.
End of Section 6: "If necessary, the EST-coaps-to-HTTP Registrar will support resouce discovery according to the rules in Section 5.1." -> what about (also added letter to 'resouce') "The EST-coaps-to-HTTP Registrar MUST support resource discovery according to the rules in Section 5.1." Because this Registrar operates to the CoAP client facing side exactly like a CoAP EST server. So it must support the same rules for discovery, or else it won't work (e.g. be not discoverable).
Section 9.1: "These have been registered provisionally in the Expert Review range (0-255)" -> "These have been registered provisionally in the IETF Review or IESG Approval range (256-9999)"
Section 10.1: A client that pipelines EST-coaps /crts request with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests.
If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. -> does the last requirement mean new DTLS connections to the same EST server? Or, new DTLS connections to any EST server(s) in the future? -> it is also unclear here whether the updated Explicit TA needs to replace an existing configured Explicit TA (e.g. obtained from an ANIMA voucher or a previous /crts request. ). I would think not, especially given that the verification of it failed in above text? -> I wonder why the client would trust a new Explicit TA, if the EST server itself cannot be authenticated using that TA. It will disconnect and then upon next DTLS connection to the same server the handshake will fail against the new TA. And the client can't perform EST anymore until factory reset. Or is the expectation that it somehow will use another EST server for a second try?
Section 10.1: "depend in" -> "depend on"
Section 10.1: "especially since the practicality of such an attack would not expose any messages exchanged with EST-coaps." -> rather complex sentence, what about ""especially since a 3SHAKE attack does not expose messages exchanged with EST-coaps."
Section 10.1: "Regarding the Certificate Signing Request (CSR), a CA is expected to be able to enforce policies to recover from improper CSR requests." -> should be "an EST-coaps server is expected to" ? Because this specification and 10.1 describes the EST-coaps server, not a CA.
Sections 5.1, 5.7, 10.2 : word "he" is used to refer to client or server. Maybe this should become "it" (not a person).