From: TLS On Behalf Of Eric Rescorla
Sent: 09 March 2021 06:27
To: Dan Harkins
Cc:
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins
mailto:dhark...@lounge.org>> wrote:
Hi Eric,
On 3/8/21 8:00 AM, Eric Rescorla wrote:
Taking a step
From: TLS On Behalf Of Joseph Salowey
Sent: 09 March 2021 23:47
To: Dan Harkins
Cc:
Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins
mailto:dhark...@lounge.org>> wrote:
Hi Eric,
On 3/8/21 8:00 AM, Eric Rescorla wrote:
Taking a step
On Tue, Mar 9, 2021 at 1:05 PM Viktor Dukhovni wrote:
>
> On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote:
>
> > > Because there are still many TLS (non-web) implementations that don't
> > > do ECDHE.
> >
> > I'm confused: if those implementations don't do ECDHE, what's wrong
> >
Carrick Bartle wrote:
> I think the blanket prohibition of reuse of ECDHE keys is maybe not
> really justified.
>
> Why is that?
>
PFS isn't all-or-nothing. I do think each key should be used when
practical, although I don't know why it would be bad to reuse a key for a
very short period of
Oh, never mind, presumably you're referring to the proposal in this thread.
> On Mar 9, 2021, at 4:47 PM, Carrick Bartle
> wrote:
>
>> The proposal on the table is to deprecate FFDHE.
>
> Sorry, the title of the document is incorrect and will be changed. The actual
> proposal is not to
> The proposal on the table is to deprecate FFDHE.
Sorry, the title of the document is incorrect and will be changed. The actual
proposal is not to deprecate FFDHE but to deprecate FFDH and prohibit key reuse
for FFDHE.
> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni wrote:
>
> On Tue, Mar
Andrei Popov wrote:
> Hi Brian,
>
>
>
>- Look at Windows Server 2012 and similar legacy products that are in
>widespread use, which don't support any PFS cipher suites except FFDHE.
>
> Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and
> TLS_ECDHE_RSA cipher suites: TLS
On Sun, Feb 28, 2021 at 9:35 AM Stephen Farrell
wrote:
>
> - This is *much* harder to implement compared to ESNI as
>it interacts with the rest of the TLS stack/library in
>many more ways. It should be an explicit goal to reduce
>that complexity IMO and not increase it further.
>
I
On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bartle wrote:
> > Because there are still many TLS (non-web) implementations that don't
> > do ECDHE.
>
> I'm confused: if those implementations don't do ECDHE, what's wrong
> with prohibiting the way it's used?
The proposal on the table is to
>>> I think the blanket prohibition of reuse of ECDHE keys is maybe not
>>> really justified.
>>
>> Why is that?
>
> Because there are still many TLS (non-web) implementations that don't
> do ECDHE.
I'm confused: if those implementations don't do ECDHE, what's wrong with
prohibiting the way
On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins wrote:
>
> Hi Eric,
>
> On 3/8/21 8:00 AM, Eric Rescorla wrote:
>
> Taking a step back from the crypto, I'm trying to make sure I
> understand the desired security properties. As I understand the
> situation:
>
> - the client has a preconfigured key
11 matches
Mail list logo
