Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Ilari Liusvaara]

On Fri, Mar 24, 2017 at 12:16:48PM -0400, Russ Housley wrote:
> 
> > I agree with David here. Specifically, I think.
> > 
> > - The base specification should continue to forbid certificates in 
> > combination with PSK
> > - We should at some point contemplate an extension that allows the use of 
> > certificates in combination with PSK
> > - The base spec should be factored in such a way as to make that extension 
> > easy.
> 
> While I agree that we do not want to delay the TLS 1.3 specification
> to sort this out; however, I do not think we have provided the hook
> to make this future extension easy.   Looking at the key schedule in
> -19, I think we can provide the hook without being disruptive.  My
> goal is to minimize the pain to implementing the extension in the
> future by putting a straightforward hook in today:

Unless you have fairly good idea about how such extension would look
(especially security properties!), I think it is premature to specify
where the key will go (if it doesn't go there, you got problems).

At least from what I know about my implementation, adding new keys
to be injected in present spots is easy (after one has computed
the value, it is one method call to inject it). Actually changing
what keys are derived from each stage or creating new stages is of
course expensive.

Currently, there are three stages in key schedule.
- 0-RTT (Binders, 0-RTT keys and 0-RTT exporters).
- Handshake (handshake keys, finished)
- Application (application keys, exporters and dynamic PSKs).


In comparision, new handshake message would be far more expensive
code-wise, even if I could piggyback main handshake states like with
CertificateRequest. And something that actually changes the main
state machine would be far more expensive still.


And extension specs are only really bound by TLS offer-answer
rules. The rest is matter of how difficult the extensions are
actually to implement, and how much security problems they
have...



-Ilari

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Jim Schaad]

 

 

From: Eric Rescorla [mailto:e...@rtfm.com] 
Sent: Saturday, March 25, 2017 6:40 AM
To: Jim Schaad 
Cc: Russ Housley ; IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

 

 

 

On Fri, Mar 24, 2017 at 8:14 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:

EKR – I think that is the wrong answer because of the resume case.

 

Why? It seems like for Russ'a application, you would inject the static PSK 
initially

and then it would be implicitly part of any resumption so no need to reinject it

to obtain PQ safety.

 

It seems odd to me that you would want to use a different key agree algorithm 
when you are doing the initial negotiation as opposed to the resumption.   
Depending on how the static PSK is specified, it might need to be restated for 
the resumption as well.

 

Jim

 

 

-Ekr

 

However, I would expect that the external PSK would be appended or otherwise 
munge into the computed secret (assuming DH) and would be consumed as part of 
that processing.  No additional slot needed.

 

jim

 

From: TLS [mailto:tls-boun...@ietf.org <mailto:tls-boun...@ietf.org> ] On 
Behalf Of Eric Rescorla
Sent: Friday, March 24, 2017 12:19 PM
To: Russ Housley mailto:hous...@vigilsec.com> >
Cc: IETF TLS mailto:tls@ietf.org> >
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

 

Why would the external PSK not just go into he PSK slot.

 

-Ekr

 

 

On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley mailto:hous...@vigilsec.com> > wrote:


> I agree with David here. Specifically, I think.
>
> - The base specification should continue to forbid certificates in 
> combination with PSK
> - We should at some point contemplate an extension that allows the use of 
> certificates in combination with PSK
> - The base spec should be factored in such a way as to make that extension 
> easy.


While I agree that we do not want to delay the TLS 1.3 specification to sort 
this out; however, I do not think we have provided the hook to make this future 
extension easy.   Looking at the key schedule in -19, I think we can provide 
the hook without being disruptive.  My goal is to minimize the pain to 
implementing the extension in the future by putting a straightforward hook in 
today:

 0
 |
 v
   PSK ->  HKDF-Extract = Early Secret
 |
 +-> Derive-Secret(.,
 | "external psk binder key" |
 | "resumption psk binder key",
 | "")
 | = binder_key
 |
 +-> Derive-Secret(., "client early traffic secret",
 | ClientHello)
 | = client_early_traffic_secret
 |
 +-> Derive-Secret(., "early exporter master secret",
 | ClientHello)
 | = early_exporter_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
(EC)DHE -> HKDF-Extract = Handshake Secret
 |
 +-> Derive-Secret(., "client handshake traffic secret",
 | ClientHello...ServerHello)
 | = client_handshake_traffic_secret
 |
 +-> Derive-Secret(., "server handshake traffic secret",
 | ClientHello...ServerHello)
 | = server_handshake_traffic_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
ExtPSK OR 0 -> HKDF-Extract = Master Secret
 |
 +-> Derive-Secret(., "client application traffic secret",
 | ClientHello...Server Finished)
 | = client_traffic_secret_0
 |
 +-> Derive-Secret(., "server application traffic secret",
 | ClientHello...Server Finished)
 | = server_traffic_secret_0
 |
 +-> Derive-Secret(., "exporter master secret",
 | ClientHello...Server Finished)
 | = exporter_secret
 |
 +-> Derive-Secret(., "resumption master secret",
   ClientHello...Client Finished)
   = resumption_master_secret


The only ch

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Eric Rescorla]

On Fri, Mar 24, 2017 at 8:14 PM, Jim Schaad  wrote:

> EKR – I think that is the wrong answer because of the resume case.
>

Why? It seems like for Russ'a application, you would inject the static PSK
initially
and then it would be implicitly part of any resumption so no need to
reinject it
to obtain PQ safety.

-Ekr

However, I would expect that the external PSK would be appended or
> otherwise munge into the computed secret (assuming DH) and would be
> consumed as part of that processing.  No additional slot needed.
>
>
>
> jim
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, March 24, 2017 12:19 PM
> *To:* Russ Housley 
> *Cc:* IETF TLS 
> *Subject:* Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
>
>
>
> Why would the external PSK not just go into he PSK slot.
>
>
>
> -Ekr
>
>
>
>
>
> On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley 
> wrote:
>
>
> > I agree with David here. Specifically, I think.
> >
> > - The base specification should continue to forbid certificates in
> combination with PSK
> > - We should at some point contemplate an extension that allows the use
> of certificates in combination with PSK
> > - The base spec should be factored in such a way as to make that
> extension easy.
>
>
> While I agree that we do not want to delay the TLS 1.3 specification to
> sort this out; however, I do not think we have provided the hook to make
> this future extension easy.   Looking at the key schedule in -19, I think
> we can provide the hook without being disruptive.  My goal is to minimize
> the pain to implementing the extension in the future by putting a
> straightforward hook in today:
>
>  0
>  |
>  v
>PSK ->  HKDF-Extract = Early Secret
>  |
>  +-> Derive-Secret(.,
>  | "external psk binder key" |
>  | "resumption psk binder key",
>  | "")
>  | = binder_key
>  |
>  +-> Derive-Secret(., "client early traffic secret",
>  | ClientHello)
>  | = client_early_traffic_secret
>  |
>  +-> Derive-Secret(., "early exporter master secret",
>  | ClientHello)
>  | = early_exporter_secret
>  v
>Derive-Secret(., "derived secret", "")
>  |
>  v
> (EC)DHE -> HKDF-Extract = Handshake Secret
>  |
>  +-> Derive-Secret(., "client handshake traffic
> secret",
>  | ClientHello...ServerHello)
>  | = client_handshake_traffic_secret
>  |
>  +-> Derive-Secret(., "server handshake traffic
> secret",
>  | ClientHello...ServerHello)
>  | = server_handshake_traffic_secret
>  v
>Derive-Secret(., "derived secret", "")
>  |
>  v
> ExtPSK OR 0 -> HKDF-Extract = Master Secret
>  |
>  +-> Derive-Secret(., "client application traffic
> secret",
>  | ClientHello...Server Finished)
>  | = client_traffic_secret_0
>  |
>  +-> Derive-Secret(., "server application traffic
> secret",
>  | ClientHello...Server Finished)
>  | = server_traffic_secret_0
>  |
>  +-> Derive-Secret(., "exporter master secret",
>  | ClientHello...Server Finished)
>  | = exporter_secret
>  |
>  +-> Derive-Secret(., "resumption master secret",
>ClientHello...Client Finished)
>= resumption_master_secret
>
>
> The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret
> computation.
>
> The Section 4.1.1 can call out this place for the future specification:
>

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Jim Schaad]

EKR – I think that is the wrong answer because of the resume case.

 

However, I would expect that the external PSK would be appended or otherwise 
munge into the computed secret (assuming DH) and would be consumed as part of 
that processing.  No additional slot needed.

 

jim

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, March 24, 2017 12:19 PM
To: Russ Housley 
Cc: IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

 

Why would the external PSK not just go into he PSK slot.

 

-Ekr

 

 

On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley mailto:hous...@vigilsec.com> > wrote:


> I agree with David here. Specifically, I think.
>
> - The base specification should continue to forbid certificates in 
> combination with PSK
> - We should at some point contemplate an extension that allows the use of 
> certificates in combination with PSK
> - The base spec should be factored in such a way as to make that extension 
> easy.


While I agree that we do not want to delay the TLS 1.3 specification to sort 
this out; however, I do not think we have provided the hook to make this future 
extension easy.   Looking at the key schedule in -19, I think we can provide 
the hook without being disruptive.  My goal is to minimize the pain to 
implementing the extension in the future by putting a straightforward hook in 
today:

 0
 |
 v
   PSK ->  HKDF-Extract = Early Secret
 |
 +-> Derive-Secret(.,
 | "external psk binder key" |
 | "resumption psk binder key",
 | "")
 | = binder_key
 |
 +-> Derive-Secret(., "client early traffic secret",
 | ClientHello)
 | = client_early_traffic_secret
 |
 +-> Derive-Secret(., "early exporter master secret",
 | ClientHello)
 | = early_exporter_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
(EC)DHE -> HKDF-Extract = Handshake Secret
 |
 +-> Derive-Secret(., "client handshake traffic secret",
 | ClientHello...ServerHello)
 | = client_handshake_traffic_secret
 |
 +-> Derive-Secret(., "server handshake traffic secret",
 | ClientHello...ServerHello)
 | = server_handshake_traffic_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
ExtPSK OR 0 -> HKDF-Extract = Master Secret
 |
 +-> Derive-Secret(., "client application traffic secret",
 | ClientHello...Server Finished)
 | = client_traffic_secret_0
 |
 +-> Derive-Secret(., "server application traffic secret",
 | ClientHello...Server Finished)
 | = server_traffic_secret_0
 |
 +-> Derive-Secret(., "exporter master secret",
 | ClientHello...Server Finished)
 | = exporter_secret
 |
 +-> Derive-Secret(., "resumption master secret",
   ClientHello...Client Finished)
   = resumption_master_secret


The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret 
computation.

The Section 4.1.1 can call out this place for the future specification:

OLD:

   -  When authenticating via a certificate, the server will send the
  Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
  messages.  In TLS 1.3 as defined by this document, either a PSK or
  a certificate is always used, but not both.  Future documents may
  define how to use them together.

NEW:

   -  When authenticating via a certificate, the server will send the
  Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
  messages.  In TLS 1.3 as defined by this document, either a PSK or
  a certificate is always used, but not both.  So, the ExtPSK is not
  used in the key schedule (Section 7.1).  Future documents may
  define how to use them together and tell how the ExtPSK is
  handled in the key schedule.

Russ



 

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Eric Rescorla]

Why would the external PSK not just go into he PSK slot.

-Ekr


On Fri, Mar 24, 2017 at 9:16 AM, Russ Housley  wrote:

>
> > I agree with David here. Specifically, I think.
> >
> > - The base specification should continue to forbid certificates in
> combination with PSK
> > - We should at some point contemplate an extension that allows the use
> of certificates in combination with PSK
> > - The base spec should be factored in such a way as to make that
> extension easy.
>
>
> While I agree that we do not want to delay the TLS 1.3 specification to
> sort this out; however, I do not think we have provided the hook to make
> this future extension easy.   Looking at the key schedule in -19, I think
> we can provide the hook without being disruptive.  My goal is to minimize
> the pain to implementing the extension in the future by putting a
> straightforward hook in today:
>
>  0
>  |
>  v
>PSK ->  HKDF-Extract = Early Secret
>  |
>  +-> Derive-Secret(.,
>  | "external psk binder key" |
>  | "resumption psk binder key",
>  | "")
>  | = binder_key
>  |
>  +-> Derive-Secret(., "client early traffic secret",
>  | ClientHello)
>  | = client_early_traffic_secret
>  |
>  +-> Derive-Secret(., "early exporter master secret",
>  | ClientHello)
>  | = early_exporter_secret
>  v
>Derive-Secret(., "derived secret", "")
>  |
>  v
> (EC)DHE -> HKDF-Extract = Handshake Secret
>  |
>  +-> Derive-Secret(., "client handshake traffic
> secret",
>  | ClientHello...ServerHello)
>  | = client_handshake_traffic_secret
>  |
>  +-> Derive-Secret(., "server handshake traffic
> secret",
>  | ClientHello...ServerHello)
>  | = server_handshake_traffic_secret
>  v
>Derive-Secret(., "derived secret", "")
>  |
>  v
> ExtPSK OR 0 -> HKDF-Extract = Master Secret
>  |
>  +-> Derive-Secret(., "client application traffic
> secret",
>  | ClientHello...Server Finished)
>  | = client_traffic_secret_0
>  |
>  +-> Derive-Secret(., "server application traffic
> secret",
>  | ClientHello...Server Finished)
>  | = server_traffic_secret_0
>  |
>  +-> Derive-Secret(., "exporter master secret",
>  | ClientHello...Server Finished)
>  | = exporter_secret
>  |
>  +-> Derive-Secret(., "resumption master secret",
>ClientHello...Client Finished)
>= resumption_master_secret
>
>
> The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret
> computation.
>
> The Section 4.1.1 can call out this place for the future specification:
>
> OLD:
>
>-  When authenticating via a certificate, the server will send the
>   Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
>   messages.  In TLS 1.3 as defined by this document, either a PSK or
>   a certificate is always used, but not both.  Future documents may
>   define how to use them together.
>
> NEW:
>
>-  When authenticating via a certificate, the server will send the
>   Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
>   messages.  In TLS 1.3 as defined by this document, either a PSK or
>   a certificate is always used, but not both.  So, the ExtPSK is not
>   used in the key schedule (Section 7.1).  Future documents may
>   define how to use them together and tell how the ExtPSK is
>   handled in the key schedule.
>
> Russ
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Russ Housley]

> I agree with David here. Specifically, I think.
> 
> - The base specification should continue to forbid certificates in 
> combination with PSK
> - We should at some point contemplate an extension that allows the use of 
> certificates in combination with PSK
> - The base spec should be factored in such a way as to make that extension 
> easy.


While I agree that we do not want to delay the TLS 1.3 specification to sort 
this out; however, I do not think we have provided the hook to make this future 
extension easy.   Looking at the key schedule in -19, I think we can provide 
the hook without being disruptive.  My goal is to minimize the pain to 
implementing the extension in the future by putting a straightforward hook in 
today:

 0
 |
 v
   PSK ->  HKDF-Extract = Early Secret
 |
 +-> Derive-Secret(.,
 | "external psk binder key" |
 | "resumption psk binder key",
 | "")
 | = binder_key
 |
 +-> Derive-Secret(., "client early traffic secret",
 | ClientHello)
 | = client_early_traffic_secret
 |
 +-> Derive-Secret(., "early exporter master secret",
 | ClientHello)
 | = early_exporter_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
(EC)DHE -> HKDF-Extract = Handshake Secret
 |
 +-> Derive-Secret(., "client handshake traffic secret",
 | ClientHello...ServerHello)
 | = client_handshake_traffic_secret
 |
 +-> Derive-Secret(., "server handshake traffic secret",
 | ClientHello...ServerHello)
 | = server_handshake_traffic_secret
 v
   Derive-Secret(., "derived secret", "")
 |
 v
ExtPSK OR 0 -> HKDF-Extract = Master Secret
 |
 +-> Derive-Secret(., "client application traffic secret",
 | ClientHello...Server Finished)
 | = client_traffic_secret_0
 |
 +-> Derive-Secret(., "server application traffic secret",
 | ClientHello...Server Finished)
 | = server_traffic_secret_0
 |
 +-> Derive-Secret(., "exporter master secret",
 | ClientHello...Server Finished)
 | = exporter_secret
 |
 +-> Derive-Secret(., "resumption master secret",
   ClientHello...Client Finished)
   = resumption_master_secret


The only change is "ExtPSK OR 0” in the HKDF-Extract for the Master Secret 
computation.

The Section 4.1.1 can call out this place for the future specification:

OLD:

   -  When authenticating via a certificate, the server will send the
  Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
  messages.  In TLS 1.3 as defined by this document, either a PSK or
  a certificate is always used, but not both.  Future documents may
  define how to use them together.

NEW:

   -  When authenticating via a certificate, the server will send the
  Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
  messages.  In TLS 1.3 as defined by this document, either a PSK or
  a certificate is always used, but not both.  So, the ExtPSK is not
  used in the key schedule (Section 7.1).  Future documents may
  define how to use them together and tell how the ExtPSK is
  handled in the key schedule.

Russ


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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Eric Rescorla]

I agree with David here. Specifically, I think.

- The base specification should continue to forbid certificates in
combination with PSK
- We should at some point contemplate an extension that allows the use of
certificates in combination with PSK
- The base spec should be factored in such a way as to make that extension
easy.

-Ekr


On Thu, Feb 2, 2017 at 8:24 AM, David Benjamin 
wrote:

> I think this is much clearer, except for one bullet point below:
>
> On Thu, Feb 2, 2017 at 10:22 AM Russ Housley  wrote:
>
>> [...]
>>   -  If PSK and (EC)DH are being used together, then the server will:
>>
>>  --  sends a "pre_shared_key" extension to indicate the selected
>>  key;
>>
>>  --  provide a "key_share" extension; and
>>
>>  --  send the Certificate (Section 4.4.1) and CertificateVerify
>>  (Section 4.4.2) messages.
>
>
> This last bullet here contradicts what specification says elsewhere. From
> 4.4.1:
>
> """
> The server MUST send a Certificate message whenever the agreed-upon key
> exchange method uses certificates for authentication (this includes all key
> exchange methods defined in this document except PSK). This message conveys
> the endpoint’s certificate chain to the peer.
> """
>
> (Otherwise we defeat the point of resumption and lose PSK-based
> identities.)
>
> Like MT, I am interested in a mode with both (right now we have a ticket
> renewal cliff because only the initial handshake does an online signature),
> but we'll need to work out the exact semantics. Going from one identity to
> two identities, especially when one is added partway through the stream
> (consider 0-RTT) has a lot of sharp edges.
>
> Since this can easily be added as an extension (and would need one anyway
> for negotiation), I think it's better to do it as a later document, so we
> don't delay what we've done already or rush in a combined mode without
> considering all the details. The document would just say "when PSK and
> fancy_new_extension are both negotiated, then the server will [...]".
> Plenty of extensions have modified the handshake message flow.
>
> David
>
> ___
> 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] Using both External PSK and (EC)DH in TLS 1.3

[David Benjamin]

I think this is much clearer, except for one bullet point below:

On Thu, Feb 2, 2017 at 10:22 AM Russ Housley  wrote:

> [...]
>   -  If PSK and (EC)DH are being used together, then the server will:
>
>  --  sends a "pre_shared_key" extension to indicate the selected
>  key;
>
>  --  provide a "key_share" extension; and
>
>  --  send the Certificate (Section 4.4.1) and CertificateVerify
>  (Section 4.4.2) messages.


This last bullet here contradicts what specification says elsewhere. From
4.4.1:

"""
The server MUST send a Certificate message whenever the agreed-upon key
exchange method uses certificates for authentication (this includes all key
exchange methods defined in this document except PSK). This message conveys
the endpoint’s certificate chain to the peer.
"""

(Otherwise we defeat the point of resumption and lose PSK-based identities.)

Like MT, I am interested in a mode with both (right now we have a ticket
renewal cliff because only the initial handshake does an online signature),
but we'll need to work out the exact semantics. Going from one identity to
two identities, especially when one is added partway through the stream
(consider 0-RTT) has a lot of sharp edges.

Since this can easily be added as an extension (and would need one anyway
for negotiation), I think it's better to do it as a later document, so we
don't delay what we've done already or rush in a combined mode without
considering all the details. The document would just say "when PSK and
fancy_new_extension are both negotiated, then the server will [...]".
Plenty of extensions have modified the handshake message flow.

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Russ Housley]

Proposed update to Section 4.1.1 of draft-ietf-tls-tls13-18

OLD:

  The server indicates its selected parameters in the ServerHello as
  follows:

  -  If PSK is being used then the server will send a "pre_shared_key"
 extension indicating the selected key.

  -  If PSK is not being used, then (EC)DHE and certificate-based
 authentication are always used.

  -  When (EC)DHE is in use, the server will also provide a "key_share"
 extension.

  -  When authenticating via a certificate (i.e., when a PSK is not in
 use), the server will send the Certificate (Section 4.4.1) and
 CertificateVerify (Section 4.4.2) messages.

NEW:

  The server indicates its selected parameters in the ServerHello as
  follows:

  -  If PSK is not being used, then (EC)DHE and certificate-based
 authentication are always used, and the server will:

 --  provide a "key_share" extension; and

 --  send the Certificate (Section 4.4.1) and CertificateVerify
 (Section 4.4.2) messages.

  -  If PSK (without DH or ECDH) is being used, then the server sends a
 "pre_shared_key" extension to indicate the selected key.

  -  If PSK and (EC)DH are being used together, then the server will:

 --  sends a "pre_shared_key" extension to indicate the selected
 key;

 --  provide a "key_share" extension; and

 --  send the Certificate (Section 4.4.1) and CertificateVerify
 (Section 4.4.2) messages.

END

Many thanks to Sean Turner for turning this into a PR for me:
https://github.com/tlswg/tls13-spec/pull/870

Thanks,
  Russ

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Benjamin Kaduk]

Hi Russ,

On 01/04/2017 03:17 PM, Russ Housley wrote:
> Ben:
>
>> I also had the sense that ekr noted that we didn't want to do this in
>> the core spec.
>> So, could you point me more clearly at what you would want to change
>> in the core spec that would allow doing the thing you want to see
>> done in a future document?  (Is it just removing "i.e., when a PSK is
>> not in use"?)
>>
>
> I am not looking to put the details in the core spec.  I think I said
> that in my first posting.  However, I do want to ensure that the
> identity associated with the external PSK and the certificate are both
> considered.  There needs to be a hook in the core spec for that to happen.
>

I understand that.

> I quotes the part of the core spec that seems to say otherwise.
>

What I don't understand is exactly which part or parts in combination of
the quoted text are saying otherwise, in your reading of it.  I offered
a potential part of the quoted text which might be leading you to that
interpretation (the "i.e., when a PSK is not in use" clause), and you
did not confirm or deny my guess.  So, I still don't understand what
seems problematic to you about the existing text -- to me, it says that
certain things must be done if certain other things are or are not done,
but does not seem to preclude certain things being done and certain
other things also being done. Maybe you could propose a patch that
provides the hook that you would like to see, so that I can understand
the issue with the current text?

-Ben

>
 On Thu, Dec 22, 2016 at 4:54 PM Russ Housley >>> > wrote:

 I want to make sure that it is possible to mix PSK with (EC)DH
 as a protection against the discovery of a quantum computer.  I
 recognize that the WG does not want to tackle this topic in the
 base specification; however, the following text in Section
 4.1.1 makes this difficult to do so in a companion document:

 >The server indicates its selected parameters in the
 ServerHello as
 >follows:
 >
 >-  If PSK is being used then the server will send a
 "pre_shared_key"
 >   extension indicating the selected key.
 >
 >-  If PSK is not being used, then (EC)DHE and
 certificate-based
 >   authentication are always used.
 >
 >-  When (EC)DHE is in use, the server will also provide a
 "key_share"
 >   extension.
 >
 >-  When authenticating via a certificate (i.e., when a PSK
 is not in
 >   use), the server will send the Certificate (Section
 4.4.1) and
 >   CertificateVerify (Section 4.4.2) messages.

>
> Russ

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Russ Housley]

On Jan 3, 2017, at 9:36 PM, Martin Thomson  wrote:

> On 4 January 2017 at 12:02, Benjamin Kaduk  wrote:
>> I also had the sense that ekr noted that we didn't want to do this in the
>> core spec.
>> So, could you point me more clearly at what you would want to change in the
>> core spec that would allow doing the thing you want to see done in a future
>> document?  (Is it just removing "i.e., when a PSK is not in use"?)
> 
> I for one am interested in having a mode that allows for PSK+cert, but
> it's hard to reason through.  It falls into the same bucket as
> additive *server* authentication, which has the same inherent
> problems.  Foremost being a solid analysis.
> 
> Mechanically, it is fairly simple to add as an extension.  That makes
> me confident that we can do this later.

Mee too.  At this point, the spec calls for the identity to come from the PSK 
or the certificate.  I think there needs to be a hook in the document for the 
identity to come from a combination of the PSK and the certificate.  I 
recognize this is a forward pointer to stuff that is not yet sorted out.

Russ

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Russ Housley]

Ben:

> I also had the sense that ekr noted that we didn't want to do this in the 
> core spec.
> So, could you point me more clearly at what you would want to change in the 
> core spec that would allow doing the thing you want to see done in a future 
> document?  (Is it just removing "i.e., when a PSK is not in use"?)
> 

I am not looking to put the details in the core spec.  I think I said that in 
my first posting.  However, I do want to ensure that the identity associated 
with the external PSK and the certificate are both considered.  There needs to 
be a hook in the core spec for that to happen.

I quotes the part of the core spec that seems to say otherwise.


>>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley  wrote:
>>> I want to make sure that it is possible to mix PSK with (EC)DH as a 
>>> protection against the discovery of a quantum computer.  I recognize that 
>>> the WG does not want to tackle this topic in the base specification; 
>>> however, the following text in Section 4.1.1 makes this difficult to do so 
>>> in a companion document:
>>> 
>>> >The server indicates its selected parameters in the ServerHello as
>>> >follows:
>>> >
>>> >-  If PSK is being used then the server will send a "pre_shared_key"
>>> >   extension indicating the selected key.
>>> >
>>> >-  If PSK is not being used, then (EC)DHE and certificate-based
>>> >   authentication are always used.
>>> >
>>> >-  When (EC)DHE is in use, the server will also provide a "key_share"
>>> >   extension.
>>> >
>>> >-  When authenticating via a certificate (i.e., when a PSK is not in
>>> >   use), the server will send the Certificate (Section 4.4.1) and
>>> >   CertificateVerify (Section 4.4.2) messages.

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Martin Thomson]

On 4 January 2017 at 12:02, Benjamin Kaduk  wrote:
> I also had the sense that ekr noted that we didn't want to do this in the
> core spec.
> So, could you point me more clearly at what you would want to change in the
> core spec that would allow doing the thing you want to see done in a future
> document?  (Is it just removing "i.e., when a PSK is not in use"?)

I for one am interested in having a mode that allows for PSK+cert, but
it's hard to reason through.  It falls into the same bucket as
additive *server* authentication, which has the same inherent
problems.  Foremost being a solid analysis.

Mechanically, it is fairly simple to add as an extension.  That makes
me confident that we can do this later.

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

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Benjamin Kaduk]

I also had the sense that ekr noted that we didn't want to do this in
the core spec.
So, could you point me more clearly at what you would want to change in
the core spec that would allow doing the thing you want to see done in a
future document?  (Is it just removing "i.e., when a PSK is not in use"?)

-Ben

On 12/22/2016 04:29 PM, Russ Housley wrote:
> David:
>
> Yes, it does allow both, but the authentication is unclear when both
> are in play. The last bullet implies that certificate authentication
> only comes into play when there is no PSK.  So, if there is a PSK, the
> identity associated with it seems to trump whatever is in the certificate.
>
> As I explained below, I’d like the identity associate with the
> External PSK and the identity in the certificate to both have a role.
>
> Russ
>
>
> On Dec 22, 2016, at 5:12 PM, David Benjamin  > wrote:
>
>> It's possible I'm misunderstanding your message here (I'm a little
>> confused by the mention of combining normal certificate
>> authentication with an external PSK), but TLS 1.3 already allows
>> doing both PSK and (EC)DH. That's the psk_dhe_ke mode, rather than
>> the psk_ke mode. It's signaled by the server by sending both
>> pre_shared_key and key_share extensions. Perhaps the wording should
>> be a bit clearer.
>>
>> Our stack does not even implement psk_ke. It always requires an
>> (EC)DH operation in a TLS 1.3 handshake, whether using PSK or
>> certificates.
>>
>> David
>>
>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley > > wrote:
>>
>> I want to make sure that it is possible to mix PSK with (EC)DH as
>> a protection against the discovery of a quantum computer.  I
>> recognize that the WG does not want to tackle this topic in the
>> base specification; however, the following text in Section 4.1.1
>> makes this difficult to do so in a companion document:
>>
>> >The server indicates its selected parameters in the
>> ServerHello as
>> >follows:
>> >
>> >-  If PSK is being used then the server will send a
>> "pre_shared_key"
>> >   extension indicating the selected key.
>> >
>> >-  If PSK is not being used, then (EC)DHE and certificate-based
>> >   authentication are always used.
>> >
>> >-  When (EC)DHE is in use, the server will also provide a
>> "key_share"
>> >   extension.
>> >
>> >-  When authenticating via a certificate (i.e., when a PSK
>> is not in
>> >   use), the server will send the Certificate (Section
>> 4.4.1) and
>> >   CertificateVerify (Section 4.4.2) messages.
>>
>> An Internal PSK offers no protection against the discovery of a
>> quantum computer.  I assume that an attacker can save the
>> handshake that established the Internal PSK, and then at some
>> future date use the quantum computer to discover the Internal
>> PSK.  Therefore, protection against the discovery of a quantum
>> computer is only concerned with External PSK.
>>
>> I would like for the specification to permit normal certificate
>> authentication when someone is using an External PSK.  I am
>> guessing that the granularity of the name associated with the
>> External PSK to be pretty broad.  If this guess is correct, it
>> would be appropriate for the name in the certificate to be
>> further restrict the one associated with the External PSK.  Maybe
>> the External PSK is associated with example.com
>> 
>> ,
>> and then the certificate that includes www.example.com
>> 
>> 
>> would be acceptable acceptable.  Then, I would expect any
>> Internal PSK that is generated after such an authentication would
>> be associated with the more granular certificate name.
>>
>> Maybe it is as simple as reorganizing these bullets like this:
>>
>>- When only PSK is being used, …
>>
>>- When only (EC)DHE is being used, …
>>
>>- When PSK and (EC)DHE are both being used, …
>>
>> If others agree with this direction, I am willing to propose some
>> text.
>>
>> Happy holidays,
>>Russ
>> ___
>> TLS mailing list
>> TLS@ietf.org 
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> 

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[Eric Rescorla]

On Thu, Dec 22, 2016 at 2:28 PM, Joseph Salowey  wrote:

> Does you implementation allow a PSK to be used along with certificate
> based authentication?
>

There is presently no way to negotiate this in TLS 1.3. I have been
assuming that if we decide we
want this we would add a psk_auth_mode extension to parallel psk_ke_mode.
The sense of a number
of us is that there are enough complications with adding this feature
(consider what happens if the
server provides a different set of SANs) that we should add it later.

-Ekr


> On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin 
> wrote:
>
>> It's possible I'm misunderstanding your message here (I'm a little
>> confused by the mention of combining normal certificate authentication with
>> an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH.
>> That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by
>> the server by sending both pre_shared_key and key_share extensions. Perhaps
>> the wording should be a bit clearer.
>>
>> Our stack does not even implement psk_ke. It always requires an (EC)DH
>> operation in a TLS 1.3 handshake, whether using PSK or certificates.
>>
>> David
>>
>>
>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley 
>> wrote:
>>
>>> I want to make sure that it is possible to mix PSK with (EC)DH as a
>>> protection against the discovery of a quantum computer.  I recognize that
>>> the WG does not want to tackle this topic in the base specification;
>>> however, the following text in Section 4.1.1 makes this difficult to do so
>>> in a companion document:
>>>
>>> >The server indicates its selected parameters in the ServerHello as
>>> >follows:
>>> >
>>> >-  If PSK is being used then the server will send a "pre_shared_key"
>>> >   extension indicating the selected key.
>>> >
>>> >-  If PSK is not being used, then (EC)DHE and certificate-based
>>> >   authentication are always used.
>>> >
>>> >-  When (EC)DHE is in use, the server will also provide a
>>> "key_share"
>>> >   extension.
>>> >
>>> >-  When authenticating via a certificate (i.e., when a PSK is not in
>>> >   use), the server will send the Certificate (Section 4.4.1) and
>>> >   CertificateVerify (Section 4.4.2) messages.
>>>
>>> An Internal PSK offers no protection against the discovery of a quantum
>>> computer.  I assume that an attacker can save the handshake that
>>> established the Internal PSK, and then at some future date use the quantum
>>> computer to discover the Internal PSK.  Therefore, protection against the
>>> discovery of a quantum computer is only concerned with External PSK.
>>>
>>> I would like for the specification to permit normal certificate
>>> authentication when someone is using an External PSK.  I am guessing that
>>> the granularity of the name associated with the External PSK to be pretty
>>> broad.  If this guess is correct, it would be appropriate for the name in
>>> the certificate to be further restrict the one associated with the External
>>> PSK.  Maybe the External PSK is associated with example.com, and then
>>> the certificate that includes www.example.com would be acceptable
>>> acceptable.  Then, I would expect any Internal PSK that is generated after
>>> such an authentication would be associated with the more granular
>>> certificate name.
>>>
>>> Maybe it is as simple as reorganizing these bullets like this:
>>>
>>>- When only PSK is being used, …
>>>
>>>- When only (EC)DHE is being used, …
>>>
>>>- When PSK and (EC)DHE are both being used, …
>>>
>>> If others agree with this direction, I am willing to propose some text.
>>>
>>> Happy holidays,
>>>Russ
>>> ___
>>> 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
>>
>>
>
> ___
> 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] Using both External PSK and (EC)DH in TLS 1.3

[Russ Housley]

David:

Yes, it does allow both, but the authentication is unclear when both are in 
play. The last bullet implies that certificate authentication only comes into 
play when there is no PSK.  So, if there is a PSK, the identity associated with 
it seems to trump whatever is in the certificate.

As I explained below, I’d like the identity associate with the External PSK and 
the identity in the certificate to both have a role.

Russ


On Dec 22, 2016, at 5:12 PM, David Benjamin  wrote:

> It's possible I'm misunderstanding your message here (I'm a little confused 
> by the mention of combining normal certificate authentication with an 
> external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's 
> the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the server 
> by sending both pre_shared_key and key_share extensions. Perhaps the wording 
> should be a bit clearer.
> 
> Our stack does not even implement psk_ke. It always requires an (EC)DH 
> operation in a TLS 1.3 handshake, whether using PSK or certificates.
> 
> David
> 
> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley  wrote:
> I want to make sure that it is possible to mix PSK with (EC)DH as a 
> protection against the discovery of a quantum computer.  I recognize that the 
> WG does not want to tackle this topic in the base specification; however, the 
> following text in Section 4.1.1 makes this difficult to do so in a companion 
> document:
> 
> >The server indicates its selected parameters in the ServerHello as
> >follows:
> >
> >-  If PSK is being used then the server will send a "pre_shared_key"
> >   extension indicating the selected key.
> >
> >-  If PSK is not being used, then (EC)DHE and certificate-based
> >   authentication are always used.
> >
> >-  When (EC)DHE is in use, the server will also provide a "key_share"
> >   extension.
> >
> >-  When authenticating via a certificate (i.e., when a PSK is not in
> >   use), the server will send the Certificate (Section 4.4.1) and
> >   CertificateVerify (Section 4.4.2) messages.
> 
> An Internal PSK offers no protection against the discovery of a quantum 
> computer.  I assume that an attacker can save the handshake that established 
> the Internal PSK, and then at some future date use the quantum computer to 
> discover the Internal PSK.  Therefore, protection against the discovery of a 
> quantum computer is only concerned with External PSK.
> 
> I would like for the specification to permit normal certificate 
> authentication when someone is using an External PSK.  I am guessing that the 
> granularity of the name associated with the External PSK to be pretty broad.  
> If this guess is correct, it would be appropriate for the name in the 
> certificate to be further restrict the one associated with the External PSK.  
> Maybe the External PSK is associated with example.com, and then the 
> certificate that includes www.example.com would be acceptable acceptable.  
> Then, I would expect any Internal PSK that is generated after such an 
> authentication would be associated with the more granular certificate name.
> 
> Maybe it is as simple as reorganizing these bullets like this:
> 
>- When only PSK is being used, …
> 
>- When only (EC)DHE is being used, …
> 
>- When PSK and (EC)DHE are both being used, …
> 
> If others agree with this direction, I am willing to propose some text.
> 
> Happy holidays,
>Russ
> ___
> 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] Using both External PSK and (EC)DH in TLS 1.3

[Joseph Salowey]

Does you implementation allow a PSK to be used along with certificate based
authentication?

On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin 
wrote:

> It's possible I'm misunderstanding your message here (I'm a little
> confused by the mention of combining normal certificate authentication with
> an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH.
> That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by
> the server by sending both pre_shared_key and key_share extensions. Perhaps
> the wording should be a bit clearer.
>
> Our stack does not even implement psk_ke. It always requires an (EC)DH
> operation in a TLS 1.3 handshake, whether using PSK or certificates.
>
> David
>
>
> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley  wrote:
>
>> I want to make sure that it is possible to mix PSK with (EC)DH as a
>> protection against the discovery of a quantum computer.  I recognize that
>> the WG does not want to tackle this topic in the base specification;
>> however, the following text in Section 4.1.1 makes this difficult to do so
>> in a companion document:
>>
>> >The server indicates its selected parameters in the ServerHello as
>> >follows:
>> >
>> >-  If PSK is being used then the server will send a "pre_shared_key"
>> >   extension indicating the selected key.
>> >
>> >-  If PSK is not being used, then (EC)DHE and certificate-based
>> >   authentication are always used.
>> >
>> >-  When (EC)DHE is in use, the server will also provide a "key_share"
>> >   extension.
>> >
>> >-  When authenticating via a certificate (i.e., when a PSK is not in
>> >   use), the server will send the Certificate (Section 4.4.1) and
>> >   CertificateVerify (Section 4.4.2) messages.
>>
>> An Internal PSK offers no protection against the discovery of a quantum
>> computer.  I assume that an attacker can save the handshake that
>> established the Internal PSK, and then at some future date use the quantum
>> computer to discover the Internal PSK.  Therefore, protection against the
>> discovery of a quantum computer is only concerned with External PSK.
>>
>> I would like for the specification to permit normal certificate
>> authentication when someone is using an External PSK.  I am guessing that
>> the granularity of the name associated with the External PSK to be pretty
>> broad.  If this guess is correct, it would be appropriate for the name in
>> the certificate to be further restrict the one associated with the External
>> PSK.  Maybe the External PSK is associated with example.com, and then
>> the certificate that includes www.example.com would be acceptable
>> acceptable.  Then, I would expect any Internal PSK that is generated after
>> such an authentication would be associated with the more granular
>> certificate name.
>>
>> Maybe it is as simple as reorganizing these bullets like this:
>>
>>- When only PSK is being used, …
>>
>>- When only (EC)DHE is being used, …
>>
>>- When PSK and (EC)DHE are both being used, …
>>
>> If others agree with this direction, I am willing to propose some text.
>>
>> Happy holidays,
>>Russ
>> ___
>> 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

[David Benjamin]

It's possible I'm misunderstanding your message here (I'm a little confused
by the mention of combining normal certificate authentication with an
external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's
the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the
server by sending both pre_shared_key and key_share extensions. Perhaps the
wording should be a bit clearer.

Our stack does not even implement psk_ke. It always requires an (EC)DH
operation in a TLS 1.3 handshake, whether using PSK or certificates.

David

On Thu, Dec 22, 2016 at 4:54 PM Russ Housley  wrote:

> I want to make sure that it is possible to mix PSK with (EC)DH as a
> protection against the discovery of a quantum computer.  I recognize that
> the WG does not want to tackle this topic in the base specification;
> however, the following text in Section 4.1.1 makes this difficult to do so
> in a companion document:
>
> >The server indicates its selected parameters in the ServerHello as
> >follows:
> >
> >-  If PSK is being used then the server will send a "pre_shared_key"
> >   extension indicating the selected key.
> >
> >-  If PSK is not being used, then (EC)DHE and certificate-based
> >   authentication are always used.
> >
> >-  When (EC)DHE is in use, the server will also provide a "key_share"
> >   extension.
> >
> >-  When authenticating via a certificate (i.e., when a PSK is not in
> >   use), the server will send the Certificate (Section 4.4.1) and
> >   CertificateVerify (Section 4.4.2) messages.
>
> An Internal PSK offers no protection against the discovery of a quantum
> computer.  I assume that an attacker can save the handshake that
> established the Internal PSK, and then at some future date use the quantum
> computer to discover the Internal PSK.  Therefore, protection against the
> discovery of a quantum computer is only concerned with External PSK.
>
> I would like for the specification to permit normal certificate
> authentication when someone is using an External PSK.  I am guessing that
> the granularity of the name associated with the External PSK to be pretty
> broad.  If this guess is correct, it would be appropriate for the name in
> the certificate to be further restrict the one associated with the External
> PSK.  Maybe the External PSK is associated with example.com, and then the
> certificate that includes www.example.com would be acceptable
> acceptable.  Then, I would expect any Internal PSK that is generated after
> such an authentication would be associated with the more granular
> certificate name.
>
> Maybe it is as simple as reorganizing these bullets like this:
>
>- When only PSK is being used, …
>
>- When only (EC)DHE is being used, …
>
>- When PSK and (EC)DHE are both being used, …
>
> If others agree with this direction, I am willing to propose some text.
>
> Happy holidays,
>Russ
> ___
> 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

[TLS] Using both External PSK and (EC)DH in TLS 1.3

[Russ Housley]

I want to make sure that it is possible to mix PSK with (EC)DH as a protection 
against the discovery of a quantum computer.  I recognize that the WG does not 
want to tackle this topic in the base specification; however, the following 
text in Section 4.1.1 makes this difficult to do so in a companion document:

>The server indicates its selected parameters in the ServerHello as
>follows:
>
>-  If PSK is being used then the server will send a "pre_shared_key"
>   extension indicating the selected key.
>
>-  If PSK is not being used, then (EC)DHE and certificate-based
>   authentication are always used.
>
>-  When (EC)DHE is in use, the server will also provide a "key_share"
>   extension.
>
>-  When authenticating via a certificate (i.e., when a PSK is not in
>   use), the server will send the Certificate (Section 4.4.1) and
>   CertificateVerify (Section 4.4.2) messages.

An Internal PSK offers no protection against the discovery of a quantum 
computer.  I assume that an attacker can save the handshake that established 
the Internal PSK, and then at some future date use the quantum computer to 
discover the Internal PSK.  Therefore, protection against the discovery of a 
quantum computer is only concerned with External PSK.

I would like for the specification to permit normal certificate authentication 
when someone is using an External PSK.  I am guessing that the granularity of 
the name associated with the External PSK to be pretty broad.  If this guess is 
correct, it would be appropriate for the name in the certificate to be further 
restrict the one associated with the External PSK.  Maybe the External PSK is 
associated with example.com, and then the certificate that includes 
www.example.com would be acceptable acceptable.  Then, I would expect any 
Internal PSK that is generated after such an authentication would be associated 
with the more granular certificate name.

Maybe it is as simple as reorganizing these bullets like this:

   - When only PSK is being used, …

   - When only (EC)DHE is being used, …

   - When PSK and (EC)DHE are both being used, …

If others agree with this direction, I am willing to propose some text.

Happy holidays,
   Russ
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls