On Mon, Mar 23, 2026 at 8:19 AM John Mattsson <[email protected]> wrote:
> >The primary reason that psk_ke is unwise for external keys is that we > expect those keys to have a long lifespan. > > I disagree, the primary reason that psk_ke is unwise for external keys is > that you should not trust that the provider of the external PSK is honest > or not compromised. This includes your own systems. The main principle of > zero trust is that you should always assume breach and limit the impact of > breach. > I think "external" is doing a lot of work here. In at least one of the architectures proposed by the LS, the QKD system is in the same device as the TLS implementation. I don't think there is a meaningful difference between this structure and having a normal asymmetric key exchange inside your TLS stack. As an aside, I would note that it's possible to design a system where you have an asymmetric key establishment system that then hands the traffic keys off to some distinct node for processing. This is less natural in TLS implementations (though it's not particularly uncommon to have the TLS handshake hand off traffic keys to some hardware acceleration system) because TLS is integrated, but this is effectively the structure of IPsec, which has distinct key establishment and transport protocols. In any case, this architectural question seems outside the scope of the TLS WG, and I don't think we should weigh in on it. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
