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 compa
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
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
>
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
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 extens
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 us
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
> d
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
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
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
>> d
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
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;
>
> -
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
> 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
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 poi
[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
ailto: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 slo
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
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
>
19 matches
Mail list logo
