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

[Russ Housley <[e-mail]>]

> On Jul 27, 2018, at 5:23 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> 
> 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).

The bits and pieces for using and external PSK with certificates are also already present.  That is why the extension is defines as:

      struct {
          select (Handshake.msg_type) {
              case client_hello: Empty;
              case server_hello: Empty;
          };
      } CertWithExternPSK;

See https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-certificate-based-authentication-with-external-psk-00;
Slide 5 shows that other extensions are used, and slide 6 shows the above syntax.

Russ