Mike,
The server receives a ClientHello from a prospective client. In the case of
DTLS and QUIC, this path has not yet been validated, so the server may want
to verify the remote address prior to continuing the handshake. This is
incredibly important as generating key_shares and signing the transc
On 10/3/20 16:12, Nick Lamb wrote:
You can't possibly implement [stateless HelloRetryRequest] the
way the spec suggests with just a hash in a HRR cookie extension.
Lots of people have and it works just fine, so it seems to me that "You
can't possibly" here means something closer to "I still don'
On Fri, 02 Oct 2020 14:15:48 -0400
"Michael D'Errico" wrote:
> > > You can't possibly implement [stateless HelloRetryRequest] the
> > > way the spec suggests with just a hash in a HRR cookie extension.
Lots of people have and it works just fine, so it seems to me that "You
can't possibly" here m
On 10/2/20 22:13, I wrote:
Please don't tell me all the current TLS 1.3 implementations
forgot to include the HelloRetryRequest in the transcript hash.
Is this the reason why Microsoft ditched Edge and rebuilt on
top of Chrome? There must have been a bug bounty for this.
Are there still bug bo
On 10/2/20 14:15, I wrote:
The server also needs to know the entire HelloRetryRequest message
since this goes into the Transcript Hash calculation:
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash ||/* Handshake type */
00 00 Hash.length
> > You can't possibly implement [stateless HelloRetryRequest] the
> > way the spec suggests with just a hash in a HRR cookie extension.
>
> The only thing the server needs to know is the hash of the ClientHello
> (so it can restore the transcript hash) and that the server has already
> sent a
On Thu, Oct 1, 2020 at 7:05 AM Michael D'Errico wrote:
> > I am having a difficult time understanding the tradeoffs you're facing.
>
> This is the first time I'm reading the TLS 1.3 RFC. I have
> implemented SSLv3, TLS 1.0, 1.1, and 1.2. You may have
> used my test server at https www dot mikes
> I am having a difficult time understanding the tradeoffs you're facing.
This is the first time I'm reading the TLS 1.3 RFC. I have
implemented SSLv3, TLS 1.0, 1.1, and 1.2. You may have
used my test server at https www dot mikestoolbox dot
org or dot net to test your own code. It's kind of ol
> Not always; see TCP "fast open" options.
>Maybe this should be disabled? Fortunately if you wanted
to there is a setsockopt for TCP_FASTOPEN.
Yeah, that will go over great for the folks who want to DDoS you. :)
___
TLS mailing list
TLS@
On Wed, Sep 30, 2020 at 8:35 PM Michael D'Errico
wrote:
> > Not always; see TCP "fast open" options.
>
> Maybe this should be disabled? Fortunately if you wanted
> to there is a setsockopt for TCP_FASTOPEN.
>
I am having a difficult time understanding the tradeoffs you're facing.
What software
> Not always; see TCP "fast open" options.
Maybe this should be disabled? Fortunately if you wanted
to there is a setsockopt for TCP_FASTOPEN.
Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Mike,
On Wed, Sep 30, 2020 at 01:20:59PM -0400, Michael D'Errico wrote:
> > The costs you describe are trivial.
>
> The general idea among developers these days that CPU
> cycles are free is a huge problem.
>
> You didn't answer my biggest question, though, which was
> whether you (or anybody
>This makes sense since DTLS is over UDP, but TLS
is over TCP, so it's already undergone the SYN/ACK
handshake to establish there's an actual peer with
a reachable address.
Not always; see TCP "fast open" options.
___
TLS mailing list
DTLS 1.3 can be found here:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-38
Thank you.
The HRR is used in DTLS 1.3 for DDoS prevention.
This makes sense since DTLS is over UDP, but TLS
is over TCP, so it's already undergone the SYN/ACK
handshake to establish there's an actual peer wit
t: Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3
Problem?)
> The costs you describe are trivial.
The general idea among developers these days that CPU cycles are free is a huge
problem.
You didn't answer my biggest question, though, which was whether you (or
anybo
> The costs you describe are trivial.
The general idea among developers these days that CPU
cycles are free is a huge problem.
You didn't answer my biggest question, though, which was
whether you (or anybody else!) has had success using stateless
HelloRetryRequest to increase the number of conne
On Wed, Sep 30, 2020 at 10:17:53PM +1000, Martin Thomson wrote:
> The costs you describe are trivial. And we limit replay with a binding
> to remote address, and a short timer. But the benefit is mostly down
> to reduced code variations. We also implement DTLS where this is
> properly useful.
You
The costs you describe are trivial. And we limit replay with a binding to
remote address, and a short timer. But the benefit is mostly down to reduced
code variations. We also implement DTLS where this is properly useful.
On Wed, Sep 30, 2020, at 15:11, Michael D'Errico wrote:
> [I'm resending
[I'm resending this with a more appropriate Subject line. --Mike]
On 9/29/20 19:51, Martin Thomson wrote:
> It's symmetric crypto[1]. Hardly worth noting.
> [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that
> server clusters can share session ticket encryption keys without n
19 matches
Mail list logo
