Re: [TLS] Question regarding RFC 8446
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 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] Question regarding RFC 8446
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" 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 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
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" 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" > 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 > > 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 > > > ___ Uta mailing list > u...@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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Milestones changed for tls WG
Changed milestone "Submit "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" to the IESG", resolved as "Done". Changed milestone "Submit "Delegated Credentials for TLS" to the IESG", resolved as "Done". Changed milestone "Submit "TLS Ticket Requests" to the IESG", resolved as "Done". Changed milestone "Submit "Importing External PSKs for TLS" to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/tls/about/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] Question regarding RFC 8446
On 11/8/22 3:50 AM, Thomas Fossati wrote: Hi Paul, all, I agree with Yaron: this looks like a (D)TLS profiling aspect that should be defined by the HL7 protocol. +1 here as well. Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
