Re: [TLS] TLS 1.3 - Support for compression to be removed
Julien ÉLIE writes: > Hi Karthik, > >> It may well be true that some (typically unauthenticated) application >> protocols on top of TLS can survive TLS compression, but it is >> unlikely. > [...] >> HTTP is a particularly bad case because the attacker can potentially >> inject arbitrary data before (and after) the secret. With NNTP you >> may escape the worst of this adversary, but you probably won’t find >> any TLS expert willing to say that compressing the password is ok. > > OK, many thanks for the illustration! > > So in fact, to be safer, authentication commands should either be sent > uncompressed or be more complex than they currently are (for instance > with the insertion of random data with random length along with the > authentication command). I believe the general recommendation is to not send passwords in cleartext at all, even in encrypted tunnels. I'm sure you are aware of it, but you may SASL in NNTP as described in RFC 4643. /Simon signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-whyte-qsh-tls13-01.txt
On Sep 21, 2015, at 10:43 PM, Hubert Kario wrote: > >> I doubt anyone would really want to use any keys in the megabyte range >> anyway. Post-quantum crypto research/experimentation for TLS & other >> network protocols should really focus on systems with smaller keys. >> Even if a giant-key scheme was ideal, you'll have a very hard time >> convincing people to actually use it, no matter how much they might >> need it. :/ > > true, that being said, I can see 64KiB total being limiting for > different stuff in the future > > and while sending 2MiB packets as "just a hello" is unlikely, I can see > us sending 64KiB or 128KiB packets... Bernstein et al. needed 64 KiB public keys for McBits [http://binary.cr.yp.to/mcbits-20130616.pdf]. We needed 4 KiB public keys for ring learning with errors [https://eprint.iacr.org/2014/599]; a switch to learning with errors would make the keys much bigger, but I can't say how much bigger at this point. It is too soon to rule out 64 KiB or larger public keys, although getting smaller key sizes is a very important goal for post-quantum crypto research. Douglas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
> On 22 Sep 2015, at 01:40, Geoffrey Keating wrote: > > Daniel Kahn Gillmor writes: > >> Consider a server has an ongoing session wrapped in TLS that uses client >> authentication to approve or deny some requests from the client. It >> remembers what requests the client has made as some sort of relevant >> state. Let's take an imap server working with a client that has state >> of a "currently-examined folder", but this applies to servers and >> clients with much more complex state as well. > ... > > I think for such a protocol, you'd want to say that authentication is > not retroactive. > > For other protocols, you might want something else. For example, in a > protocol which uses client authentication for billing, you might want > to treat an authentication half-way through the session as the account > to bill for the entire session. > > Some protocols will also want to support multiple identities, and some > will not. For some protocols a new authentication might want to in > some fashion dis-trust previous authentications, other protocols might > say that all previous authentications are valid until the end of the > session. If I get this right: 1) it will be possible on the same connection to authenticate with multiple different certificates, 2) the different identities won't ( necessarily ? ) be cumulative ie, a server getting the identity I1 and then I2 on the same TLS connection won't be able to conclude that the referent of I1 is the same as the referent of I2 ? Thinking of a possible use of this over HTTP I find this surprising. So perhaps it is not meant to be applied there. Where is it? If that were to work correctly would one not also have to change the encryption for each user? (sorry to enter the discussion but I am also just checking because I seem to have made a mistaken claim on the HTTP list if 1) is true ) > > > I think this is something that TLS should allow higher-level protocols > to specify. The TLS model could be that each client authentication > happens at a particular point in the session, breaking it up into > segments, and TLS informs the higher-level protocols of where the > segments start and end; it's up to the higher-level protocol to work > out what that means. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Also, if compression is moved from TLS to upper layer(s) - how would it mitigate compression-related attacks? Besides "now it's somebody else's problem"? Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Simon Josefsson Sent: Tuesday, September 22, 2015 04:07 To: Julien ÉLIE Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed Julien ÉLIE writes: > Hi Karthik, > >> It may well be true that some (typically unauthenticated) application >> protocols on top of TLS can survive TLS compression, but it is >> unlikely. > [...] >> HTTP is a particularly bad case because the attacker can potentially >> inject arbitrary data before (and after) the secret. With NNTP you >> may escape the worst of this adversary, but you probably won’t find >> any TLS expert willing to say that compressing the password is ok. > > OK, many thanks for the illustration! > > So in fact, to be safer, authentication commands should either be sent > uncompressed or be more complex than they currently are (for instance > with the insertion of random data with random length along with the > authentication command). I believe the general recommendation is to not send passwords in cleartext at all, even in encrypted tunnels. I'm sure you are aware of it, but you may SASL in NNTP as described in RFC 4643. /Simon smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Tue, Sep 22, 2015 at 9:23 AM, Blumenthal, Uri - 0553 - MITLL wrote: > Also, if compression is moved from TLS to upper layer(s) - how would it > mitigate compression-related attacks? Besides "now it's somebody else's > problem"? Exactly. Upper-level layers can do the analysis to indicate when compression contexts can be shared. TLS cannot as it doesn't have access to the relevant information. > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > Original Message > From: Simon Josefsson > Sent: Tuesday, September 22, 2015 04:07 > To: Julien ÉLIE > Cc: tls@ietf.org > Subject: Re: [TLS] TLS 1.3 - Support for compression to be removed > > Julien ÉLIE writes: > >> Hi Karthik, >> >>> It may well be true that some (typically unauthenticated) application >>> protocols on top of TLS can survive TLS compression, but it is >>> unlikely. >> [...] >>> HTTP is a particularly bad case because the attacker can potentially >>> inject arbitrary data before (and after) the secret. With NNTP you >>> may escape the worst of this adversary, but you probably won’t find >>> any TLS expert willing to say that compressing the password is ok. >> >> OK, many thanks for the illustration! >> >> So in fact, to be safer, authentication commands should either be sent >> uncompressed or be more complex than they currently are (for instance >> with the insertion of random data with random length along with the >> authentication command). > > I believe the general recommendation is to not send passwords in > cleartext at all, even in encrypted tunnels. I'm sure you are aware of > it, but you may SASL in NNTP as described in RFC 4643. > > /Simon > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi all, On 22 September 2015 at 15:23, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Also, if compression is moved from TLS to upper layer(s) - how would it > mitigate compression-related attacks? Besides "now it's somebody else's > problem"? > It allows the authors of the layers above to cherry-pick which parts of the connection to compress, rather than potentially leaking sensitive information through a "blanket compression" on the entire datastream. For instance in the case of HTTP, using a Content-Transfer-Encoding leaks no information on the headers, as only the response body is compressed. Furthermore, one can choose to only apply compression to static resources such as CSS files. -Thijs ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
Hi Henry, > 1) it will be possible on the same connection to authenticate with multiple > different certificates, With the current proposal as it stands, yes. > 2) the different identities won't ( necessarily ? ) be cumulative ie, a > server getting the identity I1 and then I2 on the same TLS connection won't > be able to conclude that the referent of I1 is the same as the referent of > I2 ? I believe the server can conclude this; the caveat is that in practice a server can only support a limited number of client identities simultaneously. > Thinking of a possible use of this over HTTP I find this surprising. So > perhaps it is not meant to be applied there. Where is it? Indeed there's a surprising number of sites that have a landing page accessible without client auth, but require client auth when a protected resource is accessed. This is currently done via renegotiation; in TLS1.3 we're looking for a way to accommodate such sites. > If that were to work correctly would one not also have to change the > encryption for each user? So far we don't know that one has to change the encryption keys after each client authentication, but this is still under discussion. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of henry.st...@bblfish.net Sent: Tuesday, September 22, 2015 6:10 AM To: tls@ietf.org Subject: Re: [TLS] Review of PR #209 > On 22 Sep 2015, at 01:40, Geoffrey Keating wrote: > > Daniel Kahn Gillmor writes: > >> Consider a server has an ongoing session wrapped in TLS that uses >> client authentication to approve or deny some requests from the >> client. It remembers what requests the client has made as some sort >> of relevant state. Let's take an imap server working with a client >> that has state of a "currently-examined folder", but this applies to >> servers and clients with much more complex state as well. > ... > > I think for such a protocol, you'd want to say that authentication is > not retroactive. > > For other protocols, you might want something else. For example, in a > protocol which uses client authentication for billing, you might want > to treat an authentication half-way through the session as the account > to bill for the entire session. > > Some protocols will also want to support multiple identities, and some > will not. For some protocols a new authentication might want to in > some fashion dis-trust previous authentications, other protocols might > say that all previous authentications are valid until the end of the > session. If I get this right: 1) it will be possible on the same connection to authenticate with multiple different certificates, 2) the different identities won't ( necessarily ? ) be cumulative ie, a server getting the identity I1 and then I2 on the same TLS connection won't be able to conclude that the referent of I1 is the same as the referent of I2 ? Thinking of a possible use of this over HTTP I find this surprising. So perhaps it is not meant to be applied there. Where is it? If that were to work correctly would one not also have to change the encryption for each user? (sorry to enter the discussion but I am also just checking because I seem to have made a mistaken claim on the HTTP list if 1) is true ) > > > I think this is something that TLS should allow higher-level protocols > to specify. The TLS model could be that each client authentication > happens at a particular point in the session, breaking it up into > segments, and TLS informs the higher-level protocols of where the > segments start and end; it's up to the higher-level protocol to work > out what that means. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ ___ 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] TLS 1.3 - Support for compression to be removed
On Tue, Sep 22, 2015 at 6:23 AM, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Also, if compression is moved from TLS to upper layer(s) - how would it > mitigate compression-related attacks? Besides "now it's somebody else's > problem"? This is the wrong way of looking at it. Keeping compression in TLS endorses unsafe usage of a feature known to introduce compression sidechannels. Whether other protocols decide to introduce their own secondary compression layer is their own prerogative. But an unsafe feature shouldn't be kept in TLS just because some protocols want to do unsafe things and are too lazy to implement their own compression. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
"henry.st...@bblfish.net" writes: > > On 22 Sep 2015, at 01:40, Geoffrey Keating wrote: > > > > Daniel Kahn Gillmor writes: > > > >> Consider a server has an ongoing session wrapped in TLS that uses client > >> authentication to approve or deny some requests from the client. It > >> remembers what requests the client has made as some sort of relevant > >> state. Let's take an imap server working with a client that has state > >> of a "currently-examined folder", but this applies to servers and > >> clients with much more complex state as well. > > ... > > > > I think for such a protocol, you'd want to say that authentication is > > not retroactive. > > > > For other protocols, you might want something else. For example, in a > > protocol which uses client authentication for billing, you might want > > to treat an authentication half-way through the session as the account > > to bill for the entire session. > > > > Some protocols will also want to support multiple identities, and some > > will not. For some protocols a new authentication might want to in > > some fashion dis-trust previous authentications, other protocols might > > say that all previous authentications are valid until the end of the > > session. > > If I get this right: > 1) it will be possible on the same connection to authenticate > with multiple different certificates, I think this is still under discussion. In the most recent draft, no, but in that draft you can only send a client certificate before sending application data. However a possibility under discussion is that you could send a client certificate at any point in the stream. > 2) the different identities won't ( necessarily ? ) be cumulative > ie, a server getting the identity I1 and then I2 on the same TLS > connection won't be able to conclude that the referent of I1 is the > same as the referent of I2 ? IMO, this is outside the scope of TLS, a higher-layer protocol will have to determine what it means. TLS need only report 'you got a client certificate here and another client certificate here'. > If that were to work correctly would one not also have to change the > encryption for each user? No. Even if the client private key is possessed by an untrusted entity, all that needs to be revealed to that entity to perform the signature is the current value of the handshake hash. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On 22/09/15 17:23, Tony Arcieri wrote: > But an unsafe feature shouldn't be kept in > TLS just because some protocols want to do unsafe things and are too lazy > to implement their own compression. Compression does have issues clearly, but it's not correct to describe people wanting TLS to compress as lazy. They're rather looking for the same features that TLS has offered for a couple of decades. So if there were a way to help them, that'd be good. And if not, the onus I think is on us in this WG to clearly explain why we're removing that feature in TLS1.3. That doesn't have to be text in the TLS1.3 specification but I would guess the question may keep coming up, so documenting the answer in some archival form (such as an RFC:-) might be a good plan. S. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On 9/21/15, Daniel Kahn Gillmor wrote: > On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni > wrote: >> So the client would now need to cache some session data by transport >> address, and other data by name and port. That's rather complex. > > This is already done by HTTP/2 clients, since they can access multiple > servers at the same address:port combination. > >> And how often will the same client visit multiple servers at the >> same transport address? > > *.github.io, *.blogspot.com, massive CDNs, etc. It's a common pattern. > >> I don't really see this as viable or worth the effort. > > I disagree -- the metadata leaked to a passive attacker by mandatory SNI > is a valuable signal. It is worth trying to protect it. I agree - this metadata is usable as a selector for automated surveillance and for automated exploitation. > >> I don't think SNI hiding is viable without encryption at the >> transport or network layers. > > any encrypted SNI is effectively acting as a shim for transport > encryption, yes. Then again, TLS is itself "transport layer security", > so we should try to provide it at least as an option. In an ideal world: using ephemeral keys, we must be able to have usage of the protocol that is selector free. > >> And there's still a metadata leak via DNS which may prove difficult to >> address. > > The DNS community is working to address the DNS leak in DPRIVE. The TLS > community should be working to fix its own part of the metadata leak. > Agreed, strongly. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Tue, Sep 22, 2015 at 1:35 PM, Stephen Farrell wrote: > > > On 22/09/15 17:23, Tony Arcieri wrote: >> But an unsafe feature shouldn't be kept in >> TLS just because some protocols want to do unsafe things and are too lazy >> to implement their own compression. > > Compression does have issues clearly, but it's not correct to describe > people wanting TLS to compress as lazy. They're rather looking for the > same features that TLS has offered for a couple of decades. So if there > were a way to help them, that'd be good. And if not, the onus I think > is on us in this WG to clearly explain why we're removing that feature > in TLS1.3. > > That doesn't have to be text in the TLS1.3 specification but I would > guess the question may keep coming up, so documenting the answer in > some archival form (such as an RFC:-) might be a good plan. I like this idea... and it doesn't have to be compression-specific but could rather be of the variety of "Things that we [don't think make sense/consider harmful/are best done] if done at the TLS layer." This won't help get 1.3 out the door sooner, but it would be very useful to understand important points of consensus in TLS WG that are broader design decisions that may persist past 1.3. best, Joe -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Tony, Keeping compression in TLS endorses unsafe usage of a feature known to introduce compression sidechannels. Whether other protocols decide to introduce their own secondary compression layer is their own prerogative. But an unsafe feature shouldn't be kept in TLS just because some protocols want to do unsafe things and are too lazy to implement their own compression. What for protocols that aren't subject to unsafe usage and that were relying on the compression facility provided by TLS? Unconditionally removing TLS compression leads to a regression for them. As others already mentioned in this list, even with NNTP we can use a safe SASL mechanism to authenticate. No password sent in plain-text. Regarding vulnerable protocols, clients (and/or servers) could very well disable compression in TLS. And either never use compression or implement their own compression, according to their needs. It is what happened with BEAST: Firefox and Chrome disabled TLS compression. -- Julien ÉLIE « Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Tue, Sep 22, 2015 at 1:39 PM, Jacob Appelbaum wrote: > On 9/21/15, Daniel Kahn Gillmor wrote: >> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni >> wrote: >>> So the client would now need to cache some session data by transport >>> address, and other data by name and port. That's rather complex. >> >> This is already done by HTTP/2 clients, since they can access multiple >> servers at the same address:port combination. >> >>> And how often will the same client visit multiple servers at the >>> same transport address? >> >> *.github.io, *.blogspot.com, massive CDNs, etc. It's a common pattern. >> >>> I don't really see this as viable or worth the effort. >> >> I disagree -- the metadata leaked to a passive attacker by mandatory SNI >> is a valuable signal. It is worth trying to protect it. > > I agree - this metadata is usable as a selector for automated > surveillance and for automated exploitation. I agree with Jake and DKG wholeheartedly. I'd add that in addition to surveillance and exploitation, cleartext SNI will be useful for censors at various scales... the same property that it's useful for (distinguishing which domain at an endpoint a TLS conversation is for), can be used to impair or drop flows. I realize there is a small minority of people that participate in TLS WG that feel very strongly about designing a way to have encrypted SNI, but I'd really hope that we can find a way to do it, and that it's not considered too massive of an effort. The uses in which we would want to harden TLS connections against surveillance, exploitation, and censorship will seem to only grow, and having it baked into the infrastructure (and done well) will mean we will have much more deployed ability to resist these kinds of network attacks. >> >>> I don't think SNI hiding is viable without encryption at the >>> transport or network layers. >> >> any encrypted SNI is effectively acting as a shim for transport >> encryption, yes. Then again, TLS is itself "transport layer security", >> so we should try to provide it at least as an option. > > In an ideal world: using ephemeral keys, we must be able to have usage > of the protocol that is selector free. > >> >>> And there's still a metadata leak via DNS which may prove difficult to >>> address. >> >> The DNS community is working to address the DNS leak in DPRIVE. The TLS >> community should be working to fix its own part of the metadata leak. >> > > Agreed, strongly. > > All the best, > Jacob > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Tuesday, September 22, 2015 02:16:47 pm Julien ÉLIE wrote: > Regarding vulnerable protocols, clients (and/or servers) could very well > disable compression in TLS. And either never use compression or > implement their own compression, according to their needs. > It is what happened with BEAST: Firefox and Chrome disabled TLS > compression. No sane security protocol should allow any mode which is known to be insecure under its common use-case. TLS 1.2 is technically configurable in a secure manner, but hardly anyone does so correctly. With TLS 1.3, we need to get rid of all of the insecure modes so all configurations are secure (at least to start). Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
> On Sep 22, 2015, at 8:35 PM, Stephen Farrell > wrote: > > > > On 22/09/15 17:23, Tony Arcieri wrote: >> But an unsafe feature shouldn't be kept in >> TLS just because some protocols want to do unsafe things and are too lazy >> to implement their own compression. > > Compression does have issues clearly, but it's not correct to describe > people wanting TLS to compress as lazy. They're rather looking for the > same features that TLS has offered for a couple of decades. So if there > were a way to help them, that'd be good. And if not, the onus I think > is on us in this WG to clearly explain why we're removing that feature > in TLS1.3. > > That doesn't have to be text in the TLS1.3 specification but I would > guess the question may keep coming up, so documenting the answer in > some archival form (such as an RFC:-) might be a good plan. Doesn’t this count? 3.3. Compression In order to help prevent compression-related attacks (summarized in Section 2.6 of [RFC7457]), implementations and deployments SHOULD disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless the application protocol in question has been shown not to be open to such attacks. Rationale: TLS compression has been subject to security attacks, such as the CRIME attack. (From RFC 7525) Sure, we could leave compression in the spec, and recommend that HTTP MUST NOT use it while NNTP MAY. A protocol for multiple use-cases can be either one size fits all, or else have a bunch of knobs for the different uses. I prefer the one size fits all approach. More specific to compression: people had been using TLS (and SSL) to encrypt HTTP for over two decades before the CRIME attack. That’s how long it took to realize that it is dangerous for HTTP. Are people that sure that a similar issue doesn’t exist for the much less analyzed NNTP? Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
We discussed this before. Not that we can't discuss it again. Here's a link to slides I presented at the Toronto Interim in July 2015. https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Dave, No sane security protocol should allow any mode which is known to be insecure under its common use-case. Then the default in TLS 1.3 could be to not activate compression. TLS 1.2 is technically configurable in a secure manner, but hardly anyone does so correctly. With TLS 1.3, we need to get rid of all of the insecure modes so all configurations are secure (at least to start). This is compatible with keeping compression as a mode that can be explicitly activated. -- Julien ÉLIE « Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
The security community thinks that compression is risky, error-prone, and that a security/auth layer is the wrong place to put it. So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to move to TLS 1.3 without losing data compression." Is this accurate? -- 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] TLS 1.3 - Support for compression to be removed
Hi Rich, The security community thinks that compression is risky, error-prone, and that a security/auth layer is the wrong place to put it. So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to move to TLS 1.3 without losing data compression." Is this accurate? Thanks for that checkpoint in the discussion! I think the counter-arguments given so far all fall in that sentence. Maybe we could say "if TLS 1.2 has a flaw or if I want to benefit of the new facilities provided with TLS 1.3" to be more general. -- Julien ÉLIE « – Je ne peux que vous proposer l'étable… – Comment s'appelle ce village ? – Bethléem, je crois ! » (Astérix) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On 22/09/15 19:32, Yoav Nir wrote: > >> On Sep 22, 2015, at 8:35 PM, Stephen Farrell >> wrote: >> >> >> >> On 22/09/15 17:23, Tony Arcieri wrote: >>> But an unsafe feature shouldn't be kept in >>> TLS just because some protocols want to do unsafe things and are too lazy >>> to implement their own compression. >> >> Compression does have issues clearly, but it's not correct to describe >> people wanting TLS to compress as lazy. They're rather looking for the >> same features that TLS has offered for a couple of decades. So if there >> were a way to help them, that'd be good. And if not, the onus I think >> is on us in this WG to clearly explain why we're removing that feature >> in TLS1.3. >> >> That doesn't have to be text in the TLS1.3 specification but I would >> guess the question may keep coming up, so documenting the answer in >> some archival form (such as an RFC:-) might be a good plan. > > Doesn’t this count? It does count, but doesn't cover TLS1.3. And it's when TLS1.3 hits the shelves that we'll maybe get more and more folks waking up to the fact that we've removed functionality. (That's not so different to what seems to be happening with HTTP/2 and client-auth maybe.) But yes, text along those lines is what'd be needed. Depending on the overall scope, one might want more self-contained text and less of a dependency on references, not sure. S. > > 3.3. Compression > > >In order to help prevent compression-related attacks (summarized in >Section 2.6 of [RFC7457]), implementations and deployments SHOULD >disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless >the application protocol in question has been shown not to be open to >such attacks. > >Rationale: TLS compression has been subject to security attacks, such >as the CRIME attack. > > (From RFC 7525) > > Sure, we could leave compression in the spec, and recommend that HTTP MUST > NOT use it while NNTP MAY. > > A protocol for multiple use-cases can be either one size fits all, or else > have a bunch of knobs for the different uses. I prefer the one size fits all > approach. > > More specific to compression: people had been using TLS (and SSL) to encrypt > HTTP for over two decades before the CRIME attack. That’s how long it took to > realize that it is dangerous for HTTP. Are people that sure that a similar > issue doesn’t exist for the much less analyzed NNTP? > > Yoav > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
> On Sep 22, 2015, at 9:40 PM, Salz, Rich wrote: > > The security community thinks that compression is risky, error-prone, and > that a security/auth layer is the wrong place to put it. > > So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to > move to TLS 1.3 without losing data compression." > > Is this accurate? I think the other counter-argument is that modifying NNTP to have a compression feature is hard, whereas updating the TLS library is something that implementations are likely to do. I have to wonder if it’s worth it. In the last decade bandwidth has increased and prices for networking have gone down much faster than CPU speeds. 10 years ago having 1 Mbps at home was the highest-end broadband you could get. Now you routinely get 100x that. CPU has increased, but nowhere near that. This makes compression less desirable, to the point that people did not complain much when browser vendors removed compression following the CRIME attacks. True, the rise of mobile brought back limited bandwidth, but is this really an issue? Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On 09/22/2015 02:44 PM, Yoav Nir wrote: >> On Sep 22, 2015, at 9:40 PM, Salz, Rich wrote: >> >> The security community thinks that compression is risky, error-prone, and >> that a security/auth layer is the wrong place to put it. >> >> So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to >> move to TLS 1.3 without losing data compression." >> >> Is this accurate? > I think the other counter-argument is that modifying NNTP to have a > compression feature is hard, whereas updating the TLS library is something > that implementations are likely to do. > > I have to wonder if it’s worth it. In the last decade bandwidth has increased > and prices for networking have gone down much faster than CPU speeds. 10 > years ago having 1 Mbps at home was the highest-end broadband you could get. > Now you routinely get 100x that. CPU has increased, but nowhere near that. > This makes compression less desirable, to the point that people did not > complain much when browser vendors removed compression following the CRIME > attacks. True, the rise of mobile brought back limited bandwidth, but is this > really an issue? Well, this just came across my browser: http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new-compression.html -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Tue, Sep 22, 2015 at 02:56:36PM -0400, Jeffrey Walton wrote: > > If compression increases entropy, then one could argue its a desired > service with security benefits. Compression does not change the total amount of entropy. It has the same entropy but in less bits, so you increase the density. The security should not depend on the entropy density. After the encryption you should not be able to tell what the density was. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Key Hierarchy
On Sun, Sep 20, 2015 at 9:56 PM, Brian Smith wrote: > On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla wrote: > >> https://github.com/tlswg/tls13-spec/pull/248 >> >> Aside from some analytic advantages >> > > What are the analytic advantages? > The advantages are: a cleaner separation of keys derived from ES and SS, a simpler proof argument (via the explicit functional separation of extract and expand steps), and the ability to represent the whole key derivation scheme via the extract/expand steps or via full HKDF calls, whichever is more convenient (the latter gives significant flexibility to an implementation depending on its API to the full HKDF function or to its extract and expand components). > Also, a question that applied even to the older design: I remember the an > HKDF paper and the HKDF paper stating that before it is safe to use a value > as an HKDF salt, it must be authenticated. But, in both the old and new > designs it seems like an authenticated value is being used as the salt in > the HKDF-Extract(mSS, mES) operation. What does this mean for the security > analysis? > It seems that when you say "an authenticated value" you actually mean "an unauthenticated value". If I got it wrong let me know. Assuming this interpretation of your question let me point out that the value mSS is server-authenticated by virtues of g^s being authenticated (via a server's signature or a server-configuration) hence it complies with the RFC (and paper). > One of the notes in the new design draws some attention to the strange > fact that we compress the output of the ECDHE operation to the length of a > digest function that is independent of the length of the ECDH keys used. > For example, if we used P-256 in the ECDHE operation for a AES-128-GCM > cipher suite, we'd compress the output to 256 bits using HKDF-Extract with > SHA-256. But, if we used P-521 in the ECDHE operation for the same cipher > suite, we'd still compress the output to 256 bits using HKDF-Extract with > SHA-256. That seems wrong. I would guess it makes more sense to choose the > HKDF digest algorithm based on the size of the ECDHE key. Note that in the > NSA Suite B Profile for TLS, they fixed this by requiring a more rigid > relationship between the ECDHE key size and the cipher suite than what TLS > requires. See [1]. I think it's worth considering whether the current > (older and newer) design makes is better or worse than a design like the > NSA Suite B Profile in this respect. > Ekr answered this. If you still feel something is wrong let us know. Hugo > > [1] https://tools.ietf.org/html/rfc6460#section-3.1. > > Cheers, > Brian > -- > https://briansmith.org/ > > > ___ > 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
[TLS] '15 TLS Fall Interim Minutes
I’ve gone ahead and posted the minutes/list of decisions to: https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] '15 TLS Fall Interim Minutes
"Versions of TLS prior to 1.3 had limited support for padding. This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types. The design also enforces all-zero padding octets, which allows for quick detection of padding errors. " On Tue, Sep 22, 2015 at 4:45 PM, Dave Garrett wrote: > On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > That has this: > > > For padding, we reached a very rough consensus to start with the content > type followed by all zeros (insert reasons why) over the explicit length > option (insert reasons why). DKG to propose a PR that we'll then fight out > on the list. See PR #253. > > The "reasons why" that were discussed were not inserted. ;) > > > Dave > > ___ > 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] '15 TLS Fall Interim Minutes
Thanks. What sort of errors are we trying to avoid by making sure implementations have to check for zeroed padding? Are we really worried some sloppy implementation is going to leave it uninitialized in a memory-unsafe language and just encrypt an arbitrary block of memory? This was mentioned at some point, and sounds really stupid, but planning for the stupid is probably a good idea. Dave On Tuesday, September 22, 2015 09:18:53 pm Eric Rescorla wrote: > "Versions of TLS prior to 1.3 had limited support for padding. This padding > scheme was selected because it allows padding of any encrypted TLS record > by an arbitrary size (from zero up to TLS record size limits) without > introducing new content types. The design also enforces all-zero padding > octets, which allows for quick detection of padding errors. > " > > On Tue, Sep 22, 2015 at 4:45 PM, Dave Garrett > wrote: > > > On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > > > That has this: > > > > > For padding, we reached a very rough consensus to start with the content > > type followed by all zeros (insert reasons why) over the explicit length > > option (insert reasons why). DKG to propose a PR that we'll then fight out > > on the list. See PR #253. > > > > The "reasons why" that were discussed were not inserted. ;) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Benjamin Kaduk writes: >Well, this just came across my browser: >http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new- >compression.html There's a million compression algorithms [0] out there, you shouldn't have any problem finding one to fit your needs, and you don't really need to wait for some new one to come along, there are lots of viable candidates. Responding to the OP's comment, the "we have all the bandwidth we need" argument is the cousin of the endlessly-used "everyone has a quad-core 2GHz i7 with 8GB of RAM so we don't need to worry about efficient algorithms any more". You may have the bandwidth (and a quad-core i7), but there are lots and lots of cases that don't, and never will. (The majority of these use store-and-forward, so CMS (S/MIME) or PGP compression, I can't immediately think of any that use TLS compression, but wanted to point out that "well, it works for me" isn't really a valid argument). Peter. [0] Figure exaggerated slightly for theatrical effect, actual is hundreds to thousands depending on how you count sub-families and variants. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
I think there is a compression extension for NNTP: http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html it doesn't seem too hard. My 2c: even if this were not the case, optimizing NNTP in a backwards compatible way does seem like a more important goal than making transport security as secure as possible by default. On Tue, Sep 22, 2015 at 12:44 PM, Yoav Nir wrote: > > > On Sep 22, 2015, at 9:40 PM, Salz, Rich wrote: > > > > The security community thinks that compression is risky, error-prone, > and that a security/auth layer is the wrong place to put it. > > > > So far, the only counter-argument has been "if TLS 1.2 has a flaw, I > want to move to TLS 1.3 without losing data compression." > > > > Is this accurate? > > I think the other counter-argument is that modifying NNTP to have a > compression feature is hard, whereas updating the TLS library is something > that implementations are likely to do. > > I have to wonder if it’s worth it. In the last decade bandwidth has > increased and prices for networking have gone down much faster than CPU > speeds. 10 years ago having 1 Mbps at home was the highest-end broadband > you could get. Now you routinely get 100x that. CPU has increased, but > nowhere near that. This makes compression less desirable, to the point that > people did not complain much when browser vendors removed compression > following the CRIME attacks. True, the rise of mobile brought back limited > bandwidth, but is this really an issue? > > Yoav > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Tue, Sep 22, 2015 at 8:32 PM, Colm MacCárthaigh wrote: > it doesn't seem too hard. My 2c: even if this were not the case, > optimizing NNTP in a backwards compatible way does seem like a more > important goal than making transport security as secure as possible by > default. > I don't think I could be more opposed to this position. The most important transport encryption protocol on the Internet should not have sharp edges simply to cater to the errata of Usenet. Nobody is forcing NNTP users to use TLS 1.3. I'm not sure the new features of TLS 1.3 even make sense for NNTP use cases. NNTP can add its own compression. Or worst case, if there's some existential threat to TLS < 1.3, NNTP can switch and not have compression until they can implement their own compression feature. If compression is so important to NNTP, they should add first-class support. Period. They should not be relying on a poorly conceived feature which has been repeatedly demonstrated to introduce vulnerabilities in what is supposed to be a *security protocol* just because they don't want to implement compression themselves. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
> On 22 Sep 2015, at 01:40, Geoffrey Keating wrote: > > Daniel Kahn Gillmor writes: > >> Consider a server has an ongoing session wrapped in TLS that uses client >> authentication to approve or deny some requests from the client. It >> remembers what requests the client has made as some sort of relevant >> state. Let's take an imap server working with a client that has state >> of a "currently-examined folder", but this applies to servers and >> clients with much more complex state as well. > ... > > I think for such a protocol, you'd want to say that authentication is > not retroactive. > > For other protocols, you might want something else. For example, in a > protocol which uses client authentication for billing, you might want > to treat an authentication half-way through the session as the account > to bill for the entire session. > > Some protocols will also want to support multiple identities, and some > will not. For some protocols a new authentication might want to in > some fashion dis-trust previous authentications, other protocols might > say that all previous authentications are valid until the end of the > session. If I get this right: 1) it will be possible on the same connection to authenticate with multiple different certificates, 2) the different identities won't ( necessarily ? ) be cumulative ie, a server getting the identity I1 and then I2 on the same TLS connection won't be able to conclude that the referent of I1 is the same as the referent of I2 ? Thinking of a possible use of this over HTTP I find this surprising. So perhaps it is not meant to be applied there. Where is it? If that were to work correctly would one not also have to change the encryption for each user? (sorry to enter the discussion but I am also just checking because I seem to have made a mistaken claim on the HTTP list if 1) is true ) > > > I think this is something that TLS should allow higher-level protocols > to specify. The TLS model could be that each client authentication > happens at a particular point in the session, breaking it up into > segments, and TLS informs the higher-level protocols of where the > segments start and end; it's up to the higher-level protocol to work > out what that means. > > ___ > 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
