In draft-ietf-uta-tls13-iot-profile, in https://github.com/thomas-fossati/draft-tls13-iot/pull/84 we clarified that servers should not send trust anchors in TLS.
I opened https://github.com/thomas-fossati/draft-tls13-iot/issues/100 I think #83 is probably good advice, but I feel that there might be corner cases that we missing. This says the "server" should not transmit it's anchor. I would agree with this for device to cloud connections: the cloud server should not transmit any trust anchor that it thinks the client should already have. But, incomplete knowledge is an issue. a. some device-to-cloud deployments will pin an anchor, sometimes it's a self-signed certificate for the server. Never to be updated until the firmware is updated. Often used for *decades*... not good crypto hygiene, but very reliable! Clearly the client does not need that certificate if it has pinned it! But, how can the server know for sure? Often the challenge is then, how to migrate this to a more hygienic situation. RFC6066's Trusted CA indicator can be used by the new nodes that have newer trust anchor with more structure. Other solutions include using new names (via SNI), and/or new port numbers or IP addresses. Old systems with old server, new systems with new server. b. the client to server certificate is not mentioned in the above text. When transitioning between CAs, the client's highest trust anchor might not be a self-signed certificate. It could be a lower (subordinate) CA, but the client won't know this. So I think the client should always send the entire certificate chain that it has been given. An operator that knows that all the trust anchors are always terminal (lead to self-signed) could simply *omit* those from the chain that is provided to the client. It's not, however, obvious to me, how exactly to do this within EST: the client might still need to have the new trust anchor. c. There could also be rfc4210 section 4.4 root key update in progress. The new anchors might be evenly distributed yet. This is acute with device to device communication (where one device is arbitrarily the server)! This is why in (a) I want to insert the word "cloud" or non-constrained server. The mechanisms of RFC4210 assume certificates are in a directory that all clients can access. In isolated IoT networks, the new anchors would be retrieved periodically using EST /cacerts, or another protocol. The device needs to have the newWithOld (to transmit to devices without the new key), oldWithNew (to verify devices without a new key). It might not be apparent to devices which is which; it's just a bag of certificates. Maybe section 18 say more. When doing 4210 transitions, there are two potential trust anchors (old, and new), but there are certificates produced that allow mapping from old->new or new->old. The device without a renewed certificate and/or trust-anchor likely does not change. (It doesn't know it has to). Both old and new trust anchor likely have the same DN. So one can not distinguish between them from Issuer DN. If using Trusted CA Indication, one has: select (identifier_type) { case pre_agreed: struct {}; case key_sha1_hash: SHA1Hash; case x509_name: DistinguishedName; case cert_sha1_hash: SHA1Hash; so one can't use x509_name. (This document needs an update for SHA256, I don't think TLS1.3 updated that yet?). One can use key_sha1_hash, as it ought to match the AuthorizedKeyIdentifier, right? The simplest method, however, is for the device with the new trust anchor to simply send everything it has: newWithNew (the trust anchor!), and newWithOld. From the receivers point of view, both of these look like extraneous trust anchors at first if the receiver already has the new trust anchor. (It might need to use oldWithNew in order to validate the peers old certificate) My instinct is that nobody has implemented this. I'd be thrilled to be wrong. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
