Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk

[Nikos Mavrogiannopoulos <[e-mail]>]

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