On Mon, 2018-04-23 at 15:30 -0400, Russ Housley wrote: > > > > In the presentation the main driver for it seems to be quantum > > computer > > resistance as temporary measure. If that's the main argument I > > don't > > think it is really significant. PSK can hardly be used with PKI, > > and as > > a matter of fact we use PKI because of PSK key distribution > > problems. > > If we switch to PSK for quantum computer resistance there is there > > a > > reason to use PKI? Probably no (I may be wrong here, if there is a > > reason for a hubrid model I'm missing, I'd be glad to know). > > I am not advocating for a pairwise PSK between every client and > server. If that were available to us, then as you say, we would > always use the PSK without any PKI. > > I envision a PSK being distributed to a group of clients and group of > severs. At some point in the future a large-scale quantum computer > might get invented, and if any member of the group has access to it, > then they can recover the traffic. However, parties outside the > group cannot recover the traffic because the large-scale quantum > computer does not assist with the discovery of the PSK.
[going back to this thread, as I have missed that reply and only saw it after the request for adoption was made] It certainly makes sense. > > I could see the main driver for such proposal the replacement of > > the > > RSA-PSK ciphersuites. I know they have _some_ adoption, but I'm not > > sure whether that is significant to require update to TLS1.3. > > This is not my goal. > > > On the implementation side, why not use post-handshake > > authentication > > here? I.e., extend it to be usable from client-side, and on a PSK > > key > > exchange, have the client request server authentication after the > > handshake? > > I'm not sure why that is easier to implement. Can you say more? Current TLS1.3 implementations can do a PSK key exchange and authenticate the client's certificate with post-handshake auth. Based on that, what you'd need to make that authentication two-way (both server and client use cert) is the ability for client to ask the server for certificate. As PHA is fairly simple (server sends a certificate request to client if the PHA extension is seen), doing the opposite if another extension is seen, seems trivial (the bits and pieces are already there). regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
