On 23/11/16 08:50, Yoav Nir wrote:
> As long as you run over a network that has a smallish MTU, you’re going to
> incur the packetization costs anyway, either in your code or in operating
> system code. If you have a 1.44 GB file you want to send, it’s going to take
> a million IP packets
On 23/11/16 19:13, Watson Ladd wrote:
> On Nov 23, 2016 10:22 AM, "Jeremy Harris" <j...@wizmail.org> wrote:
>>
>> On 23/11/16 08:50, Yoav Nir wrote:
>>> As long as you run over a network that has a smallish MTU, you’re going
> to incur the pack
On 07/09/2018 05:40 PM, Kathleen Moriarty wrote:
> Stephen and I posted the draft below to see if the TLS working group
> is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has
> been a recent drop off in usage for web applications due to the PCI
> Council recommendation to move off
On 05/04/2019 11:03, internet-dra...@ietf.org wrote:
>In TLS handshakes, certificate chains often take up the majority of
>the bytes transmitted.
>
>This document describes how certificate chains can be compressed to
>reduce the amount of data transmitted and avoid some round
On 30/09/2019 14:36, Christopher Wood wrote:
> On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
>> Clients must therefore
>> bound the number of parallel connections they initiate by the
>> number of tickets in their possession, or risk ticket re-use.
>> ```
>>
>> I'm not a
On 16/11/2019 11:04, Viktor Dukhovni wrote:
>> We should probably be emphasizing that *all* policy belongs on the server,
>> and
>> we are just defining a signal for the client to convey some information as
>> input
>> to the server's decision. In that mindset I'm not sure that the "subtract
On 05/03/2020 05:53, Viktor Dukhovni wrote:
> On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:
>> It's not the usecase: it's the program. Postfix made architectural
>> choices that make storing tickets allegedly expensive.
>
> These fit into a existing archicture of security-hardened
On 04/02/2020 13:56, Hubert Kario wrote:
> the thing is that getting extra ticket from the server is at most an
> inconvenience for postfix
Isn't the giving out of needless tickets a performance cost
for the server, as well as a bandwidth cost for the network?
Or are tickets zero-cost to
On 13/01/2020 17:48, internet-dra...@ietf.org wrote:
> Title : Batch Signing for TLS
> Author : David Benjamin
> Filename: draft-ietf-tls-batch-signing-00.txt
> Pages : 10
> Date: 2020-01-13
>
> Abstract:
>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 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
On 08/07/2020 16:07, Nico Williams wrote:
> On Tue, Jul 07, 2020 at 09:22:24PM -0700, Benjamin Kaduk wrote:
>> There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently
>> in IESG Evaluation):
>>
>>The protocol convention specified in the current document assumes
>>there can be
Hi,
Could people please confirm a detail of TLS 1.3 session
close behaviour? Specifically, are half-closes supported
in similar fashion to TCP half-closes - in that it is
legitimate for one end to issue a Close Notify alert
and for the other end to receive that alert but continue
to transmit
On 16/03/2021 07:53, Ben Smyth wrote:
Further, is it reasonable for the above first end to
expect the above second end to continue processing and
sending data that would have been sent in the absence of
such a first Close Alert?
The endpoint should expect their interlocutor to ignore any
On 17/03/2021 07:15, Ben Smyth wrote:
Perhaps one scenario where that
behaviour is useful: An endpoint is about to be comprimised and raises an
alert to avoid secrets being leaked.
I'd have tout that a section 6.2 Error Alert would be more
appropriate in such a situation, than the (implicitly
On 17/03/2021 14:45, Ben Smyth wrote:
Do you at least agree that Google is in violation of the 6.1
wording requiring that it sends a Close Alert before sending
a TCP FIN?
Which aspect of Section 6.1 do you think Google doesn't comply with?
"Each party MUST send a "close_notify" alert
16 matches
Mail list logo
