> Authors, can you please update the document (and fix the clarification
that Ekr recently raised) at your convenience?
Sure, I'll start working on it.
best,
Nimrod
On Fri, 10 Mar 2023 at 03:35, Christopher Wood wrote:
> First, let us apologize for taking so long to conclude this consensus
>
First, let us apologize for taking so long to conclude this consensus call. We
should have closed this much sooner.
After reviewing the responses on the mailing list, and taking into
consideration discussions that took place during meetings, it is our assessment
that there is rough consensus
Hubert Kario writes:
>Because there are software stacks that allow configuration of arbitrary
>parameters for FFDH (see GnuTLS, OpenSSL), and there are software stacks that
>generate one public key share and reuse it for a long time, or allow
>configuration of this kind of behaviour (see old
On Tuesday, 3 January 2023 11:33:39 CET, Peter Gutmann wrote:
Hubert Kario writes:
It's also easy and quick to verify that the server *is* behaving correctly
and thus is not exploitable.
It's also a somewhat silly issue to raise, if we're worried about a server
using deliberately broken
Hubert Kario writes:
>It's also easy and quick to verify that the server *is* behaving correctly
>and thus is not exploitable.
It's also a somewhat silly issue to raise, if we're worried about a server
using deliberately broken FFDHE parameters then why aren't we worried about
the server
On 14/12/2022 04:08, Peter Gutmann wrote:
Blumenthal, Uri - 0553 - MITLL writes:
I do not support deprecation, because there will be deployed devices (IoT,
SCADA) that aren’t upgradable – and the new stuff will have to access them.
It's actually much worse than just SCADA, there are
On 02/01/2023 13:55, Hubert Kario wrote:
On Saturday, 24 December 2022 02:10:08 CET, Rob Sayre wrote:
Maybe it would help if the chairs could clarify the difference between
"deprecated" and "prohibited" / "forbidden".
I think these words have straightforward definitions, and I find many
On Mon, Jan 2, 2023 at 5:55 AM Hubert Kario wrote:
>
> The problem is not the language, but how the word "deprecated" is used by
> different regulatory bodies.
>
I'm not sure what you're referring to, or why they wouldn't understand
the definition of the word, but maybe a longer explanation
On Monday, 2 January 2023 17:32:26 CET, Nimrod Aviram wrote:
It's also easy and quick to verify that the server *is*
behaving correctly and thus is not exploitable.
Could you please help me understand how you propose to verify this?
For example, assuming an SMTP server that presents a
On Mon, Jan 02, 2023 at 06:32:26PM +0200, Nimrod Aviram wrote:
> (To concede a point in advance: It is obviously possible to _assume_ that
> if the server presents a modulus, then it "must" be a safe prime, or it
> meets some desired security notion that the server operator has deemed
>
> It's also easy and quick to verify that the server *is* behaving
correctly and thus is not exploitable.
Could you please help me understand how you propose to verify this?
For example, assuming an SMTP server that presents a (presumably)
custom-generated safe prime.
My understanding is that this
On Saturday, 24 December 2022 02:10:08 CET, Rob Sayre wrote:
Maybe it would help if the chairs could clarify the difference
between "deprecated" and "prohibited" / "forbidden".
I think these words have straightforward definitions, and I
find many responses to be disrespectful in insisting
On Thursday, 22 December 2022 23:26:26 CET, Carrick Bartle wrote:
the latter is basically unexploitable with properly behaving
hosts in TLSv1.2
Well, right, that's the trick. The issue that people have
pointed out with FFDHE is that it's very easy to have a host
that is not properly behaving
Maybe it would help if the chairs could clarify the difference between
"deprecated" and "prohibited" / "forbidden".
I think these words have straightforward definitions, and I find many
responses to be disrespectful in insisting that "deprecated" means
something it does not. But maybe this is an
> Telling people that they shouldn't use the only things they can use means
that the advice is unactionable, thus will be ignored.
Yep, that's precisely what people are suggesting. If someone has a legacy
system that cannot be upgraded, or they need to interface with such
systems, they can ignore
> the latter is basically unexploitable with properly behaving hosts in
TLSv1.2
Well, right, that's the trick. The issue that people have pointed out with
FFDHE is that it's very easy to have a host that is not properly behaving
(see RFC 7919, which is referenced in our draft).
On Wed, Dec
On Thu, Dec 22, 2022 at 6:10 AM Hubert Kario wrote:
> On Wednesday, 21 December 2022 19:13:36 CET, Rob Sayre wrote:
> > On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario wrote:
> >
> > Telling people that they shouldn't use the only things they can use
> means...
> >
> > Well, I'd be curious to know
100% support the BCP route.
--
V/R,
Uri
On 12/22/22, 10:16, "TLS on behalf of Peter Gutmann" wrote:
Hal Murray writes:
>Would a BCP be a better approach? That might provide a good setting to
>discuss the issues. There is no reason to limit a BCP to TLSv1.2 or FFDHE.
Hal Murray writes:
>Would a BCP be a better approach? That might provide a good setting to
>discuss the issues. There is no reason to limit a BCP to TLSv1.2 or FFDHE.
That seems like a much better idea. A deprecate RFC can only say "no" while a
BCP can cover alternatives, in this situation
> What I'm against is blanket forbidding of FFDHE in TLSv1.2.
The subject says "deprecate". That seems to have caused much of the
discussion.
Would a BCP be a better approach? That might provide a good setting to
discuss the issues. There is no reason to limit a BCP to TLSv1.2 or FFDHE.
On Wednesday, 21 December 2022 19:13:36 CET, Rob Sayre wrote:
On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario wrote:
Telling people that they shouldn't use the only things they can use means...
Well, I'd be curious to know what the use cases are.
The stuff Uri Blumenthal already mentioned:
On Thu, Dec 22, 2022 at 05:56:50AM +, Peter Gutmann wrote:
> John Mattsson writes:
>
> >A more reasonable approach would be to deprecate all cipher suites without
> >_ECDHE_.
> >
> >While the WG is in deprecation mode, please deprecate all non-AEAD cipher
> >suites as well. RFC 7540 did
John Mattsson writes:
>A more reasonable approach would be to deprecate all cipher suites without
>_ECDHE_.
>
>While the WG is in deprecation mode, please deprecate all non-AEAD cipher
>suites as well. RFC 7540 did this 7.5 years ago...
An even more reasonable approach would be to mandate EMS,
Sounds good, thanks!
On Mon, Dec 19, 2022 at 3:46 PM Rob Sayre wrote:
> On Mon, Dec 19, 2022 at 2:52 PM Martin Thomson wrote:
>
>> On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote:
>> >> You might need to clarify that TLS 1.1 and earlier are wholly
>> deprecated though, just to be sure.
>>
On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario wrote:
>
> Telling people that they shouldn't use the only things they can use
> means...
>
Well, I'd be curious to know what the use cases are. But I would also say
this might be enough:
devices
are labeled depracated.
Cheers,
John
From: TLS on behalf of Hubert Kario
Date: Wednesday, 21 December 2022 at 14:59
To: Martin Thomson
Cc: tls@ietf.org
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote
On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote:
On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
use of FFDHE with large key sizes is the best protection against
store-and-decrypt-later attacks
This doesn't deprecate use of FFDHE in TLS 1.3, for which we
have some
On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:
On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario wrote:
Thus the deprecation of it is a matter of taste, not
cryptographic
necessity.
I'm sorry if I'm being dense here, but isn't all of this a
SHOULD NOT in RFC 9325?
On Tue, Dec 20, 2022 at 2:56 PM Martin Thomson wrote:
> On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
> > use of FFDHE with large key sizes is the best protection against
> > store-and-decrypt-later attacks
>
> This doesn't deprecate use of FFDHE in TLS 1.3, for which we have some
>
On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
> use of FFDHE with large key sizes is the best protection against
> store-and-decrypt-later attacks
This doesn't deprecate use of FFDHE in TLS 1.3, for which we have some
ludicrously large named groups. Is that not enough?
> If anything,
On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario wrote:
> Thus the deprecation of it is a matter of taste, not
> cryptographic
> necessity.
>
I'm sorry if I'm being dense here, but isn't all of this a SHOULD NOT in
RFC 9325?
I oppose deprecation.
Given that we're still a ways off from standardised post-quantum key
exchanges,
use of FFDHE with large key sizes is the best protection against
store-and-decrypt-later attacks (buying likely years of additional
protection)
I think the deprecation is premature.
While
On Mon, Dec 19, 2022 at 2:52 PM Martin Thomson wrote:
> On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote:
> >> You might need to clarify that TLS 1.1 and earlier are wholly
> deprecated though, just to be sure.
> >
> > We do mention that in the body of the document. Are you suggesting that
>
On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote:
>> You might need to clarify that TLS 1.1 and earlier are wholly deprecated
>> though, just to be sure.
>
> We do mention that in the body of the document. Are you suggesting that
> we also add that to the abstract and intro?
Oh yeah, three
> You might need to clarify that TLS 1.1 and earlier are wholly deprecated
though, just to be sure.
We do mention that in the body of the document. Are you suggesting that we
also add that to the abstract and intro?
On Sun, Dec 18, 2022 at 2:55 AM Martin Thomson wrote:
> On Sun, Dec 18, 2022,
15
> *To: *David Benjamin
> *Cc: *TLS List
> *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites
>
>
>
> Hi David,
>
>
>
> My understanding is that we're only discussing deprecating DHE for 1.2.
> 1.3 is out of scope for this document.
>
>
>
&
On Sun, Dec 18, 2022, at 04:33, Yaron Sheffer wrote:
> Yes, this is clear to people on this thread. My comment was just about
> the document, which IMO should define its scope more clearly and early
> on.
The title and abstract and introduction could say "TLS 1.2" and the document
would be
List
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
It is, however, mentioned throughout the actual text of the document, assuming
we're both looking at draft-ietf-tls-deprecate-obsolete-kex-01. I think the
document describes its current change just fine. I asked only
artle <
> cbartle...@gmail.com>
> *Date: *Thursday, 15 December 2022 at 20:15
> *To: *David Benjamin
> *Cc: *TLS List
> *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites
>
>
>
> Hi David,
>
>
>
> My understanding is that we'r
on behalf of Carrick Bartle
Date: Thursday, 15 December 2022 at 20:15
To: David Benjamin
Cc: TLS List
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
Hi David,
My understanding is that we're only discussing deprecating DHE for 1.2. 1.3 is
out of scope
I'm not sure such an implicit approach best serves everyone's interests...
Vendors would be better served if we explicit communicate expected
timelines for deprecation, and expected timelines where maintaining support
is a "must"/MUST/SHOULD.
And this WG would be better served if we have
On Tue, Dec 13, 2022 at 09:46:29AM -0500, Sean Turner wrote:
> This message starts the process to judge whether there is consensus to
> deprecate all FFDHE cipher suites including those well-known groups.
> Please indicate whether you do or do not support deprecation of FFDHE
> cipher suites by
On Fri, Dec 16, 2022 at 3:22 AM Peter Gutmann
wrote:
> Saying
> "lalalalala I'm not listening, I'm not listening" won't deal with the fact
> that there's a staggering amount of gear out there with product lifecycles
> sometimes measured in decades that needs a sound basis for making decisions
>
The fact that there are long product lifecycles makes the case for
deprecation rather than against it. Imagine that we do not deprecate DHE.
That means that next year, someone will be fully within the standard to
create a long-lived product that uses DHE with TLS 1.2 and nothing more
secure than
There have been attempts in the past to signal this to product planners:
SHOULD+This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at
some future time to be a MUST.
SHOULD-This term means the
> There needs to be some plan with a schedule that gives downstream users
time to get their act in gear.
I agree. And the schedule should also allow for deprecation in a reasonable
timeline.
> Should there be an IETF group to help coordinate things like this?
I think it'd be better if each group
Rob Sayre writes:
>For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
>endlessly keeping old cipher suites alive. The unwise cost-cutting in those
>areas does not constrain the rest of the internet.
And for my part I'm... well not really sick of but resigned to accepting the
On Fri, Dec 16, 2022, 11:41 Hal Murray wrote:
>
> say...@gmail.com said:
> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> > endlessly keeping old cipher suites alive. The unwise cost-cutting in
> those
> > areas does not constrain the rest of the internet.
>
> Agreeded,
say...@gmail.com said:
> For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> endlessly keeping old cipher suites alive. The unwise cost-cutting in those
> areas does not constrain the rest of the internet.
Agreeded, but the software maintainers can't just drop support for X
On Thu, Dec 15, 2022 at 4:27 PM Peter Gutmann
wrote:
>
> It seems the only real reason for deprecating DHE is that it's not
> fashionable.
This kind of discourse isn't cool. If there are good ways to show that
FFDHE cipher suites are ok, let's document them.
> And as my earlier message
> without further guidance they've chosen to go with literally the worst
possible option instead of the perfectly-OK one.
You are more than welcome to draft a document stating that, given two
deprecated options, which is preferable.
> It seems the only real reason for deprecating DHE is that it's
Carrick Bartle writes:
>In the situation you've described, they've been told they shouldn't use RSA
>either, so clearly it doesn't matter to them what we've deprecated or not.
Yup, because if you give people the choice between not A but not B either then
they have to ignore one of the two, and
In the situation you've described, they've been told they shouldn't use RSA
either, so clearly it doesn't matter to them what we've deprecated or not.
We should deprecate insecure algorithms; the fact that there's a spectrum
of insecurity among deprecated algorithms does not detract from the fact
> Wouldn’t be the first case an RFC gets misinterpreted.
I don't think the IETF's decisions should be dictated by the risk that
someone might potentially misread their documents. That's always a risk.
Someone might misread RFC 8446 as saying "use SSL 3.0 only." Does that mean
the IETF shouldn't
not support deprecation, because there will be deployed devices (IoT,
> SCADA) that aren’t upgradable – and the new stuff will have to access them.
>
>
>
> I’ll spare the group my personal opinion about this draft.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
>
Hi David,
My understanding is that we're only discussing deprecating DHE for 1.2. 1.3
is out of scope for this document.
Carrick
On Tue, Dec 13, 2022 at 10:06 AM David Benjamin
wrote:
> Small clarification question: is this about just FFDHE in TLS 1.2, i.e.
> the TLS_DHE_* cipher suites, or
True - but, unfortunately, quite a few readers misunderstand that and use depreciation as an excuse to remove support of deprecated algorithms and protocols. Wouldn’t be the first case an RFC gets misinterpreted. Regards,UriOn Dec 14, 2022, at 02:30, Rob Sayre wrote:On Tue, Dec 13, 2022 at 8:14
On Tue, Dec 13, 2022 at 03:51:33PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I do not support deprecation, because there will be deployed devices
> (IoT, SCADA) that aren’t upgradable – and the new stuff will have to
> access them.
Any stuff that needs to access such devices already has to
Nimrod Aviram writes:
>Let me clarify that the document also has RSA as a MUST NOT.
>
>So there will be no reason to read this document and switch from FFDHE to
>RSA.
If you tell people they can't have A but they can't have B either then they're
going to have to choose one of the two in order
Let me clarify that the document also has RSA as a MUST NOT.
So there will be no reason to read this document and switch from FFDHE to
RSA.
On Wed, 14 Dec 2022 at 06:09, Peter Gutmann
wrote:
> Blumenthal, Uri - 0553 - MITLL writes:
>
> >I do not support deprecation, because there will be
On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:\
>
>
> I think I’ve made my point already – there are devices that use FFDHE,
> which remain secure (so far), and may require access by new .
> Thus, an RFC that would prohibit it, sounds, as you said
o: Sean Turner , Ira McDonald
Cc: TLS List
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
Hi,
Yes - I support deprecating all FFDHE cipher suites including well-known groups.
Cheers,
- Ira
On Tue, Dec 13, 2022 at 9:46 AM Sean Turner wrote:
During the
Blumenthal, Uri - 0553 - MITLL writes:
>I do not support deprecation, because there will be deployed devices (IoT,
>SCADA) that aren’t upgradable – and the new stuff will have to access them.
It's actually much worse than just SCADA, there are deployments in things like
wholesale banking where
ll spare the group my personal opinion about this draft.
>
> --
>
> V/R,
>
> Uri
>
>
>
>
>
> *From: *TLS on behalf of Ira McDonald <
> blueroofmu...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 10:47
> *To: *Sean Turner , Ira McDonald
> *Cc:
: deprecate all FFDHE cipher suites
Hi,
Yes - I support deprecating all FFDHE cipher suites including well-known groups.
Cheers,
- Ira
On Tue, Dec 13, 2022 at 9:46 AM Sean Turner wrote:
During the tls@IETF 115 session topic covering
draft-ietd-tls-deprecate-obsolete-kex, the sense
;
>
>
>
> *From: *TLS on behalf of Ira McDonald <
> blueroofmu...@gmail.com>
> *Date: *Tuesday, December 13, 2022 at 10:47
> *To: *Sean Turner , Ira McDonald
> *Cc: *TLS List
> *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites
>
>
&
Small clarification question: is this about just FFDHE in TLS 1.2, i.e. the
TLS_DHE_* cipher suites, or also the ffdhe* NamedGroup values as used in
TLS 1.3?
I support deprecating the TLS_DHE_* ciphers in TLS 1.2. Indeed, we removed
them from Chrome back in 2016
I support deprecating all of them. My reason is not because I think there are
known weaknesses, but because we can remove code.
There are apparently devices that cannot be updated to do this and that's okay.
There are apparently devices that could not be upgraded to support TLS 1.3 and
we
I support.
On Tue, Dec 13, 2022, 18:47 Sean Turner wrote:
> During the tls@IETF 115 session topic covering
> draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there
> was support to deprecate all FFDHE cipher suites including well-known
> groups. This message starts the
, December 13, 2022 at 10:47
To: Sean Turner , Ira McDonald
Cc: TLS List
Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites
Hi,
Yes - I support deprecating all FFDHE cipher suites including well-known groups.
Cheers,
- Ira
On Tue, Dec 13, 2022 at 9:46 AM Sean Turner
Hi,
Yes - I support deprecating all FFDHE cipher suites including well-known
groups.
Cheers,
- Ira
On Tue, Dec 13, 2022 at 9:46 AM Sean Turner wrote:
> During the tls@IETF 115 session topic covering
> draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there
> was support
71 matches
Mail list logo
