Hi Jonathan,
Am Freitag, dem 05.11.2021 um 15:34 + schrieb Jonathan Hoyland:
>
> Having now looked at SCRAM a little bit, using the TLS channel
> binding guarantees that some malicious server isn't passing the
> client's messages off to another server and performing a malicious
>
Hi all,
Both DTLS 1.2 and DTLS 1.3 mandate:
> When a DTLS implementation receives a handshake message fragment
> corresponding to the next expected handshake message sequence number, it MUST
> buffer it until it has the entire handshake message.
Can someone explain the underlying rationale?
Hi Simo,
As I said in my email to Sam, my language here was sloppy, I meant that the
channel binding is included in the key derivation process, and thus the
output keys will be related to each other.
The term channel bindings has two different meanings using in very similar
contexts, which leads
That's my inclination as well. It's an odd thing for a server to do, but it
seems fine to just retry with the new config without much fuss?
On Fri, Nov 5, 2021 at 10:18 AM Stephen Farrell
wrote:
>
> Hiya,
>
> Bit of a corner case I'm not sure about. Apologies
> if this has come up before.
>
>
Hiya,
Bit of a corner case I'm not sure about. Apologies
if this has come up before.
The scenario:
- inner SNI is inner.example
- ECHConfig from inner.example's DNS has outer.example
as public_name
- client authenticates with ClientHelloOuter and the
ServerHello contains retry_configs
hi John,
On Thu, Nov 4, 2021 at 1:11 PM John Mattsson wrote:
> TLS 1.2 has been obsolete for over three years. Oxford dictionary defines
> obsolete as "no longer produced or used; out of date." NIST requires
> support of TLS 1.3 everywhere no later than Jan 2024, which at least in
> theory
