💾 Archived View for rawtext.club › ~sloum › geminilist › 005830.gmi captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[announce] Delegation of responsibility for spec finalisation

Alex // nytpu alex at nytpu.com

Mon Mar 1 22:26:46 GMT 2021

- - - - - - - - - - - - - - - - - - -

On 2021-03-01 03:18PM, Scot wrote:

1. Not requiring client applications to send TLS close_notify, since

they indicate end-of-data via the request <CR><LF> ?

See this quote from the TLS 1.3 spec:

Each party MUST send a "close_notify" alert before closing its write

side of the connection, unless it has already sent some error alert.

This does not have any effect on its read side of the connection.https://tools.ietf.org/html/rfc8446#section-6.1 - TLS 1.3

The effect of this is that clients MUST send close_notify after writingtheir a request in order to properly comply with TLS 1.3. I wouldoperate under the assumption that a server would not send a responseuntil a close_notify is received (or the request would be allowed totime out). Obviously a robust server would work without a close_notify,but you should still operate within the spec because I'm wouldn't besurprised if at least one or two TLS implementations require it.

There's even stronger wording for TLS 1.2 which requires a close_notifyafter writing is completed and for /both/ the sending and receivingparties to send a close_notify after the transaction is completed, sothe client would have to send a close_notify after the both request andthe response, not just the request.See: https://tools.ietf.org/html/rfc5246#section-7.2.1

On 2021-03-01 03:18PM, Scot wrote:

2. Only requiring server applications to send TLS close_notify if all

data has been sent? If the TCP or TLS connection is interrupted by the

client or by an intermediary before the server application has

transmitted all of its data, there doesn't seem to be a benefit to

sending a close_notify to the client and it could also cause various

delays which prohibit the server application from moving on to other

work. For example, an unending streaming response would be closed by

the client, in which case there is no need for a close_notify from the

server.

The whole point of close_notify is to indicate that the write hassuccessfully been completed. I may be misunderstanding your question,but if the connection is interrupted then a close_notify should not besent, as that would erroneously report that the transaction wassuccessfully completed. For streaming data I assume that it would beproperly terminated by the client closing the connection since the datais never completely sent (it's unending).

I'm no TLS expert, I'm just reporting what I found after skimming theTLS RFCs, feel free to correct me if I'm wrong here.

~nytpu

-- Alex // nytpualex at nytpu.comGPG Key: https://www.nytpu.com/files/pubkey.ascKey fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5Bhttps://useplaintext.email/-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 833 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210301/7c782861/attachment.sig>