On Fri, Jul 14, 2023 at 04:03:25PM +, Peter Gutmann wrote:
> Interesting, so you're saying that essentially no-one uses custom groups? My
> code currently fast-tracks the known groups (RFC 3526 and RFC 7919) but also
> allows custom groups (with additional checking) to be on the safe side
On Friday, 14 July 2023 18:03:25 CEST, Peter Gutmann wrote:
Hubert Kario writes:
FIPS requires to support only well known groups (all of them 2048 bit or
larger), and we've received hardly any customer issues after implementing
that as hard check (connection will fail if the key exchange
Hubert Kario writes:
>FIPS requires to support only well known groups (all of them 2048 bit or
>larger), and we've received hardly any customer issues after implementing
>that as hard check (connection will fail if the key exchange uses custom DH
>parameters) good few years ago now.
I wrote:
>Salz, Rich writes:
Argh, sorry, text-trimming fail, I was quoting Viktor Dukhovni but cut out the
wrong block of text.
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Salz, Rich writes:
>The formulation I would choose would be:
>
> - MUST prefer ECDHE key exchange, when supported, over FFDHE key exchange.
> - MUST prefer FFDHE key exchange, when supported, over RSA key exchange.
I think there should also be some wording around avoiding falling back to RSA
> - MUST prefer ECDHE key exchange, when supported, over FFDHE key exchange.
> - MUST prefer FFDHE key exchange, when supported, over RSA key exchange.
I agree with this.
> That's a reasonable position to take, but at this stage I guess the
> discussion is mostly around the presentation and
On Fri, Jul 14, 2023 at 04:53:42PM +0300, Nimrod Aviram wrote:
> There are a few valid arguments, from yourself and others here, to soften
> the prescription regarding FFDHE from MUST NOT to SHOULD NOT, or similar.
The formulation I would choose would be:
- MUST prefer ECDHE key exchange, when
> At the moment the blanket "don't do DH" is in effect saying "use RSA
keyex" to a chunk of the market.
Does the document in question say in effect "use RSA keyex"? Or could it be
read that way?
The first sentence is "This document deprecates the use of RSA key exchange
and Diffie Hellman". That
On Friday, 14 July 2023 09:01:30 CEST, Peter Gutmann wrote:
Viktor Dukhovni writes:
What benefit do we expect from forcing weaker security (RSA
key exchange or
cleartext in the case of SMTP) on the residual servers that
don't do either
TLS 1.3 or ECDHE?
This already happens a lot in
Viktor Dukhovni writes:
>What benefit do we expect from forcing weaker security (RSA key exchange or
>cleartext in the case of SMTP) on the residual servers that don't do either
>TLS 1.3 or ECDHE?
This already happens a lot in wholesale banking, the admins have dutifully
disabled DH because
On Thu, Jul 13, 2023 at 03:03:15PM +0200, Hubert Kario wrote:
> And in general, it's far better to use FFDHE kex with legacy client
> than RSA. Getting RSA right is very hard, using ephemeral secrets for
> FFDHE is trivial and recommended practice already.
Indeed, though I agree that TLS
> There are no ECDHE or FFDHE cipher suites in TLS 1.3. Cipher suites
specify
> just the bulk encryption, PRF, and integrity protection mechanism. The key
> exchange is fully controlled by .
Ah, good point :-)
Maybe go with this text instead?
In TLS 1.3 connections, clients and servers MAY offer
> My main point is say it once, not repeat it in each section.
I think that language was added for fear that readers will only glimpse the
document, and somehow conclude that RSA/FFDH is fine with TLS 1.1.
(The document is mostly aimed at late adopters of best practices anyway...)
So my
> My main point is say it once, not repeat it in each section.
I think that language was added for fear that readers will only glimpse the
document, and somehow conclude that RSA/FFDH is fine with TLS 1.1.
(The document is mostly aimed at late adopters of best practices anyway...)
So my preference
On Wednesday, 12 July 2023 19:13:02 CEST, Viktor Dukhovni wrote:
On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:
On Jul 11, 2023, at 13:52, Salz, Rich wrote:
...
This appears in s2:
Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
and TLS 1.3 does not support FFDH
>This appears in s2:
>Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
>and TLS 1.3 does not support FFDH [RFC8446].
>You’re suggesting that this be moved to s1?
My main point is say it once, not repeat it in each section.
> If that’s the case then maybe make Appendix B normative (and
On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:
> > On Jul 11, 2023, at 13:52, Salz, Rich wrote:
> >
> >> This email starts the working group last call for "Deprecating Obsolete
> >> Key Exchange Methods in TLS 1.2” I-D, located here:
> >
> >> .
> On Jul 11, 2023, at 13:52, Salz, Rich wrote:
>
>> This email starts the working group last call for "Deprecating Obsolete Key
>> Exchange Methods in TLS 1.2” I-D, located here:
>
>> . https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
>
> Three minor issues and a
> This email starts the working group last call for "Deprecating Obsolete Key
> Exchange Methods in TLS 1.2” I-D, located here:
>. https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
Three minor issues and a question.
Consider saying once, early.in the document, that this
This email starts the working group last call for "Deprecating Obsolete Key
Exchange Methods in TLS 1.2” I-D, located here:
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/
The WG Last Call will end 25 July 2023 @ 2359 UTC.
Please review the I-D and submit i
20 matches
Mail list logo
