I also agree. Even without implicit CIDs we can still put multiple handshake
messages into a single record. Hence, there is no performance problem.
From: TLS On Behalf Of Richard Barnes
Sent: Thursday, May 28, 2020 3:37 PM
To: Christopher Wood
Cc: TLS@ietf.org
Subject: Re: [TLS] Banning implici
Thanks, all! It looks like we have consensus on #148, so I merged it. Let's
spin a new version with these changes and move forward.
Best,
Chris
On Fri, May 29, 2020, at 8:29 AM, Hannes Tschofenig wrote:
>
> I also agree. Even without implicit CIDs we can still put multiple
> handshake message
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : The Datagram Transport Layer Security (DTLS) Protocol
Version 1.3
Authors : Eric Rescorla
Hi all,
As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some
interesting interactions with TCP. We thought we’d document these and send
a note here. In general, we've found that TLS implementations need to be
wary of post-handshake messages and “unexpected” transport writes. This
On 29/05/2020 21:59, David Benjamin wrote:
> Moreover, in a client-speaks-first protocol, the error now comes after the
> client has already sent its request. This is not only a behavior change but
> makes it unreliable over TCP. TCP sees:
>
>
>1.
>
>Client: write(ClientHello);
>2.
>
On Fri, May 29, 2020 at 5:36 PM Jeremy Harris wrote:
> On 29/05/2020 21:59, David Benjamin wrote:
> > Moreover, in a client-speaks-first protocol, the error now comes after
> the
> > client has already sent its request. This is not only a behavior change
> but
> > makes it unreliable over TCP. TC
On Fri, May 29, 2020 at 5:01 PM David Benjamin wrote:
>
> Hi all,
>
>
> As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some
> interesting interactions with TCP. We thought we’d document these and send a
> note here. In general, we've found that TLS implementations need to be wa
On Fri, May 29, 2020 at 06:35:58PM -0400, Watson Ladd wrote:
> In my experience the issues are thorniest when dealing with blocking
> sockets. Libraries using nonblocking sockets have to signal to the
> application that they want IO to happen during the handshake, and can
> use that same mechanism
On 29/05/2020 22:52, David Benjamin wrote:
> On Fri, May 29, 2020 at 5:36 PM Jeremy Harris wrote:
>
>> On 29/05/2020 21:59, David Benjamin wrote:
>>> Moreover, in a client-speaks-first protocol, the error now comes after
>> the
>>> client has already sent its request. This is not only a behavior
On Fri, May 29, 2020 at 10:36:42PM +0100, Jeremy Harris wrote:
> > Note (4) and (5) happen in parallel. Ideally ??? would be a bad_certificate
> > alert, but it is sometimes a TCP reset. I’m not a TCP expert, but I believe
> > this is because the client writes data (“GET / ...”) the server never
>
10 matches
Mail list logo
