Hi Paul,
I'm actually not sure this is a good idea, and not because we are at the RFC
Editor.
TLS has intentionally kept this aspect out of scope basically forever. The
following text appears in TLS 1.0 (Jan. 1999) and still appears unchanged in
TLS 1.3:
"No part of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when connections
are opened or closed."
Given we left this behavior unspecified, it is no wonder that people have
differing implementations. I'm not sure it is appropriate for UTA to make this
decision for the whole industry and hundreds of protocols that are layered on
top of TLS.
Thanks,
Yaron
On 08/11/2022, 10:05, "Uta on behalf of Paul Wouters" <uta-boun...@ietf.org on
behalf of p...@nohats.ca> wrote:
On Mon, 7 Nov 2022, Eric Rescorla wrote:
> Subject: Re: [TLS] Question regarding RFC 8446
>
> Hi David,
>
> This question seems a bit out of scope for TLS, which is kind of
indifferent to the transport interaction.
>
> Perhaps it might make sense to be in UTA, though unfortunately, RFC
7525-bis is in the editor queue now...
I just talked to my fellow AD, and we are okay with a one line/paragraph
addition to 7525-bis if the document authors and UTA chairs are okay
with this as well. It seems a real interop issue that would be good to
nail down.
Paul
> -Ekr
>
>
> On Mon, Nov 7, 2022 at 1:37 AM David Barr <david20...@gmail.com> wrote:
> How can I make suggestions for the TLS specifications? I'm having a
problem that could be clarified by a change to the spec.
> This is the sentence that causes problems for me: "how to initiate TLS
handshaking and how to interpret the authentication certificates exchanged
> are left to the judgment of the designers and implementors of protocols
that run on top of TLS".
>
> I have two vendors that have implemented software that layers the HL7
protocol on top of TLS. The Epic implementation does not perform a handshake
> until it has data to send. This could be hours after the TCP connection
is established. There is no other TCP communication prior to the handshake
> (e.g. a STARTTLS command). The Infor Cloverleaf implementation times out
waiting for a handshake, and the software becomes unresponsive while this
> is happening.
>
> It would be helpful if the TLS spec added something like this:
>
> If protocols that are layered on top of TLS use implicit encryption
(relying on a port number rather than an explicit command that is
> issued before the handshake), then the handshake should begin
immediately after the TCP/IP socket connection is established.
>
> I have no idea how suggestions like this make it into the spec, so if I
need to suggest this somewhere else, please let me know.
>
> David Barr
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
_______________________________________________
Uta mailing list
u...@ietf.org
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
