Please note and respect the Reply-To: u...@ietf.org.
TL;DR> Help us avoid stuffing non-DNS strings into SubjectAltName dNSName
when doing device to device (D)TLS.In https://github.com/thomas-fossati/draft-tls13-iot/issues/65 I ask why draft-ietf-uta-tls13-iot-profile suggests that IoT devices that have certificates (probably IDevID) whose primary identity is an EUI64 are using dNSName with a fabricated ascii representation of hex EUI64. (An EUI64 identity is often common on 802.15.4 networks, which use 8-byte EUIs) now at: https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-11.html#name-subject-3 we say: > When the server identity is given by an EUI-64 format, then it MUST be > encoded in a subjectAltName of type DNS-ID {{RFC9525, Section 1.5}}, as a > string of the form `HH-HH-HH-HH-HH-HH-HH-HH` where 'H' is one of the > symbols '0'-'9' or 'A'-'F'. and some of this goes back to RFC7925. Section 4.4.1 says: Note that there will be servers that are not provisioned for use with DNS domain names, for example, IoT devices that offer resources to nearby devices in a local area network, as shown in Figure 7. When such constrained servers are used, then the use of certificates as described in Section 4.4.2 is applicable. Note that the SNI extension cannot be used in this case since SNI does not offer the ability to convey a 64-bit Extended Unique Identifier (EUI-64) [EUI64]. Note that this document does not recommend use of IP addresses in certificates nor does it discuss the implications of placing IP addresses in certificates. and also: 4.4.2. Certificates Used by Clients For **client certificates**, the identifier used in the SubjectAltName or in the leftmost CN component of subject name MUST be an EUI-64. (I find the above very unclear btw. So at least the text from the update is better) ---- Note: DNS-ID is not a SAN, but rather through indirection through RFC9525 section 1.5: DNS-ID: A subjectAltName entry of type dNSName as defined in [PKIX]. I really don't want to encode new sillyness into dNSName!!! We really *ought* to be using otherName. Some years ago I wrote code that did that, using a PEN OID in otherName with mbedtls. {I suspect that any savings from encoding the 8-byte EUI64 in binary (vs 16+7 ascii bytes) is probably lost due to the OID needed in the otherName. But I didn't count yet} I think that otherName:<OID-to-be-allocated> ought to be fine for all uses where a certificate is used for client-side TLS authentication to a "cloud" service. Such a service will be referenced by (DNS) name, and so an SNI belongs. Where we get into trouble is when we want to do device to device communication such as with COAPS (CoAP over DTLS). If there has not been an onboarding process that has deployed an LDevID, then we miight wind up using that same IDevID certificate. This all assumes: 1) the IoT device is acting as a (D)TLS endpoint. {such as CoAPS!} 2) the IoT device is using EUI-64 as it's identity (vs having an LDevID assigned) 3) there are more than one (D)TLS endpoint on the device, making an accurate SNI important while for class 2 or lower devices, the odds of the device having more than one valid TLS endpoint is low, for class 4,10,15[RPI] devices, it seems entirely reasonable that there could be multiple end-points distinguished by SNI. options that I see are: 1. hold my nose (and yours) and standardize this. 2. declare multiple end-points requiring SNI to be out-of-scope, and so (D)TLS servers on such devices should ignore SNI, and clients shouldn't bother putting in anything that isn't a real name. (It could well be "printer.local"!) 3. declare that multiple end-points would require an onboarding process (BRSKI, Matter, OPC-UA, EAP-TEAP-BRSKI, ...) to replace any IDevID with otherName:EUI64 identity with a proper name that would fit into SNI. 4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI. There isn't an IANA registry for this. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
