Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech
I support adoption. On Tue, Mar 28, 2023 at 2:20 PM Stephen Farrell wrote: > > > On 28/03/2023 05:57, Salz, Rich wrote: > >> At TLS@IETF116, the sense of the room was that there was WG support to > adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus > in the room. Please indicate whether you do or do not support adoption of > this I-D by 2359UTC on 18 April 2023. If do not support adoption, please > indicate why. > > > > Strong support. > > Yep. No-brainer that one. > > S. > > > > > ___ > > 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech
On 28/03/2023 05:57, Salz, Rich wrote: At TLS@IETF116, the sense of the room was that there was WG support to adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the room. Please indicate whether you do or do not support adoption of this I-D by 2359UTC on 18 April 2023. If do not support adoption, please indicate why. Strong support. Yep. No-brainer that one. S. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech
> At TLS@IETF116, the sense of the room was that there was WG support to adopt > draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the > room. Please indicate whether you do or do not support adoption of this I-D > by 2359UTC on 18 April 2023. If do not support adoption, please indicate why. Strong support. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] The TLS WG has placed draft-sbn-tls-svcb-ech in state "Call For Adoption By WG Issued"
The TLS WG has placed draft-sbn-tls-svcb-ech in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WG Adoption call for draft-sbn-tls-svcb-ech
At TLS@IETF116, the sense of the room was that there was WG support to adopt draft-sbn-tls-svcb-ech [1]. This message is to confirm the consensus in the room. Please indicate whether you do or do not support adoption of this I-D by 2359UTC on 18 April 2023. If do not support adoption, please indicate why. Cheers, Chris, Joe, and Sean [1] https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] potential security concern regarding the exchange of client certificates during the TLS handshake process
This concern is also why many implementations of client certificates in TLS 1.2 and earlier would perform a handshake without requesting a client certificate, then immediately begin renegotiation to exchange the client certificate under encryption. TLS 1.3 removes the need to do this. -Original Message- From: TLS On Behalf Of Viktor Dukhovni Sent: Monday, March 27, 2023 8:08 AM To: tls@ietf.org Subject: Re: [TLS] potential security concern regarding the exchange of client certificates during the TLS handshake process On Sun, Mar 26, 2023 at 02:18:58AM +, Yannick LaRue wrote: > [...] This means that information such as the client's name, email > address, and other identifying details are transmitted in cleartext, > potentially allowing for interception and exploitation by malicious > actors. This is true for TLS versions 1.0–1.2, but not TLS 1.3. > I propose that a solution to this issue would be to separate the > exchange of client certificates from the initial handshake process, > and instead require the client to present their certificate only after > the secure channel has been established. This would allow for mutual > authentication without exposing sensitive information to potential > interception. In TLS 1.3, the client certificate is in the encrypted part of the handshake. TLS 1.3 also supports post-handshake-authentication. > I urge you to consider this proposal and take action to address this > potential security vulnerability. Thank you for your attention to this > matter. It seems you've rediscovered one of the concerns addressed in TLS 1.3. -- Viktor. ___ 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] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On Mon, Mar 27, 2023 at 4:48 PM Watson Ladd wrote > > No. XDP is acting as a firewall and Tubular is mapping packets to sockets. > The TCP is handled by the kernel and given to the application through the > usual interfaces. > > That's different from DPDK where the application is completely responsible > for all handling of packets and the kernel just shoves a ring buffer at it. > > That sort of offload exists, but I don't think it's terribly common. > Obviously how you measure it is hard and we mostly have anecdotes. > It's in the definition, right? https://en.wikipedia.org/wiki/Express_Data_Path The point is to bypass the typical kernel networking. I agree that there are different ways of doing this, and this method reuses more kernel code than others. But it's still not using the kernel code in the way that you would get by default. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On Sun, Mar 26, 2023, 7:03 PM Rob Sayre wrote: > > > On Sun, Mar 26, 2023 at 6:51 PM Watson Ladd wrote: > >> >> >> On Sun, Mar 26, 2023, 5:05 PM Rob Sayre wrote: >> >>> Hi, >>> >>> The problem is also incompletely described, right? >>> >>> It doesn't address stuff like: >>> https://github.com/F-Stack/f-stack >>> >>> There, you have userspace networking right off the NIC using DPDK or >>> equivalent. This is how all big websites work (this one is from Tencent), >>> because it's easier to drain connections as you upgrade the software, and >>> it's fast enough to saturate the network hardware. >>> >> >> That's not quite true: e.g. Netflix is just kernel+TLS offload to >> kernelspace+nginx+sendfile. DPDK draining can be messy while passing the >> opened listening sockets NGINX style is pretty clean. >> > > Yep, another replier person went with the Netflix example (a strong one, > but kind of an outlier). > > > Cloudflare is XDP to kernel stack to application, at least as of the blog >> post I read before posting. >> https://blog.cloudflare.com/tubular-fixing-the-socket-api-with-ebpf/ >> > > Sure, but isn't that the same idea? > > https://en.wikipedia.org/wiki/Express_Data_Path > > "XDP (eXpress Data Path) is an eBPF-based high-performance data path used > to send and receive network packets at high rates by bypassing most of the > operating system networking stack." > > It's exciting that this idea is becoming more of an off-the-shelf > proposition, though. > No. XDP is acting as a firewall and Tubular is mapping packets to sockets. The TCP is handled by the kernel and given to the application through the usual interfaces. That's different from DPDK where the application is completely responsible for all handling of packets and the kernel just shoves a ring buffer at it. That sort of offload exists, but I don't think it's terribly common. Obviously how you measure it is hard and we mostly have anecdotes. Sincerely, Watson > > thanks, > Rob > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
h...@selasky.org said: > A typical video stream of 4 MBit/s may produce on average 333 packets per > second, and I ask a simple question if it is really needed to authenticate > all of those packets while the user sits in a chair and eats popcorn? Are you sure there is a user eating popcorn? Are there any 0-day exploits in your video system? Is that middle box doing the right thing? The main problem I see with your proposal is that it adds complexity. Everybody using TLS will now have to consider what happens if your option gets enabled and/or how to make sure that it doesn't get enabled. Security is complicated. Making it more complicated is a step in the wrong direction. Does your popcorn eating user need TLS as all? -- These are my opinions. I hate spam. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
> FYI: IANA nicely did a review of -rfc8446bis prior to this IETF and suggested > a new section be addd to -rfc84446bis that makes it clear what changes are > being made as a result of that update. That section can be found here: https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-07.html#name-changes-for-this-rfc Yes, it was reading that section that brought the question to my mind. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
FYI: IANA nicely did a review of -rfc8446bis prior to this IETF and suggested a new section be addd to -rfc84446bis that makes it clear what changes are being made as a result of that update. That section can be found here: https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-07.html#name-changes-for-this-rfc spt > On Mar 27, 2023, at 19:15, Salz, Rich > wrote: > > - 8446 registered new code points > - 8447 (mostly) changed the policies for issuance of new code points > > I'm suggesting that we maintain that separation for the -bis documents. > > I can live with the current setup then. > > ___ > 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] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
- 8446 registered new code points - 8447 (mostly) changed the policies for issuance of new code points I'm suggesting that we maintain that separation for the -bis documents. I can live with the current setup then. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
On Mon, Mar 27, 2023 at 2:28 AM Salz, Rich wrote: > > > I would prefer to have any substantive changes in 8446-bis and the policy > changes in 8447-bis > > > > Now I’m more confused, since I consider policy changes substantive > things. And I’m not sure what policy is. > Looking at 8446 and 8447: - 8446 registered new code points - 8447 (mostly) changed the policies for issuance of new code points I'm suggesting that we maintain that separation for the -bis documents. -Ekr > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
I would prefer to have any substantive changes in 8446-bis and the policy changes in 8447-bis Now I’m more confused, since I consider policy changes substantive things. And I’m not sure what policy is. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
I would prefer to have any substantive changes in 8446-bis and the policy changes in 8447-bis -Ekr On Mon, Mar 27, 2023 at 2:10 AM Salz, Rich wrote: > > > Title : IANA Registry Updates for TLS and DTLS > > Authors : Joe Salowey > > Sean Turner > > Filename : draft-ietf-tls-rfc8447bis-04.txt > ... > > This document updates the changes to TLS and DTLS IANA registries > > made in RFC 8447. It adds a new value "D" for discouraged to the > > recommended column of the selected TLS registries. > > Rfc84460bis makes some changes to the registries. Does it make sense to > merge those changes into this document so that we have fewer overlapping > changes? (The items in Section 11.1 defnitely, and maybe some of the > changes in Section 11) > > ___ > 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] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
> Title : IANA Registry Updates for TLS and DTLS > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-rfc8447bis-04.txt ... > This document updates the changes to TLS and DTLS IANA registries > made in RFC 8447. It adds a new value "D" for discouraged to the > recommended column of the selected TLS registries. Rfc84460bis makes some changes to the registries. Does it make sense to merge those changes into this document so that we have fewer overlapping changes? (The items in Section 11.1 defnitely, and maybe some of the changes in Section 11) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On 3/26/23 23:59, Eric Rescorla wrote: Hans Petter, Before I address your technical points, I would observe that your tone here isn't ideal for getting people excited about your ideas. If you think there's something that people don't understand, then by all means explain it, but telling people that they have a "total lack of kernel-side insight" or that their "technology and ideas will be totally left behind" doesn't really foster good will. Hi Eric, Who is your leader? I was aware before posting this topic, that it might be a bit controversial. The reason I'm volunteering for this change, is simply because I think making yet another port-number or protocol, is not where I want to go, neither personally or professionally. In my mind, the AES-CTR should just use the TCP sequence number for offset, and then every now and then update the window so that you get a 64-bit sequence number. As simple as that. As Boris mentioned, the problem about the existing TLS protocol, with regards to hardware offload, appears when you get packet loss. When the received TCP packet stream is not contiguous. I have an impression that a lot of effort has gone into TLS v1.3 and I would like to ask a honest question, if hardware offloads, like done directly on a passive NIC, has ever been considered as parts of the plans and way forward? From my past experience working on various USB controllers, one thing you learn, is that to provide the physical memory pointer to the data you want to transfer to the USB controller, instead of using the CPU to memcpy() the data to the internal buffer of the hardware in question. Using DMA is how you get performance. I know that Intel has made some lookaside PCI crypto cards and people around IETF is probably aware about that. And you may think why is that not a solution? At first I asked for people that can look inside operating systems source code. Now I ask for people that can look inside CPU's verilog code. I guess the count of people that have these permissions is down to a handful of people in the whole world. My point is, that in order to build an efficient system, you need to look what is below your application, all the way down to the wire actually. You cannot just sit in a JAVA container in a VM, in a cluster, doing crypto using TLS. Because JAVA is safe, VM's are safe and TLS is safe, this solution is then 3x safer than other solutions - right! There are so many insane things going on in the world right now, that are totally not needed, and cause huge resource hogs, like electricity, because the over-all system design is just terrible. If data can be avoid copied to/from the CPU or memory lanes 8 times, then you should get 8x performance on the same system basically. Then 7 of 8 data centers don't need to operate! And this is very difficult to grasp, even for engineers, because you need so much insight. And again those people are very rare from what I can see. --HPS ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Transport Layer Security (TLS) WG of the IETF. Title : IANA Registry Updates for TLS and DTLS Authors : Joe Salowey Sean Turner Filename: draft-ietf-tls-rfc8447bis-04.txt Pages : 14 Date: 2023-03-27 Abstract: This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the recommended column of the selected TLS registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-04.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
