Review of draft-ietf-ace-coap-est-oscore-02 Hi,
Below is my review of draft-ietf-ace-coap-est-oscore-02. This does not seem ready yet. * “EST-coaps ([RFC9148])” This is in parathesis, other references are not. * OLD “DTLS [RFC6347<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC6347>] [RFC9147<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC9147>]” NEW “DTLS [RFC6347<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC6347>]” RFC 6347 is obsoleted. I think the rule is to not refer to obsolete RFC unless needed. * ”instead of HTTP [RFC9110<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC9110>] [RFC9112<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC9112>] and TLS [RFC8446<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC8446>]” Any reason that this is referring to HTTP/1.1 only? HTTP/2 and HTTP/3 seems like much better more modern options. * You seem to use the old BCP14 boilerplate. Use {::boilerplate bcp14} in md * The trust anchor terminology from RFC 6024 ”used to verify digital Signatures” does not work with 3/4 of the EDHOC methods. Needs to be rewritten. * ”is the SubjectPublicKeyInfo structure” How does this work efficiently with EDHOC? * A Trust Anchor database is always required, not just for certificates (I have not read RFC 7030). ” enabling the client to authenticate the server” is always required. * ”Connection-based proof-of-possession”, I assume this means the client might not be authenticated (verify identity) in EDHOC. In that case this needs to be described and discussed. * Should ”32 bytes” seems a bit much for something trying to be lightweight. * Section 3.4 talks about ”certificates”. It is not clear which types of certificates this is about. EST-oscore use certificates on two layers (In EDHOC and on top of OSCORE). - Figure 1 does also not illustrate the use of I-D.ietf-core-oscore-edhoc * Figures 1 and 2 would look much nicer with aasvg * Figure 3 would look much nicer as a Table. * I-D.ietf-cose-x509 has been published as RFC 9360 * EST with hop-by-hop protection over a proxy seems like a very bad security architecture. Unless RFC 9148 makes this NOT RECOMMENDED, I think this draft should update RFC 9148 and do that. Server generated private keys visible to proxies should be MUST NOT. I have not read RFC 9148. * ”TBD: Compare with RFC9148” Need to be fixed before any WGLC. * OLD: Section 4 of [RFC6955<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC6955>] NEW: Section 6 of [RFC6955<https://www.ietf.org/archive/id/draft-ietf-ace-coap-est-oscore-02.html#RFC6955>] * ”The EST client obtained the CA certs including the CA's DH certificate using the /crts function” This seems very inefficient. Why not just use G_Y from EDHOC? The Client/Initiator can use the cipher suite to get the curve it wants. I think this should be added as on option. * “As per [RFC8613], the HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms defined for COSE [RFC9052].” I would say that the quoted sentence is an erratum in OSCORE. I would suggest deleting that sentence. Should be one of the HMAC algorithms defined for COSE or one of the hash functions defined for COSE. COSE does not have any general HKDFs defined. They are “direct+HKDF-SHA-512” and only make sense if you use them in COSE and not in OSCORE. EDHOC specifies that the output to OSCORE can be HMAC-SHA-384. * “External Authorization Data (EAD) fields of EDHOC are intentionally not used to carry EST payloads because EDHOC needs not be executed in the case of re-enrollment.” This seems to me like the wrong decision. Using EAD would be much more efficient for the first enrollment. How common and important is re-enrollment? By using EDHOC efficiently I think the client might be able to send the CSR in message_3 and get the cert in message_4. * “| UDP or TCP |” I suggest deleting this layer. Both CoAP and HTTP can be transported over other (or more)( or less) things. Having UDP and TCP in this figure do not add anything. * The document makes heavy use of EDHOC and states that C509 might be use as an optimization. Other parts of the draft seems 100% ASN.1. EDHOC makes heavy use of CWT/CSS/C509. It would make sense to be able to request the server to issue C509 certificates. Currently that does not seem to be possible. * This is probably handled by other drafts, but I think the draft should summarize some very basic high-level things in the introduction. Is the client assumed to have some form of credential before starting EST-oscore. In that case what kind of credential. The whole point of certificates is to bind a public key with an identity. How does the server verify the identity? If things are out of scope, it is often best to state that. * "Constrained Application Protocol (CoAP), Concise Binary Object Representation (CBOR) and the CBOR Object Signing and Encryption (COSE) format" ... and more IETF uses the Oxford comma. Cheers, John
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
