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 some
On 12/07/2023 19:23, Kampanakis, Panos wrote:
One more argument for making pass 2 optional or allowing for just pass 1
dictionaries is that if we are not talking about WebPKI we don't have the
luxury of CT logs. But we would still want to option of compressing / omitting
the ICAs by using CCA
On 13/07/2023 10:13, Rob Stradling wrote:
How about also including in the shared dictionary the SHA-256 hashes
of the public keys of all the known CTv1 logs, so that the 32-byte
LogID field of each SCT will be compressed?
This is already step 2 of the shared dictionary construction :-) (link
On 13/07/2023 02:31, Kampanakis, Panos wrote:
Btw, in 3.1.1 I noticed
- "Remove all intermediate certificates which are not signed by root certificates
still in the listing."
That could eliminate some 2+ ICA cert chains. Any reason why?
Whoops, that's a good spot. The intent here was just to r
Hi Dennis. I did read section 3.2.1 of the draft before posting, but I got the
impression that the lexicographically ordered list of log identifiers produced
in the "Secondly" step was only intended to be used as a reference in the
"Finally" step, rather than emitted as "output".
I understand
Yes to Viktor's and Peter's comments.
I can't understand fanaticism expressed in this "deprecate..." attempt.
Besides, it is simply unwise.
--
V/R,
Uri
There are two ways to design a system. One is to make it so simple there are
obviously no deficiencies.
The other is to make it so complex
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 wholes
> 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 se
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
> - 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 str
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
bec
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
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.
Interesting,
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
uses
Hubert,
I’m aware of at least one company (using the term loosely) that uses custom
group, and probably understands FFDH(E) better than you or me. Since they had
their reasons for choosing custom, “can change … to use well-known groups”
(obviously) does not apply.
Regards,
Uri
> On Jul 14, 2
Blumenthal, Uri - 0553 - MITLL writes:
>I’m aware of at least one company (using the term loosely) that uses custom
>group,
How does that work with TLS 1.3?
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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 bec
I'm not claiming that I know about all users, I can just say that of all
our
customers that do care about working in FIPS mode (which is not limited to
people that fall under US Federal regulation) none have complained
intensively
about accepting only well known groups in FIPS mode. SHA-1 depre
AFAIK, they aren’t on TLS 1.3, at least so far.
Regards,
Uri
> On Jul 14, 2023, at 12:54, Peter Gutmann wrote:
>
> !---|
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> |
19 matches
Mail list logo
