certificate revocation checks in long lasting connections

[thomas-fossati]

Now that renegotiation is gone, what recommendation can we make to deal with semi-permanent, mutually authenticated connections that need to rekey and check the associated certificate credentials?
This is a common use case in Industrial IoT.

See this long thread on the TLS mailing list: https://mailarchive.ietf.org/arch/msg/tls/vTxwj2iShME6c7AHg_Ub-_eS_fM/

[thomas-fossati]

This excerpt from Magnus' TSV-ART review of RFC7525bis is also relevant:

I think the main reason for staying on 1.2 is if you need other
features not available in TLS 1.3 like mutual re-authentication. So maybe this
rational should be updated to indicate more like why 1.2 may be preferred over
1.3 than why it is preferred over the earlier version which shall not be used.

Based on our work on DTLS/SCTP
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/ really
the issue we found with using (D)TLS 1.3 have been related to long lived
sessions and how TLS 1.3 keyUpdate works. I think three aspects we found in the
DTLS/SCTP work is relevant here for consideration and do affect applications in
their choice.

• Periodic re-authentication and transfer of revocation information of both
endpoints (not only the DTLS client).

• Periodic rerunning of Diffie-Hellman key-exchange to provide forward secrecy
and mitigate static key exfiltration attacks.

• When using keyUpdate the master secret isn't impacted, which results in
applications using TLS exporter to derive key material are not getting new keys
if re-envoking the exporter after a keyUpdate. Thus, application protocols
using the TLS exporter needs to take this into account to include epoch
counters or similar in the key-derivation process and it will not result in
forward secrecy. I would note that QUIC v1 uses its own key update mechanism as
defined in Section 6 of RFC 9001 that I think illustrates this.

For DTLS/SCTP we did go with a more complex method based on creating new DTLS
connections and dealing with handling of two connections in parallel due to
SCTPs capability for parallel transmission of data. That also avoided use to
have to rely solely on DTLS 1.2 to handle these issues and we can use DTLS 1.3
and likely any future DTLS version too.

[martinthomson]

To repeat a suggestion that I made at the mic ini Philadelphia: it might be sufficient - at least for verifying liveness of certification information - to use an exported authenticator.

[thomas-fossati]

Martin, thanks for the (good) suggestion.

[OR13]

I'm not super clear on what the action is for this issue.

Is it to add a reference to 9261 and expand on considerations for long lived static keys?

[hannestschofenig]

The text is available now but the only problem is that there is no specification in standardized IoT protocols to carry the payloads.