Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Rich, It is widely recognized that in many cases, TLS-level compression is flawed (for example NNTP authinfo?). Though I've read a few pages explaining how CRIME and BEAST attacks work, I still do not see well how TLS-level compression would make NNTP vulnerable. Same thing for POP or IMAP I believe. The news server does not leak information. The responses are just OK or KO. For instance: AUTHINFO USER test 381 Enter password AUTHINFO PASS test 281 Authentication succeeded or in the case of an authentication failure: AUTHINFO USER test 381 Enter password AUTHINFO PASS badpassword 481 Authentication failed How compression would make NNTP weaker? (Brute-force attack is still necessary, even with compression enabled.) -- Julien ÉLIE « Etna : lave dévalante. » ___ 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 Sun, Sep 20, 2015 at 5:02 AM, Julien ÉLIE wrote: > Hi Rich, > >> It is widely recognized that in many cases, TLS-level compression is >> flawed (for example NNTP authinfo?). > > > Though I've read a few pages explaining how CRIME and BEAST attacks work, I > still do not see well how TLS-level compression would make NNTP vulnerable. > Same thing for POP or IMAP I believe. > > The news server does not leak information. The responses are just OK or KO. > For instance: This analysis would predict that HTTP isn't vulnerable. Furthermore, the whole point is that TLS is supposed to provide certain services to upper levels, and not require this kind of detailed analysis in security designs. > > AUTHINFO USER test > 381 Enter password > AUTHINFO PASS test > 281 Authentication succeeded > > or in the case of an authentication failure: > > AUTHINFO USER test > 381 Enter password > AUTHINFO PASS badpassword > 481 Authentication failed > > > > How compression would make NNTP weaker? > (Brute-force attack is still necessary, even with compression enabled.) > > -- > Julien ÉLIE > > « Etna : lave dévalante. » > > ___ > 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 Watson, Though I've read a few pages explaining how CRIME and BEAST attacks work, I still do not see well how TLS-level compression would make NNTP vulnerable. Same thing for POP or IMAP I believe. The news server does not leak information. The responses are just OK or KO. This analysis would predict that HTTP isn't vulnerable. I don't understand that point for AUTHINFO. NNTP only answers "281 Authentication succeeded" or "481 Authentication failed" here, whereas HTTP response bodies are far more complex and part of the request may be reflected in the response. -- Julien ÉLIE « Etna : lave dévalante. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Julien, It may well be true that some (typically unauthenticated) application protocols on top of TLS can survive TLS compression, but it is unlikely. You ask a pointed question about AUTHINFO, so just as a fun game, let’s analyze its security: AUTHINFO USER test 381 Enter password AUTHINFO PASS test 281 Authentication succeeded From a formal security viewpoint, the logic behind disabling compression in this exchange is as follows. TLS does not hide the length of plaintext, so an 8-character password is distinguishable from a 4-character one. While this loss of confidentiality may arguably be expected and acceptable, compression makes it worse. Consider the two lines: AUTHINFO PASS AUTHINFO PASS 12345678 Both passwords have 8 characters, and so when no compression is used, a passive network adversary cannot distinguish between them. However, if they are compressed with gzip, the first results in 7 fewer bytes than the second. So compression of this line already yields 3 bits of the password to a passive adversary. No online attack needed so far. Suppose, the client also uses this password with a different command (e.g. XSECRET). XSECRET test XSECRET test 12345678 Now looking at the compressed lengths of this, the passive attacker can get another 3 bits. Considering that the average password entropy can be as low as 20 bits [1], the attacker now has a significant headstart on any other attack she may wish to pursue. 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. Best, Karthik [1] http://www.jbonneau.com/doc/B12-IEEESP-analyzing_70M_anonymized_passwords.pdf > On 20 Sep 2015, at 14:09, Julien ÉLIE wrote: > > Hi Watson, > >>> Though I've read a few pages explaining how CRIME and BEAST attacks work, I >>> still do not see well how TLS-level compression would make NNTP vulnerable. >>> Same thing for POP or IMAP I believe. >>> >>> The news server does not leak information. The responses are just OK or KO. >> >> This analysis would predict that HTTP isn't vulnerable. > > I don't understand that point for AUTHINFO. > NNTP only answers "281 Authentication succeeded" or "481 Authentication > failed" here, whereas HTTP response bodies are far more complex and part of > the request may be reflected in the response. > > -- > Julien ÉLIE > > « Etna : lave dévalante. » > > ___ > 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
> How compression would make NNTP weaker? > (Brute-force attack is still necessary, even with compression enabled.) I don't know, which is why I put a question mark; someone else suggested it. ___ 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 Sun, Sep 20, 2015 at 11:02:19AM +0200, Julien ÉLIE wrote: > Though I've read a few pages explaining how CRIME and BEAST attacks work, I > still do not see well how TLS-level compression would make NNTP vulnerable. > Same thing for POP or IMAP I believe. > > The news server does not leak information. The responses are just OK or KO. > For instance: > > AUTHINFO USER test > 381 Enter password > AUTHINFO PASS test > 281 Authentication succeeded > > or in the case of an authentication failure: > > AUTHINFO USER test > 381 Enter password > AUTHINFO PASS badpassword > 481 Authentication failed > > > > How compression would make NNTP weaker? > (Brute-force attack is still necessary, even with compression enabled.) Consider what happens when data that follows authentication (in sunsequent message bodies) either does or does not match some part of the password... -- Viktor. ___ 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 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). If TLS 1.3 is used, so without compression facility, adding a new COMPRESS command to NNTP will not help if how authentication is done is not strenghtened at the same time, won't it? Or AUTHINFO is not a valid command after the use of COMPRESS. -- Julien ÉLIE « Etna : lave dévalante. » ___ 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 Geoffrey, I bet other protocols would also need similar new specifications to explain how compression can be enabled. I think that's the idea. TLS compression only works for NNTP because no confidentiality is required. In other protocols, there's at least something (if not everything) where confidentality is desirable and so compression needs to be specified very carefully if at all. OK, understood. Even in NNTP, you don't want compression if you're using AUTHINFO---and how do you know AUTHINFO will or won't be used at the time of STARTTLS? Note that AUTHINFO can also use any available SASL mechanisms instead of sending plain user/pass. (Depending on the SASL mechanism, a security layer can be negotiated during the SASL exchange.) Unfortunately, that facility is not wide-spread in news clients and servers. To respond to your question, STARTTLS is not available after a successful authentication. Therefore, it cannot be used after STARTTLS. RFC 4642 states: A server supporting the STARTTLS command as defined in this document will advertise the "STARTTLS" capability label in response to the CAPABILITIES command ([NNTP] Section 5.2). However, this capability MUST NOT be advertised once a TLS layer is active (see Section 2.2.2) or after successful authentication [NNTP-AUTH]. However, though that practice is discouraged, most of news clients still connect to port 563 (dedicated to NNTPS) and negotiate a TLS security layer upon connection. They do not use STARTTLS in that case; and clients can authenticate with AUTHINFO, with an active TLS layer. -- 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] Review of PR #209
On Wed 2015-09-16 13:48:27 -0400, Martin Thomson wrote: > On 16 September 2015 at 08:30, Ilari Liusvaara > wrote: >> As then the application needs to ensure that the authentication >> occurs between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you > have no problem. I think that claim is reasonable, but I'm happy to > discuss it. I think this claim sounds confusing, for (at least) two reasons: (a) it interacts oddly with the possibility of > 1 CertificateVerify message -- does it imply that all messages in a TLS session (past and present) are attested to by every client certificate ever sent in the session? (b) it has unclear semantics around session resumption. If i resume a session and send a ClientCert+CertificateVerify, am i retroactively attesting to all the communications from the previous session(s)? What does that even mean to the server which has already processed the traffic from previous sessions? Can we communicate these semantics to application developers who might have an "accelerating" TLS session cache available, or who might share a session cache between systems? Can we help clients make sense of the implications of retroactive attestation when confronted with a certificateRequest? --dkg ___ 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 Fri 2015-09-18 15:47:27 -0400, "Salz, Rich" wrote: > Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression > feature you need? What TLS 1.3 feature is compelling here? I think this line of argument is worrisome -- we should try to avoid leaving behind protocols that need TLS, if we ever want to be able to deprecate TLS 1.2 the way we've (finally) deprecated SSLv3. That said, i think there are multiple approaches for NNTP and HOB/VPN that don't involve using compression at the TLS layer. For instance, with NNTP, if they're certain that CRIME isn't a risk for their use case, they could introduce a STARTCOMPRESSION verb by analogy to STARTTLS. If the only reason they're using TLS in the first place is for compression, this would be a simpler and less-risky approach in terms of software dependencies as well. I don't know enough about HOB's use of TLS to know whether they could shim their own compression layer in between the VPN traffic or not. The TLS WG knows that compression represents a serious risk to encrypted traffic, especially in situations like browsers where an adversary can direct a peer to initiate protocol action. Compression itself also represents added complexity for protocol analysis. I think we should remove compression and we should also explicitly warn users of the protocol about the risks of combining compression with TLS. --dkg ___ 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 Sat, Sep 19, 2015 at 12:04 PM, Daniel Kahn Gillmor wrote: > I think we should remove compression and we should also explicitly warn > users of the protocol about the risks of combining compression with TLS. +1 -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Key Hierarchy
https://github.com/tlswg/tls13-spec/pull/248 Folks, Hugo Krawczyk, Hoeteck Wee, and Bjorn Tackmann suggested a revision to the key hierarchy that separates out the computation of the MS from the computation of the keys that are derived from ES and SS. Specifically, xES and xES are to be used to derive their respective traffic keys and intermediate values mES and mES which are then used with HKDF-Extract to generate MS. Aside from some analytic advantages, this also allows us to use the HKDF-Extract and HKDF-Expand APIs from RFC 5869 which is convenient (it's also compatible with all-in-one HKDF APIs). The PR is at: https://github.com/tlswg/tls13-spec/pull/248 I think this is a good change, but comments welcome. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Key Hierarchy
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? 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? 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. [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] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
Hi all, We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as suggested by DKG in Prague. All comments welcome. There's an interesting issue here: McEliece keys, which should be permissible, are larger in size (about 2^20 bytes) than the maximum permissible extension size (2^16-1). In order to support McEliece keys it might be worth increasing the maximum extension size to 2^24-1 for TLS 1.3. Is there a strong reason for keeping the maximum size at 2^24-1, other than saving one byte on all the relevant length fields? Cheers, William -- Forwarded message -- From: Date: Sun, Sep 20, 2015 at 10:32 PM Subject: New Version Notification for draft-whyte-qsh-tls13-01.txt To: Zhenfei Zhang , William Whyte < wwh...@securityinnovation.com>, "John M. Schanck" < jscha...@securityinnovation.com> A new version of I-D, draft-whyte-qsh-tls13-01.txt has been successfully submitted by William Whyte and posted to the IETF repository. Name: draft-whyte-qsh-tls13 Revision: 01 Title: Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security (TLS) version 1.3 Document date: 2015-09-20 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-whyte-qsh-tls13-01.txt Status: https://datatracker.ietf.org/doc/draft-whyte-qsh-tls13/ Htmlized: https://tools.ietf.org/html/draft-whyte-qsh-tls13-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-whyte-qsh-tls13-01 Abstract: This document describes the Quantum-Safe Hybrid ciphersuite, a new cipher suite providing modular design for quantum-safe cryptography to be adopted in the handshake for the Transport Layer Security (TLS) protocol version 1.3. In particular, it specifies the use of the NTRUEncrypt encryption scheme in a TLS handshake. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Key Hierarchy
On Sun, Sep 20, 2015 at 6: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? > As I said, a clearer separation between the input keying material used to make traffic keys and that used to make keys which are then input into HKDF. > 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? > I'm going to defer this to Hugo and Hoeteck. > 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. > Why? Note that the next thing we are going to do is use this keys to generate keys which are generally <= 256-bits. It's also worth noting that previous versions of TLS behaved this way as well. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
William Whyte writes: > Hi all, > > We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as > suggested by DKG in Prague. All comments welcome. > > There's an interesting issue here: McEliece keys, which should be > permissible, are larger in size (about 2^20 bytes) than the maximum > permissible extension size (2^16-1). In order to support McEliece keys it > might be worth increasing the maximum extension size to 2^24-1 for TLS 1.3. > Is there a strong reason for keeping the maximum size at 2^24-1, other than > saving one byte on all the relevant length fields? That would affect the initial client hello, which I think we're trying to keep backwards compatible. It might be better to just define a rule like "if multiple extensions with the same number are present, their values are concatenated". ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
Geoffrey Keating writes: >That would affect the initial client hello, which I think we're trying to >keep backwards compatible. It might be better to just define a rule like "if >multiple extensions with the same number are present, their values are >concatenated". A better one would be "if you're planning on introducing some new crypto mechanism, make it one that will fit into the TLS framework". Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
On Sun, Sep 20, 2015 at 7:59 PM, William Whyte < wwh...@securityinnovation.com> wrote: > Hi all, > > We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions > as suggested by DKG in Prague. All comments welcome. > > There's an interesting issue here: McEliece keys, which should be > permissible, are larger in size (about 2^20 bytes) than the maximum > permissible extension size (2^16-1). In order to support McEliece keys it > might be worth increasing the maximum extension size to 2^24-1 for TLS 1.3. > Is there a strong reason for keeping the maximum size at 2^24-1, other than > saving one byte on all the relevant length fields? > William, I suggest you first do an experiment: Create a TLS client that contains all the stuff a browser puts in its TLS handshake. Then, add your new a maximally-sized (2^16-1 bytes) extension, but don't otherwise change the client. What percentage of handshakes fail? I suspect that a huge percentage of the handshakes will fail. First, some implementations won't accept a ClientHello larger than 1KB (IIRC) due to artificial limit imposed presumably as a DoS measure. Secondly, I suspect many implementation will fail to handle a ClientHello that is split across multiple records. Keep in mind that since the maximum record size is less than the maximum extension size, a ClientHello with a maximally-sized extension must require more than one record to be encoded. In general, I would expect most implementations don't want to receive a 1MB message of any sort unless they've advertised that they want such messages. So, a different design that doesn't require including a huge extension in the initial ClientHello would probably be better. Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
As dkg points out, dynamically authenticating clients later in the connection brings up API issues of how to notify the application about the scope of this new authentication event. I think it is inevitable that implementation will store the client credential in the session, and that the new (authenticated) stream of data will be concatenated to the older (unauthenticated) stream. Both of these design choices will lead to the following answers to dkg’s questions: (a) all messages in TLS sessions (past and present) will be attested to by every certificate (b) all traffic in earlier and future resumed sessions will be attested to by every certificate In other words, if we do allow this change to client authentication, to be safe, we must analyze the resulting protocol *as if* applications will use the authentication event to attest to all data, past and present, that may be associated with the data in the current connection. -K. > On 19 Sep 2015, at 22:14, Daniel Kahn Gillmor wrote: > > On Wed 2015-09-16 13:48:27 -0400, Martin Thomson > wrote: >> On 16 September 2015 at 08:30, Ilari Liusvaara >> wrote: >>> As then the application needs to ensure that the authentication >>> occurs between TLS handshake and actually starting up the protocol. >> >> I'm not sure that is necessarily a problem. If the claim is that the >> authentication attests to everything prior to its appearance, then you >> have no problem. I think that claim is reasonable, but I'm happy to >> discuss it. > > I think this claim sounds confusing, for (at least) two reasons: > > (a) it interacts oddly with the possibility of > 1 CertificateVerify >message -- does it imply that all messages in a TLS session >(past and present) are attested to by every client certificate ever >sent in the session? > > (b) it has unclear semantics around session resumption. If i resume a >session and send a ClientCert+CertificateVerify, am i retroactively >attesting to all the communications from the previous session(s)? >What does that even mean to the server which has already processed >the traffic from previous sessions? > > Can we communicate these semantics to application developers who might > have an "accelerating" TLS session cache available, or who might share a > session cache between systems? Can we help clients make sense of the > implications of retroactive attestation when confronted with a > certificateRequest? > > --dkg > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls signature.asc Description: Message signed with OpenPGP using GPGMail ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
