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
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Saturday, March 25, 2017 6:40 AM
To: Jim Schaad <i...@augustcellars.com>
Cc: Russ Housley <hous...@vigilsec.com>; IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
On Fri, Ma
gt;
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, March 24, 2017 12:19 PM
> *To:* Russ Housley <hous...@vigilsec.com>
> *Cc:* IETF TLS <tls@ietf.org>
> *Subject:* Re: [TLS] Using both External PSK and (EC)DH in TLS 1
[mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, March 24, 2017 12:19 PM
To: Russ Housley <hous...@vigilsec.com>
Cc: IETF TLS <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 sl
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
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
>
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
>>
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.,
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
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
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
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
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
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
14 matches
Mail list logo