Re: [TLS] TLS Record Size Limitation
Software Engineer 979 wrote: > > 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 have strong doubts that the TLS record size is the problem here. But I've seen higher layer design flaws before, which can cause such problems. The OpenSSL membio-interface seems to exhibit quite sub-optimal behaviour, because it moves data around like crazy if you fill it with MBytes of data. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Record Size Limitation
Thanks for replies everyone. I also posted the same question the OpenSSL mailing list. One interesting response stated that the size was limited to prevent DOS attacks due to resource exhaustion (in the case that data was being injected). "The peer is required to buffer the entire record before processing it, at at that point the data could be from an untrusted party/attacker. So the limit is for protection against denial-of-service via resource exhaustion." Not sure If I totally buy this as you have the same issue (on a smaller scale) w/16K buffers. Also, you underlying application implementation would have alot to due with as well. On Tue, Dec 8, 2015 at 5:20 AM, Yngve N. Pettersen wrote: > On Tue, 08 Dec 2015 11:11:52 +0100, Peter Gutmann < > pgut...@cs.auckland.ac.nz> wrote: > > Dave Garrett writes: >> >> A TLS extension to negotiate max length might be viable. >>> >> >> I think a better starting point would be to look at the implementation >> that's >> causing the problem. There's nothing magical about a 16K max segment size >> that causes poor performance, TCP typically has an MSS of 1400-1500 >> bytes, one >> tenth of the TLS segment size, without there being a 187% loss in >> throughput >> so it looks like the problem is in the implementation, not the protocol. >> I >> don't see any reason why you couldn't get close to wire speeds, or at >> least >> min( crypto speed, wire speed ) for TLS for a properly-done >> implementation. >> >> > Based on my past experience, a possible reason is that the code does the > following: > > read_event_handler: > read data from socket > decrypt data > handle application data > return > > rather than: > > read event handler: > read data from socket > queue data for decryption > signal decryption handler > return > > decryption handler: > decrypt data > handle application data > > Another factor I have seen influencing speed is the size of the buffer > reading from the socket, bigger buffer gives better speed. Within reason, > of course; IIRC the benefit of increasing the buffer stops at around 5-10% > of the connection speed. A good rule of thumb is that the buffer should be > larger than the largest block that you will ever receive over the > computer's local connection, provided you read the arriving data when you > are notified about the data. > > I recently saw 10x+ speed increase by changing an application's handling > of these two aspects (on Windows). In that case 300KB buffer was > sufficient, but I prefer a 1 MB buffer. > > > > -- > Sincerely, > Yngve N. Pettersen > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC7568 (4561)
On 08/12/15 04:05, Martin Thomson wrote: > 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. Done. (Not that anyone will update that RFC - I doubt we'll want to un-obsolete SSLv3;-) S > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The progress about theNegotiated FFDHE proposal
On Dec 05, 2015, at 10:43, Ilari Liusvaara wrote: > > On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: >> Hi, >> >> Any one know why the negotiated FFDHE draft hang on MISSREF state for more >> than 180 days? >> >>http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ > > Normatively depends on the false-start draft that isn't sent to the > RFC-Editor yet. > > The specification itself is done and all the needed codepoints have > been assigned. I haven’t see any comments on he 01 version so I’m checking with Bodo to see if he got any off list comments. If not, we’ll get the WGLC started. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The progress about theNegotiated FFDHE proposal
On Wed, Dec 9, 2015 at 8:44 AM, Sean Turner wrote: > On Dec 05, 2015, at 10:43, Ilari Liusvaara > wrote: > > > > On Sat, Dec 05, 2015 at 11:32:40PM +0800, Xuelei Fan wrote: > >> Hi, > >> > >> Any one know why the negotiated FFDHE draft hang on MISSREF state for > more > >> than 180 days? > >> > >>http://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ > > > > Normatively depends on the false-start draft that isn't sent to the > > RFC-Editor yet. > > > > The specification itself is done and all the needed codepoints have > > been assigned. > > I haven’t see any comments on he 01 version so I’m checking with Bodo to > see if he got any off list comments. If not, we’ll get the WGLC started. > The FF-DHE draft should be reset so that it specifies new cipher suite IDs for TLS_DHE_* cipher suites with the same semantics as the current TLS_DHE_* cipher suites, but with the requirement that the FF-DHE extension is present (for TLS 1.2 and earlier versions). As predicted long ago, the current design of this extension doesn't make sense because it doesn't allow for a client to require a strong DHE key and at the same time maintain compatibility with sites that use weak DHE keys when DHE cipher suites are offered but which would use a strong non-DHE cipher suite if DHE cipher suites are not offered. Additionally, because of the Microsoft SChannel AES-GCM bug from last year, it is very difficult to deploy a client that uses TLS-DHE-AES-GCM or TLS-AES-GCM cipher suites. This is more motivation for the proposal in the previous paragraph. If the current proposal goes ahead unmodified, I suspect most implementers will be forced to ignore it and simply turn of TLS_DHE cipher suites completely. That's what Apple Safari did, what Google Chrome appears to be doing, and also what Firefox partially did. If the goal is really to deprecate TLS_DHE cipher suites completely, then the wording of the draft should be made much simpler and more direct to that effect. Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] chacha/poly interop?
OpenSSL just landed our chacha/poly implementation into master. We pass the RFC test vectors, looking for other implementations to test against. Thanks. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] chacha/poly interop?
BoringSSL has an implementation of the AEAD itself you could test against. It's the EVP_AEAD named EVP_aead_chacha20_poly1305_rfc7539 (to be renamed to EVP_aead_chacha20_poly1305 later). On Wed, Dec 9, 2015 at 8:02 PM Salz, Rich wrote: > OpenSSL just landed our chacha/poly implementation into master. We pass > the RFC test vectors, looking for other implementations to test against. > Thanks. > > > > -- > > Senior Architect, Akamai Technologies > > IM: richs...@jabber.at Twitter: RichSalz > > > ___ > 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
