Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

From: Joseph Salowey <[email-masked]>
Date: Wed, 15 May 2019 06:20:48 -0700

The last call has come and gone without any comment.  Please indicate if
you have reviewed the draft even if you do not have issues to raise so the
chairs can see who has reviewed it.  Also indicate if you have any plans to
implement the draft.

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey <[email-masked]> wrote:

> This is the working group last call for the "TLS 1.3 Extension for
> Certificate-based Authentication with an External Pre-Shared Key” draft
> available at
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/.
> Please review the document and send your comments to the list by 2359 UTC
> on 23 April 2019.
>
> Thanks,
> Chris, Joe, and Sean
>

---

From: Peter Yee <[email-masked]>
Date: Wed, 15 May 2019 06:55:49 -0700

Joe,

                I reviewed the draft and sent comments directly to Russ in the form of a marked up Word document (which is why I didn’t previously post my input to the list).  I’ve no problems with the document advancing based on Russ’ -01 update.

                                -Peter

On 5/15/19, 6:20 AM, "TLS on behalf of Joseph Salowey" <[email-masked] on behalf of [email-masked]> wrote:

The last call has come and gone without any comment.  Please indicate if you have reviewed the draft even if you do not have issues to raise so the chairs can see who has reviewed it.  Also indicate if you have any plans to implement the draft. 

This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.

Thanks,
Chris, Joe, and Sean

_______________________________________________ TLS mailing list [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 15 May 2019 11:31:05 -0400

> chairs can see who has reviewed it.  Also indicate if you have any 

I have read the draft and it seems fine. It follows the same methodology 
used in draft-ietf-ipsecme-qr-ikev2, which was heavily reviewed in the 
IPsecME Working Group. I cannot speak to whether this draft uses the 
right incantations for a TLS extension, but the rationale and design are 
straightforward. Assuming that someone who understands TLS extensions is 
comfortable with Sections 4 and 5, it should be moved to IETF Last Call.

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 May 2019 15:20:16 -0400

TLS 1.3 Extension for Certificate-based Authentication with an External PSK ensures the US Government has a quantum-resistant option for TLS in the interim years until post-quantum algorithms emerge from the NIST process. For this reason, there is an intent to specify this extension in future procurements.

Russ

> On May 15, 2019, at 9:20 AM, Joseph Salowey <[email-masked]> wrote:
> 
> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
> This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ <https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/>. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.
> 
> Thanks,
> Chris, Joe, and Sean

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 20 May 2019 19:41:24 +0000

I reviewed this draft (“browsed through” would be a more honest statement). I didn’t spot an obvious problem with it.

One question that I have after reading it: I understand why one wants to implement this extension, but I don’t see how the two endpoints would arrive at that external PSK.

From: TLS <[email-masked]> on behalf of Russ Housley <[email-masked]>
Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey <[email-masked]>
Cc: IETF TLS <[email-masked]>
Subject: Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

Russ

On May 15, 2019, at 9:20 AM, Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
This is the working group last call for the "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key” draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/. Please review the document and send your comments to the list by 2359 UTC on 23 April 2019.

Thanks,
Chris, Joe, and Sean

---

From: Michael StJohns <[email-masked]>
Date: Mon, 20 May 2019 16:57:56 -0400

On 5/20/2019 3:41 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> I reviewed this draft (“browsed through” would be a more honest 
> statement). I didn’t spot an obvious problem with it.
>
> One question that I have after reading it: I understand why one wants 
> to implement this extension, but I don’t see how the two endpoints 
> would arrive at that external PSK.
>
Sadly - we're back to the 1980's in terms of key management. The obvious 
answers are a) they meet to exchange keys, b) they're given a key 
through a KDC, c) they get them in the mail. (and I'm really not kidding 
about (c))

Mike

> *From: *TLS <[email-masked]> on behalf of Russ Housley 
> <[email-masked]>
> *Date: *Monday, May 20, 2019 at 3:21 PM
> *To: *Joe Salowey <[email-masked]>
> *Cc: *IETF TLS <[email-masked]>
> *Subject: *Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk
>
> TLS 1.3 Extension for Certificate-based Authentication with an 
> External PSK ensures the US Government has a quantum-resistant option 
> for TLS in the interim years until post-quantum algorithms emerge from 
> the NIST process. For this reason, there is an intent to specify this 
> extension in future procurements.
>
> Russ
>
>
>
>     The last call has come and gone without any comment.  Please
>     indicate if you have reviewed the draft even if you do not have
>     issues to raise so the chairs can see who has reviewed it.  Also
>     indicate if you have any plans to implement the draft.
>
>         This is the working group last call for the "TLS 1.3 Extension
>         for Certificate-based Authentication with an External
>         Pre-Shared Key” draft available at
>         Please review the document and send your comments to the list
>         by 2359 UTC on 23 April 2019.
>
>         Thanks,
>         Chris, Joe, and Sean
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 20 May 2019 21:11:49 +0000

Sadly - we're back to the 1980's in terms of key management.   The obvious answers are a) they meet to exchange keys, b) they're given a key through a KDC, c) they get them in the mail. (and I'm really not kidding about (c))

I don’t think I get it. There’s a ton of submissions at NIST PQC, most came with some formal proofs. I can’t believe none of them is good enough. Anything from that pool should be better than nothing…?

Also, if you do have a running KDC, why would you want/need TLS 1.3 ECDHE in addition to it? 

Would such a pre-shared key be long-term (i.e., good/used for many connections), or is it going to be a use-once thing?

Russ

Thanks,
Chris, Joe, and Sean

---

From: Geoffrey Keating <[email-masked]>
Date: 20 May 2019 17:25:57 -0700

> chairs can see who has reviewed it.  Also indicate if you have any plans to

I looked at the draft.

My understanding of the draft (and I think it would have helped if it
contained a diagram showing the resulting TLS handshake) is that it's
specifying the existing psk_dhe_ke flow, to which it adds a
certificate-based signature over the handshake, which it doesn't
specify but works the same way as in RFC 8446 when there is no PSK.

This is somewhat confusing because the draft is written as if it
starts with a certificate-based TLS flow and somehow adds a PSK; it
repeats all the RFC 8446 PSK machinery, but doesn't explain how the
certificate interacts with it, and raises questions like "are there
two DH operations or just one?".  I think the draft could have been a
lot shorter.

Conversely, one area where the draft could have been longer would be to
explain how exactly this produces quantum-resistance in the presence
of a secret shared key.  It appears that it relies on the HKDF-Expand
function being quantum-resistant.  That seems like an important thing
to document, given that we don't have fully functional quantum
cryptanalysis yet and so don't know exactly what might be
quantum-resistant or not.

However, once you're past that, the resulting protocol seems quite
simple (as an addition to psk_dhe_ke) and I have no objections to it.

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 May 2019 09:37:28 -0400

Uri:

Out-of-band distribution is used.  This draft makes no attempt at picking one of the many ways to do that.

Russ

> On May 20, 2019, at 3:41 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 
> From: TLS <[email-masked] <mailto:[email-masked]>> on behalf of Russ Housley <[email-masked] <mailto:[email-masked]>>
> To: Joe Salowey <[email-masked] <mailto:[email-masked]>>
> Cc: IETF TLS <[email-masked] <mailto:[email-masked]>>
>> On May 15, 2019, at 9:20 AM, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
>>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 May 2019 09:39:31 -0400

Uri:

As my note said, "... until post-quantum algorithms emerge from the NIST process."

Russ

> On May 20, 2019, at 5:11 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 
>> From: TLS <[email-masked]> <mailto:[email-masked]> on behalf of Russ Housley <[email-masked]> <mailto:[email-masked]>
>> To: Joe Salowey <[email-masked]> <mailto:[email-masked]>
>> Cc: IETF TLS <[email-masked]> <mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 May 2019 09:54:13 -0400

> specify but works the same way as in RFC 8446 when there is no PSK.

I am pleased to add text that will make it more clear, but you are the first one to ask.

Please see slides 5 and 6 of the presentation at IETF 104:
https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls13-cert-with-extern-psk-00

> two DH operations or just one?".  I think the draft could have been a

One (EC)DH exchange.

I agree that there is a fair amount of context in the draft.  That was an attempt to avoid the confusion that you claim in the previous paragraph.

> quantum-resistant or not.

Hash functions are quantum-resistant.  Shor's algorithm means that you might want to use one that 2x longer than previously chosen.  The same is true for symmetric encryption algorithm keys.

I can add a paragraph to the security considerations that HKDF and the underlying hash function are assumed to be quantum-resistant.

> simple (as an addition to psk_dhe_ke) and I have no objections to it.

Thanks.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 May 2019 14:11:21 +0000

*   I don’t think I get it. There’s a ton of submissions at NIST PQC, most came with some formal proofs. I can’t believe none of them is good enough. Anything from that pool should be better than nothing…?

We want to wait until NIST decides and not jump the gun.

  *   Also, if you do have a running KDC, why would you want/need TLS 1.3 ECDHE in addition to it?

I believe this is KDC as a generic term, not Kerberos.  Many enterprises have a way to distribute keys to entities.

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 May 2019 15:46:07 -0400

> On May 20, 2019, at 8:25 PM, Geoffrey Keating <[email-masked]> wrote:
> 

I think that the necessary property is that HKDF reman a PRF.

I suggest the following additions to the Security Considerations:

  If the external PSK is known to any party other than the client and
  the server, then the external PSK MUST NOT be the sole basis for
  authentication.  The reasoning is explained in [K2016] (see
  Section 4.2).  When this extension is used, authentication is based
  on certificates, not the external PSK.

  In this extension, the external PSK regains the forward secrecy if the
  (EC)DH key agreement is ever broken by cryptanalysis or the future
  invention of a large-scale quantum computer.  As long as the attacker
  does not know the PSK and the key derivation algorithm remains
  unbroken, the attacker cannot derive the session secrets even if they
  are able to compute the (EC)DH shared secret.

  TLS 1.3 key derivation makes use of the HKDF algorithm, which depends
  upon the HMAC construction and a hash function.  This extension
  provides the desired protection for the session secrets as long as
  HMAC with the selected hash function is a pseudorandom function (PRF)
  [GGM1986].

  [GGM1986]  Goldreich, O., Goldwasser, S., and S. Micali, "How to
             construct random functions", J. ACM 1986 (33), pp.
             792-807, 1986.

  [K2016]    Krawczyk, H., "A Unilateral-to-Mutual Authentication
             Compiler for Key Exchange (with Applications to Client
             Authentication in TLS 1.3)", IACR ePrint 2016/711, August
             2016.

Russ

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 21 May 2019 17:08:37 -0400

A clarification on the text suggest below by Russ.

The way I see it, the external PSK as used in
draft-ietf-tls-tls13-cert-with-extern-psk is not intended as a means of
authentication but as a way of regaining forward secrecy in case the
(EC)DHE mechanism is ever broken (e.g., by cryptanalysis or by a quantum
computer). Indeed, as long as the future attacker does not learn the PSK
and the key derivation remains unbroken (e.g., HMAC is still a secure PRF
(*)), that attacker cannot derive the session secrets even if it can
compute the (EC)DHE value. When looking at the mechanism in this way,
questions like whether this is a PSK-with-ECDHE mechanism with added
signatures or a regular 1.5 RTT with added PSK authentication are easily
answered. It is a regular 1.5 RTT where a PSK has been added to the key
derivation for the sake of quantum-resistant forward secrecy. In this case,
one should see authentication as fully relying on certificate-based
signatures. So, even if parties other than the communicating client and
server know the PSK, this endangers the secrecy of PSK and its forward
security effect, but not the authenticity of the handshake.

The above is my interpretation of the draft based on a superficial reading.
I have not studied it carefully enough to validate the design or understand
the full implication to TLS 1.3. Yet, it seems that the above conceptual
approach may help understanding the goal of the draft and analyzing its
security.

(*) The design of HKDF has as an explicit goal to support the case of
secret salt in HKDF-Extract in which case the security of HKDF relies
solely on HMAC being a secure PRF (which is the most studied aspect of
HMAC). Using the PSK as input to the KDF achieves this property.

Hugo

---

From: Christian Huitema <[email-masked]>
Date: Wed, 22 May 2019 10:22:45 -0700

Weird. I sent this message this morning, and it did not arrive on the list.

On 5/22/2019 1:09 AM, Christian Huitema wrote:
> On 5/15/2019 6:20 AM, Joseph Salowey wrote:
>> The last call has come and gone without any comment.  Please indicate
>> if you have reviewed the draft even if you do not have issues to
>> raise so the chairs can see who has reviewed it.  Also indicate if
>> you have any plans to implement the draft. 
>>
>>     for Certificate-based Authentication with an External Pre-Shared
>>     Key” draft available
>>     at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/.
>>     Please review the document and send your comments to the list by
>>     2359 UTC on 23 April 2019.
>>
>
> My only comment regards the trade-off in this draft between privacy
> and resilience. The proposed method uses PSK to provide greater
> resilience against quantum-capable attackers, and as Russ says this is
> something that the US government cares about. But at the same time,
> the use of PSK requires inserting a PSK-ID in the client hello, which
> is sent in clear text. So we have a trade-off: government
> communications are less likely to be decrypted, but the PSK-ID will
> help track government employees. It might make sense to describe the
> trade-off explicitly in the draft, maybe in the security section.
>
> -- Christian Huitema
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 May 2019 14:06:01 -0400

Christian:

> My only comment regards the trade-off in this draft between privacy and resilience. The proposed method uses PSK to provide greater resilience against quantum-capable attackers, and as Russ says this is something that the US government cares about. But at the same time, the use of PSK requires inserting a PSK-ID in the client hello, which is sent in clear text. So we have a trade-off: government communications are less likely to be decrypted, but the PSK-ID will help track government employees. It might make sense to describe the trade-off explicitly in the draft, maybe in the security section.
> 

I suggest the following additional section for this document:

  Privacy Considerations

   Appendix E.6 of [RFC8446] discusses identity exposure attacks on
   PSKs.  The guidance in this section remains relevant.

   This extension makes use of external PSKs to improve resilience
   against attackers that gain access to a large-scale quantum computer
   in the future.  This extension is always accompanied by the
   "pre_shared_key" extension to provide the PSK identities in plaintext
   in the ClientHello message.  Passive observation of the these PSK
   identities will aid an attacker to track users of this extension.

Does that address your comment?

Russ

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 May 2019 13:56:12 -0700

On 5/22/2019 11:06 AM, Russ Housley wrote:
>> resilience against quantum-capable attackers, and as Russ says this
>> is something that the US government cares about. But at the same
>> time, the use of PSK requires inserting a PSK-ID in the client hello,
>> which is sent in clear text. So we have a trade-off: government

Yes, although "passive observation will help" is somewhat more benign
than what I would have written. If the "government employee" is some
agent in a foreign country, they may want to think twice before using
the proposed option. Or alternatively, you may want a solution in which
the PSK-ID is randomized using some ESNI-like process.

-- Christian Huitema

---

From: Geoff Keating <[email-masked]>
Date: Fri, 31 May 2019 14:31:44 -0700

> On 21 May 2019, at 2:08 pm, Hugo Krawczyk <[email-masked]> wrote:
> 
> The way I see it, the external PSK as used in draft-ietf-tls-tls13-cert-with-extern-psk is not intended as a means of authentication but as a way of regaining forward secrecy in case the (EC)DHE mechanism is ever broken (e.g., by cryptanalysis or by a quantum computer).

It’s a bit problematic if the expected use of the draft is with quantum-resistant certificates, because TLS doesn’t support those yet.

If that’s the intent, shouldn’t the draft say something like "The server MUST choose a quantum-resistant algorithm when considering those listed in signature_algorithms_cert and/or signature_algorithms.  The client MUST supply at least one quantum-resistant algorithm in signature_algorithms, and in signature_algorithms_cert if present.”  ?  But that makes it unimplementable until such an algorithm is specified...

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 31 May 2019 21:59:00 +0000

On 5/31/2019, 17:34, "TLS on behalf of Geoff Keating" <[email-masked] on behalf of [email-masked]> wrote:
    >> The way I see it, the external PSK as used in draft-ietf-tls-tls13-cert-with-extern-psk is not intended as
    >> a means of authentication but as a way of regaining forward secrecy in case the (EC)DHE mechanism
    >>  is ever broken (e.g., by cryptanalysis or by a quantum computer).
    >
    >  It’s a bit problematic if the expected use of the draft is with quantum-resistant
    >  certificates...

This is not the intent/expected use. 
   
The intent is to protect the content of the session against being recorded now and decrypted later.

In short, no problem.

---

From: Russ Housley <[email-masked]>
Date: Fri, 31 May 2019 18:11:08 -0400

> On May 31, 2019, at 5:31 PM, Geoff Keating <[email-masked]> wrote:
> 
> 
> 

That is not the way I read Hugo's note, and that is certainly not called for by this draft.  Quite the opposite.

Russ