[TLS] TLS 1.3 ServerConfiguration
This came up while writing serializers/deserializers for various TLS 1.2 and 1.3 stuff... Didn't see issues/pull requests for any of these... 1) ServerConfiguration has field early_data_type, which is of type EarlyDataType. I don't see definition of that type anywhere. I guess it was missed when that type was removed? 2) If ServerConfiguration contains an unknown extension, how should the client behave? Ignore the unknown extension, ignore the entiere ServerConfiguration or send a fatal alert? 3) Could the group and server_key fields be combined into a single field of type KeyShareEntry? The layout would be identical, and one could clearly reuse KeyShareEntry parsing (especially considering some groups have 2-byte interrior length fields as opposed to 1-byte). BTW: The new TLS 1.3 extensions don't have even test values assigned. The values I put in were: - early_data: 13000 (0x32C8) - pre_shared_key: 13001 (0x32C9) - key_share: 13002 (0x32CA) - cookie: 13003 (0x32CB) -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 ServerConfiguration
On Mon, Dec 7, 2015 at 3:09 AM, Ilari Liusvaara wrote: > This came up while writing serializers/deserializers for various TLS > 1.2 and 1.3 stuff... Didn't see issues/pull requests for any of > these... > > 1) ServerConfiguration has field early_data_type, which is of type > EarlyDataType. I don't see definition of that type anywhere. I > guess it was missed when that type was removed? > Oops. This got removed. Will re-add. > 2) If ServerConfiguration contains an unknown extension, how should > the client behave? Ignore the unknown extension, ignore the entiere > ServerConfiguration or send a fatal alert? > Ignore the unknown extension seems consistent. 3) Could the group and server_key fields be combined into a single > field of type KeyShareEntry? The layout would be identical, and > one could clearly reuse KeyShareEntry parsing This is a great idea. I will do it! > (especially > considering some groups have 2-byte interrior length fields > as opposed to 1-byte). > I noticed this in my implementation as well. I actually propose to just remove that extra interior length field. Can't see any reason to keep it. BTW: The new TLS 1.3 extensions don't have even test values > assigned. The values I put in were: > - early_data: 13000 (0x32C8) > - pre_shared_key: 13001 (0x32C9) > - key_share: 13002 (0x32CA) > - cookie: 13003 (0x32CB) > I suggest 40-44 in the order you list above, since we've agreed not to have specified ranges any more. -Ekr > > > -Ilari > > ___ > 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] [Editorial Errata Reported] RFC7568 (4561)
On 8 December 2015 at 14:49, RFC Errata System wrote: > TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, > TLS 1.2 was drafted in 2006, but not published until 2008. The date on the documents are indeed wrong. I recommend holding for document update. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Editorial Errata Reported] RFC7568 (4561)
The following errata report has been submitted for RFC7568, "Deprecating Secure Sockets Layer Version 3.0". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7568&eid=4561 -- Type: Editorial Reported by: Richard Petrie Section: 1. Original Text - Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2002 [RFC4346] and 1.2 in 2006 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3. The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows. Corrected Text -- Since it was released in 1996, the SSLv3 protocol [RFC6101] has been subject to a long series of attacks, both on its key exchange mechanism and on the encryption schemes it supports. Despite being replaced by TLS 1.0 [RFC2246] in 1999, and subsequently TLS 1.1 in 2006 [RFC4346] and 1.2 in 2008 [RFC5246], availability of these replacement versions has not been universal. As a result, many implementations of TLS have permitted the negotiation of SSLv3. The predecessor of SSLv3, SSL version 2, is no longer considered sufficiently secure [RFC6176]. SSLv3 now follows. Notes - TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly, TLS 1.2 was drafted in 2006, but not published until 2008. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -- RFC7568 (draft-ietf-tls-sslv3-diediedie-03) -- Title : Deprecating Secure Sockets Layer Version 3.0 Publication Date: June 2015 Author(s) : R. Barnes, M. Thomson, A. Pironti, A. Langley Category: PROPOSED STANDARD Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS Record Size Limitation
Hello, I'm currently developing an data transfer application using OpenSSL. The application is required to securely transfer large amounts of data over a low latency/high bandwidth network. The data being transferred lives in a 3rd part application that uses 1 MB buffer to transfer data to my application. When I hook OpenSSL into my application I notice an appreciable decline in network throughput. I've traced the issue the default TLS record size of 16K. The smaller record size causes the 3rd party application's buffer to be segmented into 4 16K buffers per write and the resulting overhead considerably slows things down. I've since modified the version of OpenSSL that I'm using to support an arbitrary TLS record size allowing OpenSSL to scale up to 1MB or larger TLS record size. Since this change, my network throughput has dramatically increased (187% degradation down to 33%). I subsequently checked the TLS RFC to determine why a 16K record size was being used, and all could find was the following: length The length (in bytes) of the following TLSCompressed.fragment. The length MUST NOT exceed 2^14 + 1024. The language here is pretty explicit stating that the length must not exceed 16K (+ some change).Does anyone know the reason for this? Is there a cryptographic reason why we shouldn't exceed this message size? Based on my limited experiment, it would appear that a larger record size would benefit low latency/high bandwidth networks. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
