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

[Joseph Salowey]

Thanks to everyone that replied to this last call.  In summary, there is
support to move the draft forward with the minor editorial changes
discussed on the list.  We’ll start the process of moving this along to the
IESG for publication.

Thanks,

Joe, Sean, and Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

> On May 31, 2019, at 5:31 PM, Geoff Keating  wrote:
> 
> 
> 
>> On 21 May 2019, at 2:08 pm, Hugo Krawczyk  wrote:
>> 
>> 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).
> 
> It’s a bit problematic if the expected use of the draft is with 
> quantum-resistant certificates, because TLS doesn’t support those yet.

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

Russ

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

On 5/31/2019, 17:34, "TLS on behalf of Geoff Keating"  wrote:
>> On 21 May 2019, at 2:08 pm, Hugo Krawczyk  wrote:
>> 
>> 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).
>
>  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.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Geoff Keating]

> On 21 May 2019, at 2:08 pm, Hugo Krawczyk  wrote:
> 
> 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).

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...
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

On 5/22/2019 11:06 AM, Russ Housley wrote:
>
> Christian:
>
>> 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. 
>>>
>>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey >> > 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.
>>>
>> 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?

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

Christian:

> 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. 
>> 
>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > > 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.
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

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. 
>>
>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > > 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.
>>
>
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hugo Krawczyk]

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

On Tue, May 21, 2019 at 3:46 PM Russ Housley  wrote:

>
>
> > On May 20, 2019, at 8:25 PM, Geoffrey Keating  wrote:
> >
> > Joseph Salowey  writes:
> >
> >> 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.
> >
> > 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.
>
> 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 

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

[Russ Housley]

> On May 20, 2019, at 8:25 PM, Geoffrey Keating  wrote:
> 
> Joseph Salowey  writes:
> 
>> 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.
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

  *   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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

Geoffrey:
> 
> 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.
> 
> 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.

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

> 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.

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.

> 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.

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.

> 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.

Thanks.

Russ

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

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  
> wrote:
> 
> 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))
> 
> 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?
>  
>>  
>> From: TLS  <mailto:tls-boun...@ietf.org> on behalf of 
>> Russ Housley  <mailto:hous...@vigilsec.com>
>> Date: Monday, May 20, 2019 at 3:21 PM
>> To: Joe Salowey  <mailto:j...@salowey.net>
>> Cc: IETF TLS  <mailto:tls@ietf.org>
>> 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
>>  
>> 
>> 
>> 
>>> On May 15, 2019, at 9:20 AM, Joseph Salowey >> <mailto:j...@salowey.net>> 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. 
>>>  
>>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey >> <mailto:j...@salowey.net>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <https://www.ietf.org/mailman/listinfo/tls> 
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

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  
> 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.
>  
> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
> Russ Housley mailto:hous...@vigilsec.com>>
> Date: Monday, May 20, 2019 at 3:21 PM
> To: Joe Salowey mailto:j...@salowey.net>>
> Cc: IETF TLS mailto:tls@ietf.org>>
> 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
>  
> 
> 
>> On May 15, 2019, at 9:20 AM, Joseph Salowey > <mailto:j...@salowey.net>> 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. 
>>  
>> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey > <mailto:j...@salowey.net>> 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
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Geoffrey Keating]

Joseph Salowey  writes:

> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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))

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?

 

 

From: TLS  on behalf of Russ Housley 

Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey 
Cc: IETF TLS 
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

 




On May 15, 2019, at 9: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. 

 

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey  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







___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Michael StJohns]

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  on behalf of Russ Housley 


*Date: *Monday, May 20, 2019 at 3:21 PM
*To: *Joe Salowey 
*Cc: *IETF TLS 
*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



On May 15, 2019, at 9:20 AM, Joseph Salowey mailto:j...@salowey.net>> 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.

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey mailto:j...@salowey.net>> 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




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Blumenthal, Uri - 0553 - MITLL]

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  on behalf of Russ Housley 

Date: Monday, May 20, 2019 at 3:21 PM
To: Joe Salowey 
Cc: IETF TLS 
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



On May 15, 2019, at 9:20 AM, Joseph Salowey 
mailto:j...@salowey.net>> 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.

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey 
mailto:j...@salowey.net>> 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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

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  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. 
> 
> On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey  > 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paul Hoffman]

On 15 May 2019, at 9:20, 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.


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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Yee]

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"  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. 

 

On Tue, Apr 9, 2019 at 8:51 PM Joseph Salowey  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

___ TLS mailing list TLS@ietf.org 
https://www.ietf.org/mailman/listinfo/tls 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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  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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls