Hi Hannes, Thanks for addressing the comments. Here are some short responses, clarifications and questions.
Yours, Daniel > The "Exported Authenticator" specification, see > [RFC9261], recently added support for mutual, post-handshake > authentication but requires the Certificate, CertificateVerify and > the Finished messages to be exchanged by the application layer > protocol, as it is exercised for HTTP/2 and HTTP/3 in > [I-D.ietf-httpbis-secondary-server-certs]. > MGLT: the text looks like application layer is involved, which sounds a > bit strange to rely on above-TLS layers to compleet TLS. > > [Hannes] This may indeed look surprising but that is what the TLS working > group came up with. > > MGLT: I think my comment was more how relying on HTTP HEADERS makes sense in IoT. Not knowing much of CoAP, I am wondering how this could be done in CoAP. The other point I am wondering is why not simply redo a key exchange from the beginning from time to time. I am under the impression that having the application to interact with TLS is very complex for a relatively small gain, but maybe I am missing something. > > > [Hannes] An implementation that supports PSK-based credentials still has > to support these three extensions. Supported Version is required by the TLS > 1.3 specification. Cookie is used for DDoS prevention and SNI is required > for virtual hosting environments, which are very common today. > > > MGLT: "supports PSK-based credentials still has to support these three extensions. " was not clear in the beginning, but you clarified it. I suspect SNI is for reaching the server in a cloud so likely depending on the use case. > > * Supported Versions, > * Cookie, > * Server Name Indication (SNI), > * Pre-Shared Key, > * PSK Key Exchange Modes, and > * Application-Layer Protocol Negotiation (ALPN). > > For use of external pre-shared keys [RFC9258] makes the following > recommendation: > > Applications SHOULD provision separate PSKs for (D)TLS 1.3 and > prior versions. > > Where possible, the importer interface defined in [RFC9258] MUST be > used for external PSKs. This ensures that external PSKs used in > (D)TLS 1.3 are bound to a specific key derivation function (KDF) and > hash function. > MGLT: I think there are always bound to KDF and hash. What we want is that > both hosts uses the same KDF and hash. Suppose that one PSK is used with a > hash function that has become unsecured, I am wondering if the > recommendation would be to keep on using it over an unsecured hash function > as opposed a newly known secured hash function. Though it might be as > secured as if we had always used the secured hash function, I am wondering > it might still be better to use it this way. > > [Hannes] The purpose of RFC 9258 is generate different PSKs for different > versions of TLS. This was the motivation for developing the RFC. Of course, > if you do not mix different versions of the TLS & DTLS protocol in your > deployment then this issue goes away. I think what you are saying is that > there are other ways to accomplish that goal but this is outside the scope > of this draft. > > MGLT: I think the case I raised was that if a device is configured with a PSK and a given KDF based on SHA2. Suppose we move to SHA3, I was wondering what are the recommendations regarding the PSK. > > > allow for the distribution and updating of > certificates on demand. This enables a deployment model where IoT > device utilize end entity certificates with shorter lifetime making > certificate revocation protocols, like OCSP and CRLs, less relevant. > Whenever certificates are updated the TLS stack needs to be informed > since the communication endpoints need to be aware of the new > certificates. This is particularly important when long-lived TLS > connections are used. In such a case, the post-handshake > authentication exchange is triggered when the application requires > it. TLS 1.3 provides client-to-server post-handshake authentication > only. Mutual authentication via post-handshake messages is available > by the use of the "Exported Authenticator" [RFC9261] but requires the > application layer protocol to carry the payloads. > MGLT: This seems horribly complex, it would be good to know whether this > is recommended or not to use such mechanism. I believe it really depends on > the trust model since there is not a mandatory need to re-authenticate > regularly once the session has been authenticated once. Authentication is > performed at a given time, there is no commitment it remains unchanged > during the entire TLS session. > I think the only reason we need to authenticate id when the key is rogue > and we have later realized the current TLS session has been authenticated > with that rogue key. In any other cases, it seems fine, security relies on > the TSL session key not the authentication. > I see authentication as the main source of consumption, so I would like to > understand the effective gain instead of doing a reconnection. > I am wondering why we do not simply request to reconnect every X period of > time to keep things light. > > Note that authenticators are mostly done to handle different identities > > > > [Hannes] If you want the functionality in your deployment then you have to > use this mechanism. > > The exported authenticator functionality is just what it is. > > > MGLT: I do see IoT with long time sessions. I am wondering if the motivation to recheck the identity is that the certificate is being revoked or expired. I think the text should explain that the certificate validity only happens at the setting of the session, and that it could be acceptable to continue exchanging with an expired certificate or revoked certificate. HOwever, I believe it would be good to RECOMMEND the session does not go beyond the validity period of the certificate. > > > > > MGLT: I would like a section on Subject SAN. > > [Hannes] What would you write? > MGLT: recommending using SAN and empty "subject" for end certificates. I realize this is mostly done later in the subject section. Maybe it looked strange to me that the field was missing. > > > MGLT: It is my believe that this section should come out with some > recommendations on how to name a IoT client / server. EUI-64 and FQDN are > listed, but I am wondering what about UUID or any other scheme. > > [Hannes] In the past we made the effort to talk about the different naming > schemes and it was a failure. So, we are not going there again. > MGLT: I do not see UUIDs as typed identifiers in the SAN, but I would be interested by any references on how to handle them for my own information. > >
_______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
