Re: [TLS] Confirming consensus: TLS1.3->TLS*
I don't oppose any of the 4 given options, but I slightly prefer TLS 2.0, it seems simple and clear. In my opinion, the whole SSL vs TLS confusion needs better education to confront, version numbers (even dates) alone might not be enough. Renaming *SSL products to *TLS should help. Avoiding "SSL/TLS" might help. Since others have proposed new options, how about TLS 2.017? Using the date has benefits, but the actual crypto changes are much more important, so the decimal makes that point. An old crypto principle is that older is better (among equally unbroken options) -- but naming new stuff is just not enough to rid us of broken old stuff, so putting dates in names might not undermine this principle. For future naming, on minor changes (or even pre-scheduled reviews with no changes), update the date part, on major changes, start from scratch (as in 3.2024, or even use different letters ... ). By the way, I'm sorry if my opinion diverges from the currently forming consensus. Just my $0.02. Dan PS Just to be clear, if votes are to be tallied, my vote on this issue should be weighted quite low (i.e. 0, unless other votes are weighted low too, and some kind of tie-breaker is needed), for at least three reasons: I have not followed the TLS 1.3/2.0 spec closely (i.e., I had no part in building the shed); I have nearly zero experience dealing with user interpretation (i.e. marketing) of protocol names; my preference is weak. (Enough to deserve a negative weight, if that were not cheatable;) PPS I've said before that I prefer TLC(rypto) to TLS(ecurity), but that's unlikely to fly, and it may be okay to grandfather this tradition. (I hope names of future crypto protocols (that TLS WG might work on) can be more specific and realistic.) -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett Sent: Tuesday, November 22, 2016 5:07 PM To: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* (replies to a bunch of ideas in this thread) As the person who lit the match under this latest bikeshed debate, personally, I don't see a strong consensus building here. Leaving the bikeshed unpainted seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if that's the result here. That said, I think I've been somewhat swayed to the TLS 4 camp with the "fourth version of TLS" message. It makes a kind of messy sense that's kind of fitting for TLS. I'm no longer against it. I've also suggested highlighting the year in the past, but only in the context of the title and messaging, not actually replacing the version number itself. I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace of 1.3 and changing it to 2017, wholesale. That just feels even more confusing. Lastly, I am vehemently against the suggestion of ditching the TLS name in favor of SSL again, as was also brought up in this thread. SSL is dead and insecure, and that message needs to stay. We need to get people to stop conflating the two and making this worse, not accepting it. Dave On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote: > I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the > major version number we should abandon the minor one). > TLS 2017 strikes me as quite bad; we're certainly not planning to do a > TLS 2018. I am strongly opposed to TLS 2017. > > -Ekr > > > On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: > > > At IETF 97, the chairs lead a discussion to resolve whether the WG > > should rebrand TLS1.3 to something else. Slides can be found @ > > https://www.ietf.org/proceedings/97/slides/slides- > > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and > > to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm > > this decision on the list so please let the list know your top choice > > between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. ___ 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] record layer limits of TLS1.3
On 23/11/16 19:13, Watson Ladd wrote: > On Nov 23, 2016 10:22 AM, "Jeremy Harris" wrote: >> >> On 23/11/16 08:50, Yoav Nir wrote: >>> As long as you run over a network that has a smallish MTU, you’re going > to incur the packetization costs anyway, either in your code or in > operating system code. If you have a 1.44 GB file you want to send, it’s > going to take a million IP packets either way and 100 million AES block > operations. >> >> Actually, no. Everybody offloads ether-frame packetization and TCP >> re-segmentation to the NIC, talking 64kB TCP segments across the NIC/OS >> boundary. > > Who is 'everybody'? Broadcom, Intel, Emulex... anyone producing a high speed NIC. Perhaps we're talking past each other; I'm referring to (usually TCP) offload. > Let's look at the cost more exactly. We always have to copy from the > storage to the network. Packetization copies a tiny bit more data on each > packet. The amount of extra data doesn't hurt, having to deal with a larger number of buffers does - especially on receive, with reassembly. -- Jeremy ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Maximum Fragment Length negotiation
> On 24 Nov 2016, at 20:50, Thomas Pornin wrote: > > Hello, > > I know that I am a bit late to the party, but I have a suggestion for > the upcoming TLS 1.3. > > Context: I am interested in TLS support in constrained architectures, > specifically those which have very little RAM. I recently published a > first version of an implementation of TLS 1.0 to 1.2, that primarily > targets that kind of system ( https://www.bearssl.org/ ); a fully > functional TLS server can then run in as little as 25 kB of RAM (and > even less of ROM, for the code itself). > > Out of these 25 kB, 16 kB are used for the buffer for incoming records, > because encrypted records cannot be processed until fully received (data > could be obtained from a partial record, but we must wait for the MAC > before actually acting on the data) and TLS specifies that records can > have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is > directly related to that maximum fragment length. > > There is a defined extension (in RFC 6066) that allows a client to > negotiate a smaller maximum fragment length. That extension is simple > to implement, but it has two problems that prevent it from being > really usable: > > 1. It is optional, so any implementation is free not to implement it, >and in practice many do not (e.g. last time I checked, OpenSSL did >not support it). > > 2. It is one-sided: the client may asked for a smaller fragment, but >the server has no choice but to accept the value sent by the client. >In situations where the constrained system is the server, the >extension is not useful (e.g. the embedded system runs a minimal >HTTPS server, for a Web-based configuration interface; the client is >a Web browser and won't ask for a smaller maximum fragment length). > > > I suggest to fix these issues in TLS 1.3. My proposal is the following: > > - Make Max Fragment Length extension support mandatory (right now, > draft 18 makes it "recommended" only). > > - Extend the extension semantics **when used in TLS 1.3** in the following > ways: > > * When an implementation supports a given maximum fragment length, it > MUST also support all smaller lengths (in the list of lengths > indicated in the extension: 512, 1024, 2048, 4096 and 16384). > > * When the server receives the extension for maximum length N, it > may respond with the extension with any length N' <= N (in the > list above). > > * If the client does not send the extension, then this is equivalent > to sending it with a maximum length of 16384 bytes (so the server > may still send the extension, even if the client did not). > > Semantics for the extension in TLS 1.2 and previous is unchanged. > > With these changes, RAM-constrained clients and servers can negotiate a > maximum length for record plaintext that they both support, and such an > implementation can use a small record buffer with the guarantee that all > TLS-1.3-aware peers will refrain from sending larger records. With, for > instance, a 2048-byte buffer, per-record overhead is still small (about > 1%), and overall RAM usage is halved, which is far from negligible. > > > RAM-constrained full TLS 1.3 is likely to be challenging (I envision > issues with, for instance, cookies, since they can be up to 64 kB in > length), but a guaranteed flexible negotiation for maximum fragment > length would be a step in the right direction. > > Any comments / suggestions ? Can we extend this in a way that you can also increase the maximum fragment length. So if the client requests a larger value and the server is willing to do so, it can be used? Best regards Michael > > Thanks, > > > --Thomas Pornin > > ___ > 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] Maximum Fragment Length negotiation
Hi Thomas, your observations are in line with what we had noticed as well, see Section 6 of https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 Ciao Hannes On 11/24/2016 08:50 PM, Thomas Pornin wrote: > Hello, > > I know that I am a bit late to the party, but I have a suggestion for > the upcoming TLS 1.3. > > Context: I am interested in TLS support in constrained architectures, > specifically those which have very little RAM. I recently published a > first version of an implementation of TLS 1.0 to 1.2, that primarily > targets that kind of system ( https://www.bearssl.org/ ); a fully > functional TLS server can then run in as little as 25 kB of RAM (and > even less of ROM, for the code itself). > > Out of these 25 kB, 16 kB are used for the buffer for incoming records, > because encrypted records cannot be processed until fully received (data > could be obtained from a partial record, but we must wait for the MAC > before actually acting on the data) and TLS specifies that records can > have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is > directly related to that maximum fragment length. > > There is a defined extension (in RFC 6066) that allows a client to > negotiate a smaller maximum fragment length. That extension is simple > to implement, but it has two problems that prevent it from being > really usable: > > 1. It is optional, so any implementation is free not to implement it, > and in practice many do not (e.g. last time I checked, OpenSSL did > not support it). > > 2. It is one-sided: the client may asked for a smaller fragment, but > the server has no choice but to accept the value sent by the client. > In situations where the constrained system is the server, the > extension is not useful (e.g. the embedded system runs a minimal > HTTPS server, for a Web-based configuration interface; the client is > a Web browser and won't ask for a smaller maximum fragment length). > > > I suggest to fix these issues in TLS 1.3. My proposal is the following: > > - Make Max Fragment Length extension support mandatory (right now, >draft 18 makes it "recommended" only). > > - Extend the extension semantics **when used in TLS 1.3** in the following >ways: > >* When an implementation supports a given maximum fragment length, it > MUST also support all smaller lengths (in the list of lengths > indicated in the extension: 512, 1024, 2048, 4096 and 16384). > >* When the server receives the extension for maximum length N, it > may respond with the extension with any length N' <= N (in the > list above). > >* If the client does not send the extension, then this is equivalent > to sending it with a maximum length of 16384 bytes (so the server > may still send the extension, even if the client did not). > >Semantics for the extension in TLS 1.2 and previous is unchanged. > > With these changes, RAM-constrained clients and servers can negotiate a > maximum length for record plaintext that they both support, and such an > implementation can use a small record buffer with the guarantee that all > TLS-1.3-aware peers will refrain from sending larger records. With, for > instance, a 2048-byte buffer, per-record overhead is still small (about > 1%), and overall RAM usage is halved, which is far from negligible. > > > RAM-constrained full TLS 1.3 is likely to be challenging (I envision > issues with, for instance, cookies, since they can be up to 64 kB in > length), but a guaranteed flexible negotiation for maximum fragment > length would be a step in the right direction. > > Any comments / suggestions ? > > Thanks, > > > --Thomas Pornin > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Errata Verified] RFC5288 (4694)
RFC Errata System writes: >The following errata report has been verified for RFC5288, >"AES Galois Counter Mode (GCM) Cipher Suites for TLS". I think the erratum needs an erratum. Firstly, nonce doesn't mean "number used once". Secondly, nonce reuse doesn't just result in a failure of integrity-protection, it also results in a loss of confidentiality protection. In other words it leads to total breach of the encryption mode's security, both properties that it's supposed to provide are no longer present. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
