Re: [TLS] Fixing TLS
On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote: > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: >> Martin's comment reminded me of the following that I've been meaning to >> post... >> >> In a recent discussion among some crypto folks, the topic of what TLS 1.3 >> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path >> from >> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The discussion >> centered around the fact that we already have lots of analysis done for TLS >> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 >> problems while being as compatible as possible with existing infrastructure. >> So what this would do is take existing security analysis applied to TLS, > [...] > > Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks. > > I'll be the bearer of bad news and tell you that your proposal has come up in > multiple forms. I suggested a similar thing a while back and far before me > others have as well. The chairs have, however, long declared consensus that > we want to focus on a single new version not leaving out other more complex > changes, namely latency improvements. Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter way to go to document a profile of TLS 1.2 that covers almost all of this. From a quick read, existing RFCs and I-Ds cover most of this: - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256) - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256) - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) - RFC 7366 (EtM) - RFC 7627 (extended master secret) - RF 4055 (RSA-PSS) The gaps seem to be: - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated (BoringSSL has an implementation using cipher suite 0xca,0xfe) - DH parameters -- the alternative would be using FFDH named groups (draft-ietf-tls-negotiated-ff-dhe-10), right? This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right? Thanks, Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote: >> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: >>> Martin's comment reminded me of the following that I've been meaning to >>> post... >>> >>> In a recent discussion among some crypto folks, the topic of what TLS 1.3 >>> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path >>> from >>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The >>> discussion >>> centered around the fact that we already have lots of analysis done for TLS >>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 >>> problems while being as compatible as possible with existing infrastructure. >>> So what this would do is take existing security analysis applied to TLS, >> [...] >> >> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks. >> >> I'll be the bearer of bad news and tell you that your proposal has come up >> in multiple forms. I suggested a similar thing a while back and far before >> me others have as well. The chairs have, however, long declared consensus >> that we want to focus on a single new version not leaving out other more >> complex changes, namely latency improvements. > > Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter > way to go to document a profile of TLS 1.2 that covers almost all of > this. From a quick read, existing RFCs and I-Ds cover most of this: > - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256) > - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256) > - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) > - RFC 7366 (EtM) > - RFC 7627 (extended master secret) > - RF 4055 (RSA-PSS) > > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe) Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite. Still no cipher suite allocated, but there is an active draft. > - DH parameters -- the alternative would be using FFDH named groups > (draft-ietf-tls-negotiated-ff-dhe-10), right? > > This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right? > > Thanks, > Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
On Tue, Mar 13, 2018 at 3:16 PM, Russ Housley wrote: > Second, using > TLS1.2 does not technically address the issue. If the client were to > exclusively offer DHE-based ciphersuites, then the visibility techniques > that have been used in the past are thwarted. I expect this configuration to become more common in the future. In November 2017, US NIST published draft SP 800-52 r2 (https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft ) which explicitly disallows all non-DH cipher suites. The comment period closed on 1 Feb 2018, and none of the published comments pushed back on this. Given that PCI DSS and many other standards refer to the NIST Special Publications for implementation requirements, I would not be surprised to see DH-only (including ECDH/ECDHE/DHE) become prevalent. Based on the comments from the proponents of the various drafts, it would seem that this should be a bigger concern than any changes in TLS 1.3, as it is implementable today. I highly suspect that the currently deployed systems will not handle handshakes that only offer DH suites, right? Thanks, Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 回复: A TLS extension transfering service indication information
It doesn't seem to be clearly spelled out: is the "charging GW" a system that can read data passing between the client and server but cannot modify it? If so, do I have it right that you are trying to design an extension that allows the client to send a message that can be observed but not tampered? On Tue, Mar 29, 2016 at 9:12 PM, Dacheng Zhang wrote: > The charging GW will not authenticate the client, it only needs to be > informed how the following traffics will be charged, in a trusted way. > That is why we will do this work. For secure reasons, we intend to use TLS > to secure the traffics to or from our APP. So, we need to provide such > information in some way to the charging GW of ISP. > > 在 16-3-30 下午12:06, "Martin Thomson" 写入: > >>On 30 March 2016 at 15:04, Dacheng Zhang >>wrote: >>> Dacheng:Let assume we trust the device. But the APP use a SNI to >>>indicate >>> the service that the APP intends to access. Because the SNI is static >>>which >>> may not be changed for months, it is easier for attackers who monitor >>>the >>> network to get the SNI and use it to gain benefit. We need a securer >>> solution. As I have mentioned in my previous email, this solution will >>>make >>> such attacks more difficult. By the way, SNI is not designed for this >>> purpose, we need to do some additional work to address this issue, >>>right? >> >> >>What is wrong with client authentication? > > > ___ > 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] AD review of draft-ietf-tls-falsestart-01
On Thu, Mar 31, 2016 at 6:19 PM, Sean Turner wrote: > > 0) As described above: Get it approved by the IESG, hold it in RFC editor’s > queue, and publish it as historic at the same time TLS 1.3 is published. I'm not a fan of this option simply because draft-ietf-tls-negotiated-ff-dhe has been stuck is MISSREF state in the RFC editor queue for months waiting on this draft. I don't think there is any question the ffdhe draft is forward looking and I, for one, would like to see it published before TLS 1.3. Thanks, Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
On Fri, Sep 23, 2016 at 2:10 PM, BITS Security wrote: > we need a better option than TLS 1.2 that will, perhaps sooner than we might > expect, be deprecated. I'm somewhat confused here. The concern over RSA for key exchange versus DH for key exchange would only seem to apply when the network tapping system has access to the RSA key, right? So the part of this about monitoring the network for external chat and such doesn't really change if the client is using TLS 1.1 or 1.3, as you still can't decrypt the connection just from monitoring, right? If that is true, then it implies that the server is at least somewhat under control of the monitor, so it can support TLS 1.2 as long as needed. TLS 1.0 came out in 1999 and is still now (in 2016) widely deployed. While I hope TLS 1.3 deployment is speedy, I don't forsee browsers dropping TLS 1.2 and earlier support any time soon. Thanks, Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
On Wed, Oct 25, 2017 at 3:40 PM, Stephen Farrell wrote: > > > On 25/10/17 23:37, Richard Barnes wrote: >> Sorry, what? The current draft proposes an extension, literally the >> opposite of a standard, supported feature. It's explicitly optional. > > Optional is not the opposite of standard. > > See the intended status below. > >> I don't really have a dog in this fight, but let's please be accurate. > > Accuracy level is just fine I think. So, to be completely clear, no one is arguing that Nick's three options (quoted below) are wrong or do not work. The objection is that the IETF should not be publishing a RFC that documents them, is that right? Nick Sullivan wrote: > 1) use TLS 1.2 with RSA -> one single key > 2) use TLS 1.3 with DH key derived from seed -> one single key (similar to > draft-green) > 3) use any version of TLS and export the session keys -> corpus of keys equal > to number of connections Thanks, Peter ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls