💾 Archived View for gemi.dev › gemini-mailing-list › 000575.gmi captured on 2023-12-28 at 15:49:27. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Hi all, Below are some proposed spec changes to address some (but not yet all) of the recently enumerated outstanding issues. Feedback is welcome. # Section 1.1: In the outline of a Gemini transaction, the step: > S: Closes connection becomes: > S: Closes connection (including TLS close_notify, see 4.2) and the entire outline is followed by the following new text: The outline above describes typical behaviour under typical circumstances, and should be considered illustrative rather than normative in every detail. Some clarifying remarks follow. It is generally the server's responsibility to close the connection, however the client MAY close the connection at any time, e.g. because it has not heard anything from the server for some time, or because the size of the received response body has already exceeded the size it is willing/able to handle. Under non-success conditions, the server MAY send a response header and close the connection before a complete request has been received from the client. The server SHOULD NOT close the connection without sending a response header. The client MAY begin handling a partially-received response body prior to the closure of the connection by the server. # Section 3 Two sets of changes here. First, in order to address the issue of empty <META>s: The line: > <META> is a UTF-8 encoded string of maximum length 1024 bytes, whose > meaning is <STATUS> dependent. becomes: > <META> is a UTF-8 encoded string with a length between 1 and 1024 > bytes (inclusive), whose meaning is <STATUS> dependent. (i.e. META may not be empty) All instances of > The contents of <META> may provide additional information on the > failure become: > The contents of <META> SHOULD provide additional information on the > failure The line: > If <META> is an empty string, the MIME type MUST default to > "text/gemini; charset=utf-8". The text/gemini media type is defined > in section 5. is removed. Secondly, regarding redirects, the following additional lines are added to the explanation of status code 3x in section 3.2.3: Clients MAY request confirmation from a user before redirecting a request. Clients MUST NOT automatically redirect a request more than 5 times, to prevent incorrectly or maliciously configured servers "trapping" clients in infinite redirect sequences, which waste resources on both sides. # Section 4 A new subsection is added: ## 4.2 Close notification As per RFCs 5246 and 8446, TLS 1.2 and 1.3 clients and servers both MUST send a "close_notify" alert before closing their write side of the connection. Under ordinary conditions, the server is responsible for closing the connection. Besides being mandated by TLS RFCs, the use of "close_notify" by the server is important as it allows clients to disambiguate between successfully completed transactions and those where the complete response body was not received due to a network fault or attack. Client authors should note that the semantics of "close_notify" changed between TLS 1.2 and 1.3 - only in TLS 1.3 may a client safely send a "close_notify" after a request to convey that it will not write anything further and then continue to receive the response. To avoid interoperability problems, clients SHOULD NOT send a "close_notify" before the server does under non-error conditions. The completion of a request is already unambiguously indicated by the CRLF characters. Cheers, Solderpunk
I don't see what's wrong with having an empty META, and I believe this is already in use. Why not just allow it and make the spec more clear so that client authors know they need to be able to handle it? I would keep the tab mandatory as well. makeworld
On Sun Dec 27, 2020 at 6:04 PM CET, wrote: > I don't see what's wrong with having an empty META, and I believe this > is > already in use. Why not just allow it and make the spec more clear so > that > client authors know they need to be able to handle it? I would keep the > tab > mandatory as well. For previous discussion see gemini://gemi.dev/gemini-mailing-list/messages/003009.gmi. The thinking is that there are circumstances where an empty META makes no sense. The clearest case is in redirects, where there *must* be a new URL to request. An empty META with a 1x status code *could* be handled sensibly with a default prompt, but leads to a very poor user experience (they have no idea what they're being asked to submit). Response handling is simplest if META is either always optional or always required (otherwise handling needs to be conditioned on the status code), and since always optional is not sensible (due to the above situations), always required is the simplest course of action. Cheers, Solderpunk
(I apologize for breaking the thread view by not replying directly to
the original message.)
> ...
>
> Client authors should note that the semantics of "close_notify"
> changed between TLS 1.2 and 1.3 - only in TLS 1.3 may a client safely
> send a "close_notify" after a request to convey that it will not write
> anything further and then continue to receive the response. To avoid
> interoperability problems, clients SHOULD NOT send a "close_notify"
> before the server does under non-error conditions. The completion of a
> request is already unambiguously indicated by the CRLF characters.
Thanks Solderpunk for proposing these updates.
Section 6.1 of RFC 8446 [1] is specified in order to avoid truncation
attacks. Since, as you noted, the server has another way to determine
that a full request has been received, I think there is no need for a
client to send a TLS close_notify.
The server is allowed to close the read side of its TCP connection at
any time:
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.
Since the sender of a close_notify is allowed to fully close the TCP
connection without waiting for a response, I think the RFC is
implicitely giving permission to the receiver of the close_notify
not to respond in kind.
This is also what I recall seeing in HTTP and Gemini TLS 1.3 packet
flows. Immediately after sending a TLS close_notify the server would
send a TCP FIN (disconnect) packet. When the client received the TLS
close_notify, it would not reply with its own close_notify. Rather,
it would wait for the TCP FIN packet and then reply with its own TCP
FIN packet.
[1] RFC 8446
Section 6.1. Closure Alerts
The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack.
close_notify: This alert notifies the recipient that the sender will
not send any more messages on this connection. Any data received
after a closure alert has been received MUST be ignored.
...
Either party MAY initiate a close of its write side of the connection
by sending a "close_notify" alert. Any data received after a closure
alert has been received MUST be ignored. If a transport-level close
is received prior to a "close_notify", the receiver cannot know that
all the data that was sent has been received.
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.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which implementations were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own. That previous requirement could cause truncation
in the read side. 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.
...
Solderpunk <solderpunk at posteo.net> writes: > Hi all, > > Below are some proposed spec changes to address some (but not yet all) > of the recently enumerated outstanding issues. Feedback is welcome. > All of these changes are fine by me. Thanks, in particular, for the explicit text around the TLS close_notify alert. This had tripped me up with Space Age when I first wrote it and was one of those things I had to figure out and fix by trial and error awhile ago. It sounds like your change to let clients start handling responses before receiving the TLS close_notify alert from the server means that streaming content is now officially supported over Gemini. Do I have that right? Thanks again for making Geminispace a reality. Happy hacking, Gary -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Why is HTML email a security nightmare? See https://useplaintext.email/ Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
---