> Which is not nearly as strong as "MUST NOT", which is what I take
> deprecation to mean. Am I wrong about the intended meaning of
> "deprecation"?
That's my understanding as well.
> On Mar 9, 2021, at 1:04 PM, Viktor Dukhovni wrote:
>
> On Tue, Mar 09, 2021 at 11:29:40AM -0800, Carrick Bart
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
> > wi
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 time
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 depr
> 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 09
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 de
>>> 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 it'
On Mon, Mar 08, 2021 at 10:25:29PM -0800, Rob Sayre wrote:
> On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> >
> > Viktor Dukhovni wrote:
> > >In practice security improves more when you raise the ceiling, rather the
> > >floor.
> >
> > Let’s start with mandating support of
> > TLS_ECDHE_RS
On Mon, Mar 8, 2021 at 10:16 PM John Mattsson wrote:
> Brian Smith wrote:
> >Deprecating FFDHE key exchange without deprecating RSA key exchange will
> substantially increase the usage >of RSA key exchange and thus make server
> key compromise more dangerous. At a minimum, RSA key >exchange shoul
2021 at 01:13
To: Martin Thomson
Cc: "TLS@ietf.org"
Subject: Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe
It is sad that nobody is willing to discuss the obvious downsides of this
proposal as written, which should at least be mentioned in the security
considerations. With
On Mon, Mar 08, 2021 at 07:08:31PM -0800, Carrick Bartle wrote:
> > 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.
Is there a credible active MiTM attack t
Brian Smith writes:
>It would be useful for the browser vendors that recently dropped FFDHE
>support to share their measurements for how much RSA key exchange usage
>increased after their changes. That would help us quantify the real-world
>impact of this change.
... in mice.
Peter.
_
David Benjamin writes:
>[*] From the conclusion of the paper: "The most straightforward mitigation
>against the attack is to remove support for TLS-DH(E) entirely, as most major
>client implementations have already stopped supporting them"
Just as you need to automatically add "in mice" to the e
> I think the blanket prohibition of reuse of ECDHE keys is maybe not really
> justified.
Why is that?
> IMO that's the part that should have deprecation of RSA cipher suites done at
> the same time.
RSA seems to me to be too off-topic for this draft. (It also seems to me that
RSA is still to
Brian Smith wrote:
> It is sad that nobody is willing to discuss the obvious downsides of this
> proposal as written, which should at least be mentioned in the security
> considerations. Without discussing the downsides we're reducing engineering
> to politics. If we discuss the downsides then we
It is sad that nobody is willing to discuss the obvious downsides of this
proposal as written, which should at least be mentioned in the security
considerations. Without discussing the downsides we're reducing engineering
to politics. If we discuss the downsides then we can substantially improve
th
Great, sounds good to me then.
> On Mar 8, 2021, at 11:24 AM, David Benjamin wrote:
>
> I guess it's a question of what the goal of this draft is. I don't
> particularly care as long as it's self-consistent. :-)
>
> We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*,
> TLS
I guess it's a question of what the goal of this draft is. I don't
particularly care as long as it's self-consistent. :-)
We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*,
TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E).
We've got the contents, which ar
I'm not opposed to expanding the scope of this document to include deprecating
DHE. Is there a major advantage to that being its own draft?
> On Mar 8, 2021, at 10:09 AM, Martin Thomson wrote:
>
> One thing at a time?
>
> On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
>> I'd suggest we
On Mon, Mar 08, 2021 at 10:52:15AM -0800, Carrick Bartle wrote:
> If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a
> draft, I'll remove all mention of 1.0/1.1.
I expect it to become an RFC this week.
-Ben
___
TLS mailing list
8 March 2021 at 16:34
> To: "TLS@ietf.org"
> Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe
>
> Well overdue. We should do this.
>
> The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the
> document content. I only
One thing at a time?
On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
>
> - The construction is broken. The leak itself in the Raccoon attack
> comes from TLS 1.2 removing leading zeros. We can't change the meaning
> of
I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
- The construction is broken. The leak itself in the Raccoon attack comes
from TLS 1.2 removing leading zeros. We can't change the meaning of the
existing code points, so any fix there would involve dropping them.
- It lacks gr
Agreed. I'll change the title to reflect that.
> On Mar 8, 2021, at 7:33 AM, Martin Thomson wrote:
>
> Well overdue. We should do this.
>
> The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the
> document content. I only see static or semi-static DH and ECDH key excha
Thomson
Date: Monday, 8 March 2021 at 16:34
To: "TLS@ietf.org"
Subject: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe
Well overdue. We should do this.
The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the
document content. I only see sta
Well overdue. We should do this.
The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match the
document content. I only see static or semi-static DH and ECDH key exchange
being deprecated (in the document as non-ephemeral).
___
TLS m
26 matches
Mail list logo
