Hi John, Thank you for this review. I have converted the points raised below into github issues. See [1]. I will be tagging you on github for items where I need additional input or that require further discussion.
Mališa [1] https://github.com/ace-wg/est-oscore/issues > On Sep 19, 2023, at 11:48, John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > 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 > Ace@ietf.org <mailto:Ace@ietf.org> > https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
