Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
To be honest, I’m rather surprised that this group continues to spend time on this. I’m of the opinion that the chairs should step in and put this discussion on hold until the work on TLS 1.3 is complete. This, and any document of the same goal, are eating up time and energy that should be directed to completing the work this group was chartered to do. There’s no indication that there will be any consensus on moving forward with any such document in this group, and I don’t think that will change any time soon. Those advocating for some standardized method of subverting the security properties of TLS have been offered numerous options in good faith, and continue to reject them all. I’m aware of extremely large enterprises that in fact require TLS 1.2 with PFS, as they made the investment in addressing this issue early on, and do so effectively. This can be solved without changes to the protocol or a standardized “backdoor” - and is being done today by at least some enterprises. I understand that this complicates the work that some do, and will mean additional engineering or spending to deal with it, when they eventually move to TLS 1.3; that said, I don’t think their decision to take the easy route in traffic inspection and ignore the evolution of 1.3 till the last moment should lead to adding new risk to every other TLS user, especially those that invested in long term solutions that deal with these changes. I’m of the opinion that this discussion is no longer productive; there’s no indication that there will be consensus on this or similar documents, good faith efforts have been made to offer alternatives - in multiple discussions, it’s distracting from the work of completing 1.3. To me, the most logical thing to do is move on, finish the work on 1.3, and then reevaluate (not that I expect consensus to emerge then either). -- --*Adam Caudill* http://adamcaudill.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
Andrew, You are requesting a major design change at the last minute, to restore a problematic feature that was removed due to its negative security impact. You should understand from the beginning that this is an extreme request. Moreso, you should understand that others in your industry have no problem complying with US and international regulations, while using PFS cipher suites. I am personally aware of two of the largest financial organizations in the US that actually require PFS suites for all internal and external applications, and use endpoint security applications to handle this issue. It may not be as convenient as what you are doing now, but it is a problem that has already been solved, and solved effectively. Before claiming that the IETF is eliminating your choice, you may want to take a closer look at how those your industry have already dealt with this. There are effective solutions that have already been mentioned, that don’t involve reducing the security of every TLS user around the globe. Personally, I agree completely with Kenny’s response - the answer is simply no. It’s too large of a change, it has too large of a security impact, and there are established solutions to address your issues. -- Adam Caudill a...@adamcaudill.com http://adamcaudill.com/ > On Sep 23, 2016, at 5:34 PM, BITS Security <bitssecur...@fsroundtable.org> > wrote: > >> you can keep using TLS1.2 in your internal network, can't you? > > There are both public and private sector regulators arcing towards being more > prescriptive in this area. It is possible, if not likely, in the not too > distant future that my member companies will not have the choice to > "downgrade" to "obsolete" TLS versions. > > Note: the standards track document says it "Obsoletes: RFC 5246" which is TLS > 1.2. That's a signal that may prove difficult to divert in this rapidly > evolving threat and regulatory environment. > > - Andrew > signature.asc Description: Message signed with OpenPGP using GPGMail ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
> On Aug 31, 2016, at 10:01 PM, Eric Mill <e...@konklone.com> wrote: > > > FWIW, I've definitely seen real-world confusion about SSLv3 being a more > recent protocol than TLS 1.X, by organizations that should know better. If > there's interest and consensus, this could be a good opportunity to reset the > situation with TLS/2 or TLS 4.0. > > I like TLS/2 aesthetically, and represents a similar level of progress/reset > that HTTP saw when it jumped from 1.1 to /2. > > -- Eric If it was called TLS/2, I suspect most people would still view it as TLS 2.0 - personally I see the / naming scheme as more of a aesthetic choice than something that meaningfully impacts perception. The mistakes that were made that set up the potential confusion between SSL 2 and TLS 2 were made long ago, and are likely beyond correction at this point. While we could go with TLS 3.4 (to match the version on the wire), or TLS 4.0 (to jump past the SSL versions), I agree with those that stated that it would cause additional confusion. And there’s more than enough confusion out there thanks to SSL vs. TLS, no need to further complicate matters. As for moving from TLS 1.3 to TLS 2.0 - this is something that will have to be dealt with at some point. Calling this version 2.0 was debated quite some time ago, and as I recall, the consensus then was to go with 1.3 and keep the changes minimal, saving 2.0 for a later, larger set of changes. Looking at the current version of the draft, calling this 2.0 seems fitting to me - as the changes have been fairly significant, not the overhaul that some wanted, but still significant. Personally, I don’t think what we call it actually has that much impact though - calling it 2.0 could cause some to jump on it quicker, could cause those that are highly risk-adverse to delay it, I doubt either of these groups would be large enough to have an impact. It’s still a new version, and will be treated the same as new versions were in the past, no matter what we call it. Overall, I’m indifferent on calling it 2.0, generally against /2, 3.4, 4.0, etc. and perfectly fine leaving it as 1.3. -- Adam Caudill a...@adamcaudill.com http://adamcaudill.com/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
