Hi,
I found a weird packet capture of DHE key exchange.
C --> S
TLSv1.2
cipher suite used: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
ServerKeyExchange message is sending:
p length: 257 whereas pubkey length is: 256
256 means 256*8 = 2048 bit DHE key size.
I am assuming, generally when usin
Hello Rory,
Sorry for not answering earlier. Many thanks for your detailed response.
One main additional comment inline below, about the utility and
frequency of new versions.
On 2023-10-06 01:34, Rory Hewitt wrote:
Hey Martin,
Some ordered response which roughly match up to your comments,
On Mon, Oct 16, 2023 at 5:52 PM Andrei Popov
wrote:
>
>- But how are you going to detect whether there's a crappy TCP/IP
>stack or an attack? You can't.
>
> Understood. This is a general problem with insecure client-side fallbacks.
>
Sure, but I think the aim is to say that the server do
* But how are you going to detect whether there's a crappy TCP/IP stack or
an attack? You can't.
Understood. This is a general problem with insecure client-side fallbacks.
It is unclear what this draft is trying to achieve:
* Is this draft paving the way for TLS clients to advertise PQC
On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov
wrote:
>
>- Where these interpretations conflict, the selection may be
>downgraded, potentially even under attacker influence.
>
> Downgrade by attacker is only possible if the client attempts insecure
> fallback (e.g., offer PQ key share, conn
* Where these interpretations conflict, the selection may be downgraded,
potentially even under attacker influence.
Downgrade by attacker is only possible if the client attempts insecure fallback
(e.g., offer PQ key share, connection failed, retry without PQ key share)?
Or am I missing some o
On Mon, Oct 16, 2023 at 9:18 AM David Benjamin
wrote:
> I've thus rephrased it in terms of just one group, which I think is much
> tidier. How does this look to you?
>
> https://github.com/davidben/tls-key-share-prediction/commit/310fa7bbddd1fe0c81e3a6865a59880efc901b33
>
I agree with the senti
Hi TLS Team,
Do you have any update that TLS 1.2 is getting expired or any EOL announcement
we have? I see document RFC 5246 (Snap attached) where you mention obsoleted by
RFC 8446?
I need update that according to your RFC draft TLS 1.2
(draft-rsalz-tls-tls12-frozen) is frozen (Already clarify
On Fri, Oct 13, 2023 at 1:29 AM Rob Sayre wrote:
> On Wed, Oct 11, 2023 at 8:43 AM David Benjamin
> wrote:
>
>> Tossed onto GitHub and removed the discussion of authenticated records
>> in
>> https://github.com/davidben/tls-key-share-prediction/commit/cabd76f7b320ab4f970f396db3d962ca9f510875
>>
