Re: [TLS] A suggestion for handling large key shares

Hi Scott, I generally agree with David, in particular that the keyshare prediction draft is the way forward. There is a different use-case for your mechanism, which you didn't mention: it's less likely to trip over buggy servers / middleboxes. We use it as the default mechanism to talk to our cus

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

I support Kris, and would like to see codepoints added for MLKEM-512, MLKEM-768, and MLKEM-1024. -- V/R, Uri On 3/19/24, 00:11, "TLS on behalf of Kris Kwiatkowski" mailto:tls-boun...@ietf.org> on behalf of k...@amongbytes.com > wrote: !--

Re: [TLS] A suggestion for handling large key shares

Hi Scott, David, I think it would make more sense for the normative language about Client and Server behavior (section 3.2, 3.4) in draft-davidben-tls-key-share-prediction-00 (https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html ) to go in draft-ietf-tls-hybrid-desig

Re: [TLS] A suggestion for handling large key shares

On Tue, Mar 19, 2024 at 12:41 AM Bas Westerbaan wrote: > Hi Scott, > > I generally agree with David, in particular that the keyshare prediction > draft is the way forward. > Hi, David did not like this idea, but it's also possible to bake this preference into ECH. If your ECHConfig requires a c

Re: [TLS] A suggestion for handling large key shares

I think you're several discussions behind here. :-P I don't think draft-ietf-tls-hybrid-design makes sense here. This has nothing to do with hybrids, but anything with large key shares. If one were to do Kyber on its own, this would apply too. Rather, per the discussion at IETF 118, the WG opted to

[TLS] Question about Large Record Sizes draft and the TLS design

Hi to all, during the presentation of the Large Record Sizes draft at the tls session yesterday, I wondered why the length restriction is in TLS in the first place. I have gone back to the TLS1.0 RFC, as well as SSLv3, TLS1.3 and TLS1.2 and have found the restriction in all of them, but not

Re: [TLS] Question about Large Record Sizes draft and the TLS design

I can't say what was going on in the SSLv3 days, but yes record size limits are important for memory. Whatever the maximum record size is, the peer can force you to buffer that many bytes in memory. That means the maximum record size is actually a DoS parameter for the protocol. On Wed, Mar 20, 20

Re: [TLS] Question about Large Record Sizes draft and the TLS design

* Whatever the maximum record size is, the peer can force you to buffer that many bytes in memory. That means the maximum record size is actually a DoS parameter for the protocol. Absolutely true. If you have a limit, attackers will try to push your server up to and over the limit and try t

Re: [TLS] Question about Large Record Sizes draft and the TLS design

On 20.03.24 11:08, David Benjamin wrote: I can't say what was going on in the SSLv3 days, but yes record size limits are important for memory. Whatever the maximum record size is, the peer can force you to buffer that many bytes in memory. That means the maximum record size is actually a DoS pa

Re: [TLS] A suggestion for handling large key shares

ACK, thx, I had missed the discussions. It looks like what I was referring to is addressed more prescriptively in rfc8446bis. That is great. From: David Benjamin Sent: Tuesday, March 19, 2024 4:42 PM To: Kampanakis, Panos Cc: Scott Fluhrer (sfluhrer) ; TLS@ietf.org Subject: RE: [EXTERNAL] [TLS]

[TLS] Next steps for Large Record Sizes for TLS and DTLS

Hi, My summary from the TLS WG session yesterday: - Let’s adopt and figure out the final details later. - Show performance data. - Should be new extension, i.e., not used together with "record size limit". - The new extension should redefine the meaning of the uint16 length field in the TLSCiphe

Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS

In offline discussion l was convinced that a bigger change might be needed. The shifting is cute, but we might be able to do better. This won't be wire compatible with the existing protocol, so maybe just embrace that and change the record header. This would happen when switching from handsha

[TLS] dispatching DTLS 1.2 errata

Hi! We’ve got 8 reported errata on DTLS 1.2 (RFC 6347): https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentation=records that we, the royal we where we is the WG, need to dispatch. By way of background, the IESG has the following statement about processing errata on the IE

Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS

Sounds good to me. That makes the solution very simple. The new extension would then work very similar to RFC 8449. The ExtensionData of the "large_record_size" extension is uint32 LargeRecordSizeLimit; When negotiated, all records protected with application_traffic_secret are changed:

Re: [TLS] dispatching DTLS 1.2 errata

> Based on the IESG statement, please let me know by 3 April if you disagree > with the following proposed resolutions: They all look good to me. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] dispatching DTLS 1.2 errata

Hi Sean, Hi List, > Errata on obsolete RFCs should be considered according to whether the error persists in the obsoleting RFC. ... If it does not, it should be Rejected with an explanation that the error is corrected in the obsoleting RFC (cited by number). I'm not sure, but I guess, that assum