The following errata report has been submitted for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7620
--
Type: Technical
Re
Hi Ben,
Before addressing the text, let's make sure we are on the same page about
the situation.
As you probably know, there are quite a few situations in which endpoints
close the connection before
receiving a close_notify, for instance, when they receive an end of data
message in the applicatio
Yes, we agree. I anticipate necessity to reduce the strength my wording (or
to ignore). I raise this errata only to discuss specification-compliant
implementations being vulnerable to truncation attack; it'd surely be
better to have a SHOULD or SHOULD NOT.
On Mon, 28 Aug 2023, 14:43 Eric Rescorla,
So I'm not sure this is an erratum as I think it correctly describes the
situation and it's a judgement call whether we ought to have a requirement
here or whether it's a 6919 MUST (BUT WE KNOW YOU WON'T)
We are currently preparing the 8446-bis, so I think the right place to have
this discussion i
On Mon, Aug 28, 2023 at 04:02:18AM -0700, RFC Errata System wrote:
> Both parties need not wait to receive a "close_notify" alert before
> closing their read side of the connection, though doing so would
> introduce the possibility of truncation.
While the paragraph text is under the microscope,
Layering. When we review 8446, we need to consider the layering of TLS
and transport. End of transmission is largely dependent on transport.
Traditional TLS runs on top of TCP and depends on TCP, so there may be
some value if noticing whether the closure of the transfer is expected
or not. But
On Mon, 28 Aug 2023, Eric Rescorla, wrote:
> ...there are quite a few situations in which endpoints close the
>>> connection before receiving a close_notify, for instance, when they receive
>>> an end of data message in the application protocol or when they time out.
>>> The former case is genera
On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth wrote:
> On Mon, 28 Aug 2023, Eric Rescorla, wrote:
>
>> ...there are quite a few situations in which endpoints close the
connection before receiving a close_notify, for instance, when they receive
an end of data message in the application prot
On Tue, Aug 29, 2023 at 10:55:56AM +0200, Ben Smyth wrote:
> TLS 1.2 dictates: Either party may initiate a close by sending a
> close_notify alert...The other party MUST respond with a close_notify
> alert of its own and close down the connection immediately, discarding
> any pending writes.
>
>
On Tue, 29 Aug 2023, 14:31 Eric Rescorla, wrote:
> On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth wrote:
>
>> On Mon, 28 Aug 2023, Eric Rescorla, wrote:
>>
>>> ...there are quite a few situations in which endpoints close the
> connection before receiving a close_notify, for instance, when they
Thanks. I understand your concern better now.
First, I think it's useful to understand what the truncation being referred
to in this case is. Suppose that A has queued messages M1, M2, ... Mn and
receives the close_notify after it has sent M4. If it responds to the
close_notify by flushing its wri
Variant of your example: A receives a request, buffers M1,..., M5, receives
close_notify after sending M4; A's peer sent the request before closing
their write side. Half closure supports request-then-close. (Related thread
in archive:
https://mailarchive.ietf.org/arch/msg/tls/V47DfS4qdsdrF2QLHogsw
On Sat, 2 Sept 2023, 13:30 Ben Smyth, wrote:
> RFC8446 leans towards half closure but doesn't mandate it.
>
> [For full closure,] it makes sense for A to just flush the outgoing data
>>
>
> Yes.
>
> [For half closure], we want A to continue sending and then eventually send
>> a close_notify when
On 9/2/2023 4:36 AM, Ben Smyth wrote:
Oh, perhaps: Because RFC8446 doesn't mandate half closure,
implementations could either transmit all data and close write, or just
close inbound?
Or, applications should clean or abrupt termination as part of the
application logic.
-- Christian Hui
On Sat, Sep 2, 2023 at 4:38 AM Ben Smyth wrote:
> On Sat, 2 Sept 2023, 13:30 Ben Smyth, wrote:
>
>> RFC8446 leans towards half closure but doesn't mandate it.
>>
>> [For full closure,] it makes sense for A to just flush the outgoing data
>>>
>>
>> Yes.
>>
>> [For half closure], we want A to cont
>
>
>>
> My point is that the relevant semantics here are application semantics,
> not TLS semantics.
>
> Regardless of what TLS says, nothing stops an application protocol from
> allowing A to decide it doesn't care what B has to say and sending
> close_notify then closing the transport connection
16 matches
Mail list logo
