yaronf
commented
4 years ago Fixes, answers and clarifications to Yaron's Secdir feedback from 10/13/2019:
Overall, I tend to be suspicious of "restricted" profiles, and this is a case in point. An implementation of DTLS is no simpler than TLS and most would probably support both protocols. And basically anything supports HTTP.
This is not the case for this draft. Most of the usecases that I know of which are implementing it do not have a TLS and TCP stack because of limited code/RAM space..
So why would it make sense to define a whole new profile just to avoid using TCP very rarely (say, for daily certificate enrollment), when this profile even needs to include its own fragmentation/buffering mechanisms because the ASN.1 payloads are too long? In other words, we are introducing new and additional complexity with little or no performance gain.
The ACE WG deals with constrained devices and environments. Often these devices use a lightweight protocol like COAP that runs over UDP or DTLS.
- Only certificate-based client authentication is supported. Hopefully some time soon we'll be able to use PAKE here, to bootstrap the PKI.
Agreed. This has been brought up before. And this draft does not recommend against other types of authentication that could be added in separate documents. The only thing that we are removing is HTTP basic authentication that existed in EST which is not possible now with COAPS. Other forms of authentication are definitely possible to be specified separately.
- "Crypto agility is important" - this statement is somewhat meaningless: do we require more than one cipher suite, which would ensure some level of agility?
This statement is just boilerplate for agility as we always recommend. I guess we could remove it, but I still see value in it as vendors would gain some performance improvement by adopting X25519 in the future. We are not mandating it here though as it is fairly new and most constrained devices do not support it.
Please either remove the statement or actually recommend X25519. As it is, a developer is not getting a clear message.
- Also, when we say "Sec. 4.4 of RFC 7925" do we mean only Sec. 4.4 or also the subsections: 4.4.1 etc.
Subsections as well.
Sec. 4.4 is long and complicated (possibly onerous, too). If you recommend that it be followed, it should have a sentence of its own and not just a clause where the main sentence is about X25519. And you might want to mention that this includes certificate URLs, revocation through software updates, and other stuff mentioned in that section.
- "in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups". This is probably true for an older version of the draft, I couldn't find anything to support it in -32.
DTLS 1.3 ClientHello and ServerHello inherit all the extensions from TLS 1.3 (RFC8446) as explained in draft-ietf-tls-dtls13 section 5.3 and TLS 1.3 is where Supported Groups are defined.
OK.
- "the Finished message must be computed" - this whole paragraph is unclear. Are we changing the Finished/MAC computation in DTLS (if so, this must be pointed out very clearly)? Or are we explaining a point about channel binding (if we are, this doesn't come across).
We are not changing DTLS. We are just repeating for clarity. The previous paragraph talks about how the Finished message is used in the CSR to provide PoP. And this paragraph explains how the Finished/MAC is calculated in DTLS 1.2/1.3 in order to add it in the CSR if there is fragmentation.
- Similarly for the following paragraph: is this a performance optimization, or a change to DTLS?
We are not changing DTLS here either. We just say you can run a bunch of requests in the same DTLS connection. That deviates from EST where it was more common to run transaction per connection.
So please clarify the text.
And by the way, why are standard session resumption mechanisms not used?
Good point. We are bringing up the use of DTLS Connection ID extension and DTLS session resumption when you want to do new transactions after a long time. That is in the next paragraph (last paragraph of Section 4)
BTW, I went and removed "1.3" in that text because resumption applies to 1.2 and 1.3.
- I don't see value in the short EST URI paths given that most of the "weight" is in ASN.1 data, and the paths are negligible in comparison. Moreover, if the paths are different, shouldn't this document formally UPDATE RFC 7030? I think it is no longer a profile.
We are not updating EST. We are adopting it to exist in the COAP constrained world.
Yes, the Introduction says so as well. But if you're changing the well-known URIs, that's a change to EST. So engineering-wise, this is fine (although I am not convinced by the reasoning below). But formally, this is a protocol change.
This issue with the long URIs was discussed in the mailing list as well. Initially we had kept the long URIs. But note that a /crt or /att request does not have payload. Also a CSR using ECDSA key could be 100-200B. So "simpleenroll", "simplereenroll", "serverkeygen" would add 10% of payload. Note some constrained mediums (of a few kbps) may leave maximum payload length of just 128B and in these cases 5-10 bytes are important and could trigger an unnecessary extra fragment that loads the medium.
- Non-default server port: the examples include an IPv6 address in addition to the port number. Is there a way to use relative URIs (omitting the IP address) but include a port number? The server may not know its own IP address (IPv4 with NAT) or the address may be dynamic.
Yes this is possible. Check the examples
coaps://example.com:<port>/...
No, this is not a relative URI, because you mention "example.com" (a DNS name, not an IP, but still an absolute URI). I believe the answer to my question is unfortunately No.
- The server MUST support the default /.well-known/est root resource, but then in the next sentence we discuss non-default URIs. In the case of the server having multiple "identities" (the main purpose of the "arbitrary label", AFAIU), the root resource is confusing - which identity is it associated with? And then how is discovery managed for each identity, and is there a way to discover the identities?
These are pretty common concepts in COAPS, so we did not expand in this draft. An EST-coaps server could serve different Labels that correspond to different client cert profiles. He could show that it supports them in any client resource discovery or he could only send them to clients that are supposed to get them (remember the client has been authenticated already in the DTLS session). That behavior is not defined or mandated by COAP or EST-coaps. In the most common case the server would tell the clients it supports a few resources/labels and the clients will be pre-configured to use the appropriate one based on config or bootstrapping criteria.
If this is common knowledge, fine. If you could point to a written description, even better.
- There is nowhere in this document a full formal definition of content type TBD287 (a single cert).
It is in Table 5 where we say that RBD287 is application/pkix-cert .
OK
- Content type negotiation: I can see how it works for enrollment. But in the case of /cacerts, if the server has a list of certs in its explicit TA store (e.g. to support rollover), how can TBD287 (a single cert) make sense?
A single cacert only makes sense for cases where there a single root PKI. In these cases the cacerts will only have one cert in them. There are deployments like that with a single root. Not all deployments trust certs from many roots.
Yes, but this assumes the root certificate will never be rolled over. I don't think we should encourage deployments that don't have any provisions in case of a PKI breach or simply root cert expiration.
- It is mighty confusing to denote "content format" by "ct" (presumably, this stands for "content type").
Yes, it is content type. That is how COAP defines it. You can check out https://tools.ietf.org/html/rfc7252#section-7.2.1
- "ASN.1 encoded in binary format" - I think this should be, "DER-encoded ASN.1, in its native binary form".
Thanks. Fixed.
- Please don't use "he" and "she" for the server and the client. Both are merely "it".
Personally I think depicting one as she and the other as he provides more clarity in the text.
Glad to fix it if there is a documented IETF rule against it though.
I am not a native English speaker but to me this is just plain strange usage. You don't want your readers to be distracted by non-standard language use.
- "The Registrar MUST authenticate and optionally authorize the client requests" - this statement is too weak. The Registrar must also ensure that clients only send CSRs that pertain to their authenticated identity (channel binding), even when POP-linking is not used. I think this is worthy of its own subsection, describing the validation required for each particular EST flow.
DTLS channel-binding is indeed useful We bring it up in Section 4 that talks about DTLS. We don't use any normative language because it is not specific to EST-coaps,, it refers to DTLS in general. We do the same thing about requiring Extended Master Secret [RFC7627] that Ben K. brought up. We didn't want to reiterate all possible DTLS protections unless they relate to EST-coaps specifically.
PoP at the Registrar or even without the Registrar is not mandatory by EST or EST-coaps. What we say is
When proof-of-possession is desired, a set of actions are required regarding the use of tls-unique, described in Section 3.5 in [RFC7030].EST RFC7030 says
[...] clients SHOULD link identity and POP by embedding tls-unique information in the certification request. If tls-unique information is included by the client, the server MUST verify it. The EST server MAY reject requests without tls-unique information as indicated by server policy.Requiring PoP linking in the CSR is considered pretty aggressive. So we stick with the SHOULD, MAY language in RFC7030 and we don't add any more normative language in EST-coaps.
I'm not sure we are talking about the same thing here: I was complaining about the "optionally authorize" text. I think the Registrar SHOULD (or MUST) verify that the CSR relates to the client's authenticated identity. Otherwise what use is authenticating the client in EST? Is this considered "aggressive"? Are there real-life use cases where this requirements cannot be followed?
- The following paragraph is not clear: is PoP-linking useful/recommended/mandated in this scenario? IMO there should be some 2119 word regarding server-side validation of the tls-unique.
We did not add more normative language because EST RFC7030 did not include normative language here either. We could say that "if there is an RA in the middle the server MUST disregard PoP linking". The issue is that servers need to know there is an RA in the middle. And that can be tricky. It can be done by using id-kp-cmcRA bit in the Registrar certificate provided to the server, but that is almost always not the case as we have seen. In other cases, the Registrar may use usr/pwd to authenticate to the EST server and in this case the server does not know he is the registrar unless he has a special registrar usr/pwd. So, mandating or unmandating PoP linking in general is not something we wanted to do for the Registrar or plain server case.
I understand the rationale, but the end result is still confusing.
- "Table 1 contains the URI mappings between EST-coaps and EST that the Registrar MUST adhere to." But the immediately preceding paragraph describes a case where a server-side generation on the EST-coaps side is mapped to client-side generation on the EST-HTTPS side, which is not a Table 1 mapping!
Good point. I rephrased this a bit to show that the paragraph above is an exception for Table 1. It now reads
A deviation from the mappings in Table 1 could take place if clients that leverage server-side key generation preferred for the enrolled keys to be generated by the Registrar in the case the CA does not support server-side key generation. Such a Registrar is responsible for generating a [...]Yes.
- "the encrypted CMS EnvelopedData blob MUST be converted at the Registrar" - can this be done without decrypting the blob, IOW must the Registrar be privy to the key wrapping key?
Oh yeah, we don't mean for the Registrar to decrypt and convert. Here we just mean to converts from based-64 of what is coming from the plain EST CA into binary CBOR for what is sent down to the client. So we are just converting the format, we are not decrypting.
OK, please say so explicitly.
- The Registrar must support resource discovery: does it mean that resource discovery messages are simply proxied upstream, or that the Registrar presents a simpler resource structure (maybe with no discovery) to its clients while performing discovery upstream?
The registrar terminates EST-coaps, so he is responsible for support discovery and advertising the resources he is expecting. These are mapped internally to EST CA resources upstream, but it is up to the Registrar to do that translation after being configured to talk to the CA.
- Security Considerations: there's a long discussion about replacing the implicit TAs with explicit ones. If we (rightly) mandate that the client re-verify the server's cert after getting the /certs response, we are losing most of the minor performance gain that keeping the DTLS connection open might have given us. So why not unambiguously mandate the simpler "MUST close the connection after /certs" instead? Besides, /cacerts is a very rare operation. Why optimise it at all?
This behavior existed from EST (RFC7030), the only thing we are changing here is that we allow for the connection to stay open which EST did not.
Re-establishing a new connection does not impose only one extra signature verification. It also includes new ephemeral key generation and key exponentiation in order to establish the shared DTLS key. We would like to avoid those.
Note that we used "SHOULD" to tell clients to go back and re-verify the connection against the new Explicit TA. The MUST only applies to using the new Explicit DB from now on.
I suggest you reconsider this optimization against the added complexity that is almost guaranteed to produce incorrect implementations and security issues.
- "Improper CSR requests" - what are they? What's the server supposed to do? Please give a reference.
I rephrased to "improperly formatted". This sentence just says that the server should not crash if the CSR is poorly formatted. I guess we could remove it, but I do think it still adds some value even though this goes without saying.
I'm not sure it adds value, because the only "recovery" is for the server not to crash. The client is still left without a certificate.
- A.3, response: I may be missing something, but the binary blob "3081...9fd9" does not parse as PKCS#8 to me.
Indeed, the "3081...9fd9" is not PKCS#8. It is PKCS#10 as this is the CSR request (content-type 286). The PKCS#8 private key comes in the "30818..." blob (content-type 284) from the server.
Right, sorry.
csosto-pk
kaduk
Fixes, answers and clarifications to Yaron's Secdir feedback from 10/13/2019:
This is not the case for this draft. Most of the usecases that I know of which are implementing it do not have a TLS and TCP stack because of limited code/RAM space..
The ACE WG deals with constrained devices and environments. Often these devices use a lightweight protocol like COAP that runs over UDP or DTLS.
Agreed. This has been brought up before. And this draft does not recommend against other types of authentication that could be added in separate documents. The only thing that we are removing is HTTP basic authentication that existed in EST which is not possible now with COAPS. Other forms of authentication are definitely possible to be specified separately.
This statement is just boilerplate for agility as we always recommend. I guess we could remove it, but I still see value in it as vendors would gain some performance improvement by adopting X25519 in the future. We are not mandating it here though as it is fairly new and most constrained devices do not support it.
Subsections as well.
DTLS 1.3 ClientHello and ServerHello inherit all the extensions from TLS 1.3 (RFC8446) as explained in draft-ietf-tls-dtls13 section 5.3 and TLS 1.3 is where Supported Groups are defined.
We are not changing DTLS. We are just repeating for clarity. The previous paragraph talks about how the Finished message is used in the CSR to provide PoP. And this paragraph explains how the Finished/MAC is calculated in DTLS 1.2/1.3 in order to add it in the CSR if there is fragmentation.
We are not changing DTLS here either. We just say you can run a bunch of requests in the same DTLS connection. That deviates from EST where it was more common to run transaction per connection.
Good point. We are bringing up the use of DTLS Connection ID extension and DTLS session resumption when you want to do new transactions after a long time. That is in the next paragraph (last paragraph of Section 4)
BTW, I went and removed "1.3" in that text because resumption applies to 1.2 and 1.3.
We are not updating EST. We are adopting it to exist in the COAP constrained world.
This issue with the long URIs was discussed in the mailing list as well. Initially we had kept the long URIs. But note that a /crt or /att request does not have payload. Also a CSR using ECDSA key could be 100-200B. So "simpleenroll", "simplereenroll", "serverkeygen" would add 10% of payload. Note some constrained mediums (of a few kbps) may leave maximum payload length of just 128B and in these cases 5-10 bytes are important and could trigger an unnecessary extra fragment that loads the medium.
Yes this is possible. Check the examples
coaps://example.com:<port>/...These are pretty common concepts in COAPS, so we did not expand in this draft. An EST-coaps server could serve different Labels that correspond to different client cert profiles. He could show that it supports them in any client resource discovery or he could only send them to clients that are supposed to get them (remember the client has been authenticated already in the DTLS session). That behavior is not defined or mandated by COAP or EST-coaps. In the most common case the server would tell the clients it supports a few resources/labels and the clients will be pre-configured to use the appropriate one based on config or bootstrapping criteria.
It is in Table 5 where we say that RBD287 is application/pkix-cert .
A single cacert only makes sense for cases where there a single root PKI. In these cases the cacerts will only have one cert in them. There are deployments like that with a single root. Not all deployments trust certs from many roots.
Yes, it is content type. That is how COAP defines it. You can check out https://tools.ietf.org/html/rfc7252#section-7.2.1
Thanks. Fixed.
Personally I think depicting one as she and the other as he provides more clarity in the text.
Glad to fix it if there is a documented IETF rule against it though.
DTLS channel-binding is indeed useful We bring it up in Section 4 that talks about DTLS. We don't use any normative language because it is not specific to EST-coaps,, it refers to DTLS in general. We do the same thing about requiring Extended Master Secret [RFC7627] that Ben K. brought up. We didn't want to reiterate all possible DTLS protections unless they relate to EST-coaps specifically.
PoP at the Registrar or even without the Registrar is not mandatory by EST or EST-coaps. What we say is
EST RFC7030 says
Requiring PoP linking in the CSR is considered pretty aggressive. So we stick with the SHOULD, MAY language in RFC7030 and we don't add any more normative language in EST-coaps.
We did not add more normative language because EST RFC7030 did not include normative language here either. We could say that "if there is an RA in the middle the server MUST disregard PoP linking". The issue is that servers need to know there is an RA in the middle. And that can be tricky. It can be done by using id-kp-cmcRA bit in the Registrar certificate provided to the server, but that is almost always not the case as we have seen. In other cases, the Registrar may use usr/pwd to authenticate to the EST server and in this case the server does not know he is the registrar unless he has a special registrar usr/pwd. So, mandating or unmandating PoP linking in general is not something we wanted to do for the Registrar or plain server case.
Good point. I rephrased this a bit to show that the paragraph above is an exception for Table 1. It now reads
Oh yeah, we don't mean for the Registrar to decrypt and convert. Here we just mean to converts from based-64 of what is coming from the plain EST CA into binary CBOR for what is sent down to the client. So we are just converting the format, we are not decrypting.
The registrar terminates EST-coaps, so he is responsible for support discovery and advertising the resources he is expecting. These are mapped internally to EST CA resources upstream, but it is up to the Registrar to do that translation after being configured to talk to the CA.
This behavior existed from EST (RFC7030), the only thing we are changing here is that we allow for the connection to stay open which EST did not.
Re-establishing a new connection does not impose only one extra signature verification. It also includes new ephemeral key generation and key exponentiation in order to establish the shared DTLS key. We would like to avoid those.
Note that we used "SHOULD" to tell clients to go back and re-verify the connection against the new Explicit TA. The MUST only applies to using the new Explicit DB from now on.
I rephrased to "improperly formatted". This sentence just says that the server should not crash if the CSR is poorly formatted. I guess we could remove it, but I do think it still adds some value even though this goes without saying.
Indeed, the "3081...9fd9" is not PKCS#8. It is PKCS#10 as this is the CSR request (content-type 286). The PKCS#8 private key comes in the "30818..." blob (content-type 284) from the server.
Commit with all the changes is here https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674fe8e403d30467c98abfb