Re: [TLS] Adoption of TLS-LTS
Hubert Kario writes: >On Monday 13 June 2016 19:51:42 Peter Gutmann wrote: >> Hubert Kario writes: >> >to be pedantic, the RFC describes itself "a profile" while in reality >> >it modifies the protocol in a way that will make it incompatible >> >with "vanilla" TLS 1.2 implementations >> >> Oh, right. Well that's easily fixed, I used "profile" because I >> couldn't think of a better term, the best I could come up with is >> "plan", but it's not really a plan either. If people think "plan" is >> better than "profile", and it deals with Russ' objection, I'll change >> it to that. Alternatively, if you can think of a better term than >> "plan", let me know (or forever hold your peace :-). > >"TLS refitting for Long Term Support" > >"Adaptation of TLS for Long Term Support" > >"LTS revision of TLS" > >"LTS addendum to TLS 1.2" (amendment?) So after some discussion with some of the people who'll be using this, we came up with: TLS 1.2 Update for Long-term Support among other suggestions, but that seemed to be the best one. Other options were things like "modernisation" or "improvement" (and one of them suggested "adaptation" as well), but I think "update" says it best. "Revision" is more or less the same as "Update", so I guess either would fit, but I'm leaning more towards "Update". If no-one has any other suggestions I'll post an updated draft, I'm just waiting for permission to include the details of the interop test server that people can run their clients against. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Tuesday, June 14, 2016 04:37:09 am Martin Thomson wrote: > On 13 June 2016 at 21:27, Daniel Kahn Gillmor wrote: > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > > > 1. Use the same key for handshake and application traffic (as in the > > > current draft-13) > > > > > > or > > > > > > 2. Restore a public content type and different keys > > > > Given this choice, i prefer (1). > > +1 > > However... > > I confess that I still haven't properly internalized the objection > from the cryptographers, and that means that I could probably live > with a public content type if more convincing evidence for the value > of 2 could be produced. +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] Compression along with TLS in NNTP
Hi Ángel, Sorry for the delay in the response. I was asking some input from developers of news clients. It implies here that the client will have to know somehow what kinds of newsgroups or articles need extra-security. The client will have to send the right COMPRESS commands at the right time. Yes. Take into account that often only the client will be able to know if the newsgroup contents are deemed confidential by the user or not. In the news.software.nntp, Michael Bäuerle gave the following answer: "In general I see the problem at layer 8: the user needs to understand what is going on and how to control things with the user interface of the programs. The same thing as with encrypted E-Mail: it's far too easy with most programs to send confidential information as clear text by accident. For security purposes it is likely already too much to expect that the "compression on/off" switch is recognised as security relevant by the users. Therefore I think the best solution for security is to use a separate newsreader (explicitly compiled without compression support) for security relevant tasks." Wouldn't it be better that the server also knows somehow what kinds of newsgroups or articles need extra-security, and clears the compression dictionary even if not explicitly asked by the client? Of course, the server MAY flush the compression dictionary more often than required to satisfy some security properties (assuming that's supported by the algorithm). OK. that could be avoided by another suggestion: if a client wants to access both public groups and secret articles, why not open two separate NNTP connections (either in parallel or one after the other)? These two sessions can be compressed, and there will be no leakage. You are sending a stronger signal to someone that was watching the connection, as he will be able to see the two connections. Plus, that requires more server resources (supporting several connections per client) and there is an added overhead of STARTTLS + AUTH on the new connection. For the client wishing to implement this, it may encounter itself being throttled or limited to 1 connection to the server per IP. I understand that point, and that it is a bad idea in general (stronger signal + more resources with the issue of limitation to 1 connection / IP). So as to answer your proposal of ensuring that the contents of articles are not compressed together, we could call "COMPRESS DEFLATE FLUSH" (or another better optional argument) that asks the server to clear the compression dictionary after every response. I expect it to have a similar complexity as allowing a complete algorithm change, while being more limited. What if eg. the user wanted to authenticate again with a different set of credentials? A user cannot authenticate twice in NNTP (RFC 4643). The AUTHINFO command is no longer available after a successful use. The user needs to open another NNTP connection. Using an NNTP command several times in a row to change a state is not usual. Suggestion from news.software.nntp not adding more complexity: "The simple "compression on/off" switch is very easy to implement and should be sufficient for nearly all non academic scenarios. But maybe the default setting for the switch should be defined as "off", because this is the more secure option. Possible words instead of the current: | Implementations MUST support a configuration where compression can be | easily disabled. --- Implementations SHOULD use a default configuration with disabled compression and MUST support an option to easily enable compression [either with global scope or server/connection based]. --- This will ensure that e.g. a new version of a newsreader with support for compression will not enable it automatically (possibly without knowledge of a user who have not read the changelog)." I suggest to also say, like your proposal, that news servers MAY have a global or connection based configuration parameter permitting to enforce more confidentiality on specific newsgroups (notably by ensuring for these newsgroups that the contents of two secret articles are not compressed together). The server will then clear the compression dictionary either after selecting these newsgroups or before sending any article posted to these newsgroups. Wouldn't these additions: - default configuration of disabled compression, - ideas to ensure protection is maximal for those wishing to implement a newsgroups based compression, - clarification that the main problem is that public data and confidential data are compressed together (and not that encryption and compression are used together), satisfy the needs of security? We believe it would work better than complexifying the simple COMPRESS command, and that it no longer introduces potential security issues in the default configuration (whereas the previous version did). -- Julien ÉLIE « A man inserted an 'ad' in the
Re: [TLS] Consensus call for keys used in handshake and data messages
On Wed 2016-06-15 12:23:38 -0400, Ilari Liusvaara wrote: > On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: >> >> To be clear, we're being asked to trade these things off against each >> other here, but there are other options which were ruled out in the >> prior framing of the question which don't rule either of them out. >> >> In particular, if we're willing to pay the cost of a slightly more >> complex key schedule (and an increased TLS record size), we could have >> "packet header" keys which protect the content-type itself for all >> non-cleartext TLS records. If we do that, these keys might as well also >> be used to protect the TLS record size itself. This would result in an >> opaque data stream (though obviously record size would still leak in >> DTLS, and timing and framing is still likely to leak the record size in >> the lowest-latency TLS applications). > > Does this need to enlarge TLS record size? Why doesn't encrypting the > content-type/length and then authenticating those off main MAC work maybe i'm not understanding your proposal, but if we're encrypting the record length as well, how do you find (and validate) the main MAC without knowing the record length? > I presume problems from header-flipping (tho in TLS that will kill the > connection if you try...) I'm not sure what header-flipping is... > Also, in DTLS, there could be issues switching the encryption on > (but then, looks like DTLS 1.3 has other unsolved problems > currently..) yes, i think that might be the case. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Closing on keys used for handshake and data messages
On Jun 3, 2016, at 17:54, Joseph Salowey wrote: > > Unfortunately, the TLS record framing is not easily compatible with having > multiple keys used simultaneously: because we encrypt the content type, it is > not possible to use it to determine which key to use to decrypt. We examined > a number of proposals which would allow you to simultaneously have encrypted > content types and separate keys, but they all appear to be nonviable for one > reason or another: [...] > • Separately encrypting the content type is inefficient in a number of > ways, especially for DTLS (and would need separate security analysis). This > is probably the most viable of the “try to get both” designs. I'd also like more information about the reasoning behind saying that separately encrypting the content type is inefficient. There was some discussion off-list (but not much) about a proposal to encrypt content type (handshake or application) with a separate key, then encrypting data with the corresponding key (handshake key or application key). The content type would be encrypted using unauthenticated encryption, resulting in a single byte of ciphertext. The authenticated encryption using the corresponding key would include the type as associated data to authenticate it. This had a few drawbacks as I remember it: 1) requires one additional byte in the communication; 2) requires deriving and keeping an extra key (the "content type key") around; 3) requires additional encryption/decryption 4) composability of the application key would still be lost because of post-handshake client authentication. In the off-list discussion, Eric had a potential solution to (1). (3) was unavoidable but in my opinion relatively minimal cost. (4) is true, but we now have Hugo's results that give a form of restricted composability that accommodate post-handshake client authentication. There may have been additional discussions that I wasn't around for. I have heard it suggested that (2) is the particularly problematic aspect for DTLS, but I do not know enough about DTLS to understand this. Even if it is problematic for DTLS, if it is not so problematic for TLS, then why not do it for at least TLS? Douglas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
I prefer (1) On Wed, Jun 15, 2016 at 5:51 PM Dan Harkins wrote: > > Hello, > > On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote: > > For background please see [1]. > > > > Please respond to this message indicating which of the following options > > you prefer by Monday June, 20, 2016 > > > > 1. Use the same key for handshake and application traffic (as in the > > current draft-13) > > > > or > > > > 2. Restore a public content type and different keys > > I prefer (1). > > Dan. > > > ___ > 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] Consensus call for keys used in handshake and data messages
Hello, On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following options > you prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys I prefer (1). Dan. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > > To be clear, we're being asked to trade these things off against each > other here, but there are other options which were ruled out in the > prior framing of the question which don't rule either of them out. > > In particular, if we're willing to pay the cost of a slightly more > complex key schedule (and an increased TLS record size), we could have > "packet header" keys which protect the content-type itself for all > non-cleartext TLS records. If we do that, these keys might as well also > be used to protect the TLS record size itself. This would result in an > opaque data stream (though obviously record size would still leak in > DTLS, and timing and framing is still likely to leak the record size in > the lowest-latency TLS applications). Does this need to enlarge TLS record size? Why doesn't encrypting the content-type/length and then authenticating those off main MAC work (that's how SSH with CHACHA20-POLY1305 does things)? I presume problems from header-flipping (tho in TLS that will kill the connection if you try...) Also, in DTLS, there could be issues switching the encryption on (but then, looks like DTLS 1.3 has other unsolved problems currently..) -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > I disagree that this is a low level crypto decision, or at least that this is > mainly so. > > There is the question of whether using the same key for application data and > handshake is harmful. That question is mainly low level crypto and could be > asked of CFRG. > > There is the other question of whether exposing the fact that there are > handshake messages and when they occur is harmful. That is security-related, > but not at all related to crypto. > > Weighing these two potential harms against each other and coming to a > decision is entirely an engineering issue, and we should not offload that to > CFRG. To be clear, we're being asked to trade these things off against each other here, but there are other options which were ruled out in the prior framing of the question which don't rule either of them out. In particular, if we're willing to pay the cost of a slightly more complex key schedule (and an increased TLS record size), we could have "packet header" keys which protect the content-type itself for all non-cleartext TLS records. If we do that, these keys might as well also be used to protect the TLS record size itself. This would result in an opaque data stream (though obviously record size would still leak in DTLS, and timing and framing is still likely to leak the record size in the lowest-latency TLS applications). The current framing of the question pits these things against each other as a tradeoff, but if we want to, we could protect them all. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC5288 (4694)
> On 14 Jun 2016, at 19:25, Joseph Lorenzo Hall wrote: > > s/it's/its/ in one place in your errata text, Aaron. Thank you. I suggest the RFC Errata editors change text and further additions/recommendations by others along the way when publishing (if that's the right way to proceed, I'm quite unfamiliar with the errata process and the information on it is a bit terse, to be honest). Aaron signature.asc Description: Message signed with OpenPGP using GPGMail ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
Hi, Nikos > On 15 Jun 2016, at 11:00 AM, Nikos Mavrogiannopoulos wrote: > > On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: >> For background please see [1]. >> >> Please respond to this message indicating which of the following >> options you prefer by Monday June, 20, 2016 >> >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >> >> or >> >> 2. Restore a public content type and different keys > > Unless participants are really expert on what is the issue is and how > these proofs are constructed, I doubt that people in the TLS WG can > resolve that in a way that provides assurance. There are good arguments > presented in the thread by few cryptographers, but since this is mainly > a low level crypto decision, why not ask the CFRG instead? I disagree that this is a low level crypto decision, or at least that this is mainly so. There is the question of whether using the same key for application data and handshake is harmful. That question is mainly low level crypto and could be asked of CFRG. There is the other question of whether exposing the fact that there are handshake messages and when they occur is harmful. That is security-related, but not at all related to crypto. Weighing these two potential harms against each other and coming to a decision is entirely an engineering issue, and we should not offload that to CFRG. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following > options you prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys Unless participants are really expert on what is the issue is and how these proofs are constructed, I doubt that people in the TLS WG can resolve that in a way that provides assurance. There are good arguments presented in the thread by few cryptographers, but since this is mainly a low level crypto decision, why not ask the CFRG instead? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
