Subject: [TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2018 16:37:57 -0500

I would like to get comments on this Internet-Draft.  Once a round of comments have been received and folded into -01, I would like to work with folks that did the earlier proofs with Tamarin to make sure that the this does not negatively impact the TLS 1.3 protocol changes that were made to eliminate the man-in-the-middle attack that they found in 2015.

Thanks,
  Russ

> From: [email-masked]
> Subject: New Version Notification for draft-housley-tls-tls13-cert-with-extern-psk-00.txt
> Date: March 1, 2018 at 4:13:44 PM EST
> To: "Russ Housley" <[email-masked]>
> 
> 
> A new version of I-D, draft-housley-tls-tls13-cert-with-extern-psk-00.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
> 
> Name:		draft-housley-tls-tls13-cert-with-extern-psk
> Revision:	00
> Title:		TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key
> Document date:	2018-03-01
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-housley-tls-tls13-cert-with-extern-psk-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-housley-tls-tls13-cert-with-extern-psk/
> Htmlized:       https://tools.ietf.org/html/draft-housley-tls-tls13-cert-with-extern-psk-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-tls-tls13-cert-with-extern-psk-00
> 
> 
> Abstract:
>   This document specifies a TLS 1.3 extension that allows a server to
>   authenticate with a combination of a certificate and an external pre-
>   shared key (PSK).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Mar 2018 08:54:40 +1100

Hi Russ,

This seems like a welcome addition.  I'm not sure why you think that
PQ needs are a good motivation for this work though.  Managing
external PSKs is so unwieldy that it almost seems like this would do
more harm than good in that regard.  I find this more interesting from
the perspective of providing continuing proof of possession for keys
while also permitting the use of 0-RTT (and session continuation more
generally).

FWIW, I don't see any reason that this approach would be a problem
given that it is additive, the problem that Sam Scott et. al. from
before was a result of important contextual information being omitted
from the transcript.

Why didn't you consider a new codepoint on psk_key_exchange_modes that
permits/requires use of the certificate?  The purpose of that
extension is to signal that a) you want PSK, and b) what additional
things are permitted alongside that PSK.

It's not clear from your text on client certificate authentication
whether your mode permits the server to omit its Certificate, but then
send CertificateRequest.  You should clarify that one way or other.

--Martin

On Fri, Mar 2, 2018 at 8:37 AM, Russ Housley <[email-masked]> wrote:
> I would like to get comments on this Internet-Draft.  Once a round of
> comments have been received and folded into -01, I would like to work with
> folks that did the earlier proofs with Tamarin to make sure that the this
> does not negatively impact the TLS 1.3 protocol changes that were made to
> eliminate the man-in-the-middle attack that they found in 2015.
>
> Thanks,
>   Russ
>
>
> Subject: New Version Notification for
> draft-housley-tls-tls13-cert-with-extern-psk-00.txt
> URL:
> https://www.ietf.org/internet-drafts/draft-housley-tls-tls13-cert-with-extern-psk-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-housley-tls-tls13-cert-with-extern-psk/
> Htmlized:
> https://tools.ietf.org/html/draft-housley-tls-tls13-cert-with-extern-psk-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-housley-tls-tls13-cert-with-extern-psk-00
>
>
> Abstract:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 1 Mar 2018 17:14:45 -0500

> while also permitting the use of 0-RTT (and session continuation more

The key management would be pretty onerous if a different external PSK is distributed to each client-server pair.  I was pretty careful to make sure that the key schedule would work out even if the external PSK is know to a group of clients and a group of servers because the (EC)DHE key will be pairwise.

If the external PSK is not pairwise, I do not think it can be used for 0-RTT traffic, which is why the I-D does not allow early data.

> before was a result of important contextual information being omitted

I did not see a problem, but we should make sure that there is not something subtle.

> things are permitted alongside that PSK.

Because of this text in the TLS 1.3 base specification:

   ... Implementations MUST NOT
   combine external PSKs with certificate-based authentication of either
   the client or the server unless negotiated by some extension.

That steered me toward an additional extension.

> send CertificateRequest.  You should clarify that one way or other.

That was intended by:

   When the "tls_cert_with_extern_psk" extension is successfully
   negotiated, authentication of the server depends upon the ability to
   generate a signature that can be validated with the public key in the
   server's certificate.  This is accomplished by the server sending the
   Certificate and CertificateVerify messages as described in Sections
   4.4.2 and 4.4.3 of [I-D.ietf-tls-tls13].

But I see that it should be reworded to include a MUST statement.

Russ

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 16:35:53 +1100

Hi Russ,

I just saw this in the draft:

   Thus, a certificate MUST NOT be used with a resumption PSK.

I think that this is grounded on an invalid basis:

   However, TLS
   1.3 does not permit an external PSK to be used in the same fashion as
   a resumption PSK, and this extension does not alter those
   restrictions.

TLS 1.3 is pretty clear that the difference derives primarily from the
provenance of a resumption PSK providing additional contextual
information:

"When PSKs are provisioned out of band, the PSK identity and the KDF
hash algorithm to be used with the PSK MUST also be provisioned."

In fact, the section on early_data establishes more requirements for 0-RTT:

"The parameters for the 0-RTT data (version, symmetric cipher suite,
ALPN protocol, etc.) are those associated with the PSK in use. For
externally established PSKs, the associated values are those
provisioned along with the key. For PSKs established via a
NewSessionTicket message, the associated values are those which were
negotiated in the connection which established the PSK."

So I would conclude that the two are in fact able to be used in the
same way, even if the two are forcibly distinguished in the key
schedule through the use of different labels.

> If the external PSK is not pairwise, I do not think it can be used for 0-RTT traffic, which is why the I-D does not allow early data.

That's a consequence of a choice not to make the key exclusive
pairwise, not the protocol you describe.  If the key meets the usage
requirements for 0-RTT, then why prohibit use with 0-RTT?

To uplevel a little, if the concern is that the server can be
impersonated due to weaknesses in the certificate authentication, you
just created a situation where all the entities with the PSK are now a
threat to session integrity. That seems like a poor outcome.

> That steered me toward an additional extension.

That's unfortunate, but I can see how that works.