Hi David, all,
I would add that if a (D)TLS profile for HL7 is written, UTA can be a natural home for this draft. Regards, Valery. From: TLS <tls-boun...@ietf.org> On Behalf Of Thomas Fossati Sent: Tuesday, November 8, 2022 1:50 PM To: Yaron Sheffer <yaronf.i...@gmail.com>; Paul Wouters <p...@nohats.ca>; Eric Rescorla <e...@rtfm.com> Cc: David Barr <david20...@gmail.com>; uta@ietf.org; t...@ietf.org Subject: Re: [TLS] [Uta] Question regarding RFC 8446 Hi Paul, all, I agree with Yaron: this looks like a (D)TLS profiling aspect that should be defined by the HL7 protocol. Cheers, t On 08/11/2022, 10:36, "Uta" <uta-boun...@ietf.org> wrote: > > 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 > > t...@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > > > > > _______________________________________________ Uta mailing list > Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta > > > _______________________________________________ Uta mailing list > Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
