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
On Mon, Sep 28, 2020 at 12:55 PM Stephen Farrell
wrote:
>
> 3. (This isn't new, but no harm repeating:-) I don't
> plan to adhere to the MUST send the public_name
>
I should also add I don't care about this requirement, and it is
unenforceable anyway.
thanks,
Rob
> 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
On Wed, Sep 30, 2020 at 8:12 AM Salz, Rich wrote:
> PSK is in the RFC. And in fact we made a point of unifying it and other
> mechanisms in the protocol.
>
I don't really feel strongly about it (because it doesn't matter to me),
but it could be taken out of the 8446-bis document.
I might also
On 9/30/20 17:34, Benjamin Kaduk wrote:
The HRR is presumed to be a deterministic function of the
initial ClientHello, and as I discussed in my earlier message,
the server can reconstruct the initial ClientHello from the
second ClientHello and verify it against the hash in the cookie.
I don't
On Wed, Sep 30, 2020 at 05:24:21PM -0400, Michael D'Errico wrote:
> I wrote:
>
> > Also the server can't be actually stateless since
> > it needs to know the HelloRetryRequest message
> > for the transcript hash, right?
>
> How can you even implement stateless HRR with a
> pseudo-session-ticket
I wrote:
> Also the server can't be actually stateless since
> it needs to know the HelloRetryRequest message
> for the transcript hash, right?
How can you even implement stateless HRR with a
pseudo-session-ticket in the "cookie"? The server
needs to know the full HRR message to calculate the
Anyway, back on the topic of stateless HelloRetryRequest, I
don't see how this can work given that the client can make
several modifications to the ClientHello which will invalidate
the hash sent in the "cookie" (even if the client echos it back
as required without modification).
The hash
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
Mike,
DTLS 1.3 can be found here:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-38
The HRR is used in DTLS 1.3 for DDoS prevention.
Ciao
Hannes
-Original Message-
From: TLS On Behalf Of Michael D'Errico
Sent: Wednesday, September 30, 2020 7:21 PM
To: tls@ietf.org
Subject: Re:
> 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
PSK is in the RFC. And in fact we made a point of unifying it and other
mechanisms in the protocol.
If someone wants to say PSK isn't recommended, then they need to do the work to
get an RFC published that says so.
___
TLS mailing list
TLS@ietf.org
> On Sep 30, 2020, at 08:51, Watson Ladd wrote:
>
> Recommended N doesn't stop people from using PSK when appropriate if
> other constraints make it the most appropriate choice.
It does, because this "stop" occurs on a business level, not the technical...
Realm of advertisement, claimed
On Wed, Sep 30, 2020 at 3:32 AM Hannes Tschofenig
wrote:
>
> Hi Watson,
>
> through Arm I deal with customers who use microcontrollers that have all
> sorts of limitations. So, the question is not so much whether these
> limitations exist but rather whether you care and what exactly these
>
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
Hi Rob,
From the email Watson sent I got the impression that he does not believe there
are CPU performance constrained devices.
Since I work in that industry I shared my experience.
I am uncertain how changing the name help us solve such an underlying problem.
Maybe it was meant to be a joke.
For me this seems to be a philosophic dispute about the
"philosopher's stone".
So, not too serious:
Great idea!
just add the number of the year to the term TLS for the main stream!
And leave the term TLS without the year numbers to those, who want to
use recommended stuff from last year also
On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:
> Hi Watson,
>
> through Arm I deal with customers who use microcontrollers that have all
> sorts of limitations.
>
One way to solve this is to name it something other than "TLS", even if it
shares some code
Hi Uri,
I would even argue that key management is less challenging for IoT deployments
because devices typically talk to a single device management server only.
So, the communication patterns are pretty simplistic compared to a generic
computing device.
RFC 7452 talks about this topic (see the
Hi Watson,
through Arm I deal with customers who use microcontrollers that have all sorts
of limitations. So, the question is not so much whether these limitations exist
but rather whether you care and what exactly these limitations are (CPU
processing, RAM, flash memory, energy, networking
20 matches
Mail list logo
