Re: [TLS] FYI, a subverted implementation attack against TLS a t ia.cr/2020/1452
On 8/26/21 at 6:01 PM, m...@lowentropy.net (Martin Thomson) wrote: That Signal was hard is interesting, but I don't think that the authors were sufficiently creative. They say "these low-bandwidth attacks cannot be used to leak the short-term, ephemeral keys", but I don't think that is true at all. I'll leave it as an exercise for the reader, but I believe it to be trivial to have all keying material available to the observer if an endpoint is cooperative. And remember, you don't have to exfiltrate the whole key to make the exhaustive search problem much easier. Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)348-7900 | using a perimeter defense is a | 150 Rivermead Rd #235 www.pwpconsult.com | perimeter. | Peterborough, NH 03458 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Transport Issues in DTLS 1.3
On 3/30/21 at 2:47 PM, martin.h.d...@gmail.com (Martin Duke) wrote: To reiterate, I believe introducing latency regressions with respect to DTLS 1.2 would be bad for the internet. So what's new in the area under discussion is (a) lowering the timeout from 1s to 100ms, and (b) the introduction of ACKs. I would characterize ekr's reply as making the following points: (1) *DTLS practice at Mozilla and elsewhere already uses timeouts << 1 sec*. Thanks for this report about the real world. I have no doubt that for WebRTC and other use cases, a short timeout is fine. However, DTLS is a general-purpose protocol and the standard should be quite conservative about the paths this thing is going to run over. Obviously, people are going to ignore this requirement when they think they can get an advantage no matter what the RFC says. I see three acceptable ways to proceed: (a) stick with 1 second with words saying that given some OOB knowledge you can go lower; (b) the same, but having an explicit floor of 100ms or 200ms; or (c) having a shorter threshold for small flights, as I proposed in my Are there any issues with space-based paths? I know Elon Musk is planning Internet service via many LEO satellites. If we were talking about going to the moon, that would be a 3 second delay. Cheers - Bill --- Bill Frantz| Can't fix stupid, but | Periwinkle (408)348-7900 | duct tape can muffle the| 150 Rivermead Road #235 www.pwpconsult.com | sound... - Bill Liebman | Peterborough, NY 03458 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites
On 2/11/21 at 9:01 PM, rsalz=40akamai@dmarc.ietf.org (Salz, Rich) wrote: I would just like to recognize that there are some situations where it isn't needed. Can you explain why TLS 1.2 isn't good enough for your needs? In my experience, there are many attacks that aren't anticipated by the designers, but are successful. How can anyone know that you don't need privacy? Back in the dark ages, I was working with a protocol which provided the same basic assurances as TLS does: confidentiality, authentication, and integrity. It and TlS also provide some other important assurances, such a one-time, in order delivery, which we also depended on. When we looked at a similar protocol which didn't provide confidentiality, we discovered that there was application level data that needed to be kept secret or the application's assurances would be violated. In all honesty, it's probably cheaper to just provide confidentiality than it is to do the analysis and protocol proofs to show you don't need it. Cheers - Bill -- Bill Frantz| There are now so many exceptions to the 408-348-7900 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On 12/2/20 at 5:37 AM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote: The fact that many of these devices are extremely critical is precisely why they're never replaced or upgraded, because they can't be taken out of production. I would like to have a few more examples of "Can't be taken out of production". One I think I can address are heart pacemakers. These are imbedded in the patients chests. Upgrading them requires surgery. However, they have a limited lifespan due to their batteries running down, I think we're talking about 10 years or so, so there is a time where upgrade is practical. Every so often, the patient needs surgery to replace the batteries. During this surgery, the pacemaker function is taken over by equipment in the operating room. The questions here are: How much more surgical risk is there for replacing the whole pacemaker? If, as I suspect, the delta risk is zero, because replacing the battery also involves removing the old pacemaker, then battery replacement time is the time to perform pacemaker upgrades. How much risk is there in delaying upgrade to the next battery replacement? If we think about security risk, from now-vulnerable versions of TLS, then risk perception will depend on the individual patient. Vice President Dick Cheney was famous for being very concerned about being attacked via his pacemaker. In his case, he might have very well opted for early surgery to install an upgrade. Most others, I suspect, would chose to run the risks, at least until the first real-world attacks surface. Can anyone else work through some examples? Cheers - Bill - Bill Frantz| Government is not reason, it is not eloquence, it is force; like 408-348-7900 | a fire, a troublesome servant and a fearful master. Never for a www.pwpconsult.com | moment should it be left to irresponsible action. Geo Washington ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact
On 7/29/20 at 5:20 AM, furr...@gmail.com (Jen Linkova) wrote: So issuing the WGLC in the trough between IETF meetings caused an undesirable outcome of people not paying enough attention. But thanks for the comments, I'll take it into account - let's consider it my learning curve.. As a long-time lurker on the TLS list, I don't think these comments apply to the TLS working group. I see the ongoing business of draft, comment, new draft etc. going on continuously, only to be interrupted with email about IETF scheduling and agendas. I would suggest that anything requiring input from the TLS working group be presented between IETF meetings, when there are many TLS experts who will take the time to review and comment. Cheers - Bill --- Bill Frantz| "I wish there was a knob on the TV to turn up the 408-348-7900 | intelligence. There's a knob called "brightness", but www.pwpconsult.com | it doesn't work. -- Gallagher ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
On 2/1/20 at 7:43 PM, rs...@akamai.com (Salz, Rich) wrote: > +1 to what Nico says. Ditto. Cheers - Bill --- Bill Frantz| Security is like Government | Periwinkle (408)348-7900 | services. The market doesn't | 150 Rivermead Rd #235 www.pwpconsult.com | want to pay for them.| Peterborough, NH 03458 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-esni feedback
A perhaps radical suggestion: Make the server name field fixed length e.g. 256 bytes. Longer server names are not supported and clients MUST NOT send them. (Both client and server can't use them because they won't fit in the fixed length field.) Putting a limitation like this one into a protocol certainly can create problems, but we can look to the file system name situation for some insight. In the dark ages, file names were limited to a small number of characters -- 4, 5, or 6. I remember when the file system I used increased the limit to 8 characters, seeming like infinity for a few days. Finally some file systems raised the limit to 256 characters and I stopped hearing complaints that the length limit was a problem. With the suggestion, DNS lookups are padded to allow all 255 byte names to be represented in what is, in effect, a fixed length lookup string. Now people with more information about the problem can describe the problems this suggestion would cause. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01
On 4/4/19 at 11:22 PM, john.matts...@ericsson.com (John Mattsson) wrote: I think "this requires both endpoints to adopt the change simultaneously" is a problem as it makes it impossible to introduce this mechanism in many existing deployments. I would expect a solution that can be introduced gradually (some nodes at a time) in existing deployments supporting RFC 8446 and/or RFC 5246. Having seen a successful deployment and migration to a new incompatible version of a protocol, I think we too rapidly dismiss the possibility. In security protocols, we gain a lot of simplicity, and therefore security, by not having a compatibility mode. I wrote a short paper about this deployment for an amateur radio publication which I have included below. Cheers - Bill - Flag Day with FT8 Bill Frantz, AE6JV West Valley Amateur Radio Association Northern California DX Club Northern California Contest Club Abstract Recently a community of over 20,000 users did a conversion between release 1 and release 2 of a amateur radio digital communications protocol called FT8. The old version of the protocol was not compatible with the new version, resulting in a "flag day" event for users. However, the conversion was rapid and proceeded smoothly. Lessons from this conversion should be useful for other software projects. -- Introduction The new FT8 digital transmission mode has taken the amateur radio world by storm. Adoption has been overwhelmingly rapid, going from nothing at its first release in July 2017 to the most popular mode for many uses in December 2018. FT8 is the invention of Steven Franke, K9AN, and Joe Taylor, K1JT. (Joe won the Nobel Prize in Physics laureate for his discovery with Russell Hulse of a "new type of pulsar, a discovery that has opened up new possibilities for the study of gravitation."[1]) It is a "weak signal" mode using 50 Hz bandwidth for each signal, and can decode stations that are 24 dB below the voice signal bandwidth noise level. It is an evolving protocol and has recently been through a major change, from 75 bit messages to 77 bit messages. When you make a major change in a computer protocol, and indeed, FT8 is a computer protocol, there are two ways to introduce the change. (1) You can code the new protocol to inter-operate with the old protocol, or (2) you can have a "Flag Day" where everyone changes to the new protocol at the same time. (A "flag day" is when everyone has to adopt the new protocol at about the same time or lose connection with those who have adopted it.) Historically, computer engineers have avoided flag days like the plague. Getting everyone to change at the same time is almost impossible, and it is easier to design inter-operation. The FT8 implementors made the other choice; to have a flag day. It is interesting examine why they made that choice and how they succeeded with that choice. Bill Somerville, G4WJS reported on January 16, 2019 [2] "The situation with the 75-bit to 77-bit update of the FT8 protocol has several constraints that are uncommon elsewhere and particularly uncommon when they are all combined, including: "1) It is a communications protocol where every user wishes to be able to communicate with any other, 2) the old version will not understand the new protocol, at least without an upgrade, 3) WSJT-X is FOSS [Freee Open Source Software] with no charges for use or upgrade, 4) the core WSJT development team is tiny and has no wish to support multiple GA [General Availability] versions. "Given these constraints and a desire not to consume extra valuable digital modes bandwidth, any opportunity for old protocol users who do not wish to upgrade should be avoided. Having a new version that still talks the old protocol just exacerbates the potential schism of users since it allows those reluctant to upgrade to continue using the old protocol, at least until the number of indecipherable signals which are QRM [interference] to their decoder overwhelms them." Joe Taylor reported on January 17, 2019 [2]: "1. We published a schedule, three months in advance, specifying target dates for intermediate candidate releases for beta testing. We publicized this schedule as widely as possible, and we stuck to it. "2. The first three candidate releases included "bi-lingual" capability for the old and new protocols. This helped to encourage beta testing and feedback from interested users, and helped to show users that upgrading was a simple drop-in replacement. "3. Candidate releases 4 and 5 were "new protocol only". They allowed us to eliminate large amounts of obsolete code and fix most of the bugs introduced by these wholes
Re: [TLS] OCSP stapling problem
On 12/19/18 at 11:15 AM, ietf-d...@dukhovni.org (Viktor Dukhovni) wrote: > What I'd rather see is automation of certificate rotation, and > increasingly (decreasingly?) short certificate lifetimes as > with Let's Encrypt. I think what you wanted to say was "increasingly shorter certificate lifetimes" :-) Happy New Year - Bill ------- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] null auth ciphers for TLS 1.3?
On 8/22/18 at 6:55 PM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote: Is there any known actual use of raw public keys for TLS? I know of a case where TLS (aka SSL) was not used because of the lack of support for raw public keys. This work is 20 years old, but I'm not sure the situation has changed very much. The E programming language for distributed applications uses remote object references of the form objectID), where the key-fingerprint is the hash of the object supporting environment -- called a "Vat", and objectID is a large secret number. The Vats use a communication protocol called "Vat TP" <http://www.erights.org/elib/distrib/vattp/CommSystemOverview.html> to support remote object invocation. TL:DR As part of setting up a connection, the target Vat sends its public key and the initiating Vat checks the hash of that key. The connection parameters are validated by a signature over the entire connection dialog. Once the hash has authenticated the public key and the signature has validated the connection, the initiating Vat can safely send the objectID. There is a writeup explaining why SSL was not used <http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html> Cheers - Bill --- Bill Frantz| There's nothing so clear as | Periwinkle (408)356-8506 | a design you haven't written | 16345 Englewood Ave www.pwpconsult.com | down.- Dean Tribble | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] integrity only ciphersuites
On 8/21/18 at 7:24 AM, stephen.farr...@cs.tcd.ie (Stephen Farrell) wrote: I agree. Quoting the meat of the abstract of RFC8446: TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. I spent some time thinking about integrity protected, authenticated, replay resistant protocols during the late 1990s as the crypto wars were running hot and heavy. I decided the problem wasn't as simple as the fully encrypted protocols of which TLS is an example. A number of people have concerns about building connections with no secrecy, even when secrecy is desired by the endpoints, either because of specification errors or because of downgrade attacks. I share those concerns, and would be willing to consider a protocol that uses entirely different packet identifiers from those used by TLS as a way to reduce this problem. I do think that the TLS working group is well qualified to analyse the design of such a protocol. Cheers - Bill --- Bill Frantz| Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] integrity only ciphersuites
One area where there is a need for an integrity and authentication only suite is in amateur radio systems. In amateur radio, any encoding scheme which hides the meaning of a message is against the FCC regulations. However, remote control by radio could benefit from both integrity and authentication. The FCC regulations recognize this need and permit encryption of messages controlling amateur radio satellites. Amateur radio digital protocols include some state of the art error detection and correction techniques, providing a kind of integrity, but they do not provide authentication. Amateurs have gotten by with a combination of very primitive authentication techniques and legal action after tracking attackers with radio direction finding. While I'm not sure that this application area is important enough to be addressed by the TLS working group, if there are other application areas with similar needs, then perhaps these needs should be addressed. Cheers - Bill -- Bill Frantz| There are now so many exceptions to the 408-356-8506 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
On 6/25/18 at 9:20 PM, j...@salowey.net (Joseph Salowey) wrote: Hi Folks, There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for modifications in the revision. Please respond to the following questions on the list by July 10, 2018. 1. Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)? I would like to see a pinning mechanism, and think this Working Group is the right place to move the idea forward. 2. Do you support the reserved bytes in the revision for a future pinning mechanism? Yes. 3. Do you support the proof of denial of existence text in the revision? I had difficulty reading the GitHub thread. 4. Do you support the new and improved security considerations? ditto Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On 4/16/18 at 9:31 AM, n...@cryptonector.com (Nico Williams) wrote: I wouldn't mind a (C'): a variant of (C) where we get denial of existence and a one- or two-byte TTL (one by count of weeks or two-byte count of hours) with de minimis text about it, leaving pinning semantics to a separate document. In such a (C') we'd elide all pinning (or most*) in this document. I have always worried about the trust model in PKIX, and thought that some form of pinning would an excellent enhancement -- modeling how individuals work in the real world: Alice, I'd like you to meet Bob. He is an expert in... (Alice learns Bob's voice pattern.) Bob, this is Alice, I'd like you to... (Alice recognizes Bob's voice in the reply.) I strongly support C or C' as the best way forward, allowing a future RFC to address the pinning details. Viktor has some good suggestions as well. Note: I have not been involved in any face-to-face meetings or hums. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
On 3/30/18 at 7:35 PM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote: As you mention, debugging TLS is unnecessarily painful if there's a problem, you typically just get a handshake-failed alert which is essentially no information at all. Having a debug-mode capability to send back a long-form error message would be extremely useful, maybe an extension to say "send back a long-form alert with more than just 'BOOLEAN succeeded = FALSE' in it". We have always avoided the long form error messages in TLS because they can be of great help to attackers as well as debuggers. I think this objection is much weaker if we write the long form error messages into a log that is kept with other server logs. Cheers - Bill --- Bill Frantz| Ham radio contesting is a| Periwinkle (408)356-8506 | contact sport. | 16345 Englewood Ave www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-01.txt
The discussion of this draft makes it sound like implementations will have additional complexity to support certificate compression. Complexity adds security risks, so just how much benefit does certificate compression provide? My naive thinking is that most of the data in certificates is signatures, which shouldn't be very compressible. Of course, for small systems, even a small improvement may be important. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] chairs - please shutdown wiretapping discussion...
I must admit that I mostly agree with Stephan that this kind of thing should not exist. However, it exists now, and the chairs have decided we should at least discuss it. I think there are many ways to meet the "requirements" of network monitoring and protocol debugging, and some are worse than others. Leading the world in the direction of the least damaging ones seems to be the bese way to deal with a bad situation. The major threats I see include: Coerced use by oppressive governments. Use outside the immediate private network Use by an ISP on its customers Use without both ends being aware that it is in use. I think coerced use is by oppressive governments is an obvious bad and I hope I have working group agreement on this point. Limiting the protocol to the immediate private network will prevent 3rd parties from activating it to spy on the enterprise. One possible way to enforce this limitation is to require compliant implementations to limit broadcast of decryption information to the IP addresses on the local subnet. I would be nice to be able to keep an ISP from spying on its customers as part of its "private network". However, I don't see how to differentiate an ISP's network from a enterprise network. If it is not technically possible to use the protocol without both ends being aware that it is in use, then user interfaces can reflect its use. One result would be that enterprise users would be continually warned that their messages aren't private. Any technical fixes we build into the protocol that prevent these actions are a positive improvement. Cheers - Bill --- Bill Frantz| If you want total security, go to prison. There you're 408-356-8506 | fed, clothed, given medical care and so on. The only www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD Review of draft-ietf-tls-tls13
On 5/22/17 at 10:46 AM, ietf-d...@dukhovni.org (Viktor Dukhovni) wrote: On May 22, 2017, at 1:37 PM, Salz, Rich <rs...@akamai.com> wrote: I strongly believe the text should stay as it is, for the most good to the most people. Viktor is in the weeds, arguably by himself. Right, all by myself... With support from Nico, Ilari, and others who've upthread accepted that certificate verification is properly RFC5280 and not TLS, before I suggested removal of the text in question (which solves no real problem, but does create needless interoperability issues for various TLS use-cases). Please allow me to add my voice to Viktor's. When I wrote the E language communication protocol, many people said I should use SSL. Some of the reasons we did not use SSL are in a 1998 document <http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html>. Our protocol started with a hash of the peer's public key. With that bit of information, other authentications are unnecessary. If I were starting today, we could use TLS with PSKs by asking the other side for it's key and then using it with a TLS library (I think). Cheers - Bill --- Bill Frantz|"Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges" - Mark Miller www.pwpconsult.com | ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Idempotency and the application developer
On 5/4/17 at 4:47 PM, c...@allcosts.net (Colm MacCárthaigh) wrote: I think you're right; and we could enforce in TLS by encrypting 0-RTT under a key that isn't transmitted until 1-RTT. This might be a generally useful pattern for 0-RTT use cases that are trying to get large quantities of data to the server quickly. BTW, I expect to see lots of security bugs due to 0-RTT. But the Internet and computer operating systems are insecure anyway. Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
On 12/2/16 at 8:48 PM, rs...@akamai.com (Salz, Rich) wrote: And also, the world will not care about a gap in numbering. Nobody cared that there was no Windows 9. If we go with 2017, we can tell the world that by using the year the standard was approved, instead of a confusing set of names and numbers, we are eliminating any confusion about which version is the most recent. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3
On 11/29/16 at 5:28 AM, rs...@akamai.com (Salz, Rich) wrote: Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" -- see https://en.wikipedia.org/wiki/Zip_bomb The risks of uncompressing data sent from a counterparty who has not yet been authenticated, do not outweigh the gains. There is a long history of successful attacks on systems through zip decompressors. In general, adding complexity to a security system makes it harder to understand, easier to compromise and less secure. If the problem is that certificates are too big, fix that problem at the source. Cheers - Bill --- Bill Frantz| Privacy is dead, get over| Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
On 11/21/16 at 4:56 PM, d...@cr.yp.to (D. J. Bernstein) wrote: The messages on the list seem to be perfectly split between "TLS 1.3" and "TLS 4". I suspect that the "TLS 2017" idea will break this impasse: * it shares the fundamental advantage that led to the "TLS 4" idea; * it has the additional advantage of making the age obvious; * it eliminates the "4 sounds too much like 3" complaint; and * it eliminates the "where are TLS 2 and TLS 3?" complaint. Perhaps it's worth starting a poll specifically between "TLS 1.3" and "TLS 2017"? Or at least asking whether the new "TLS 2017" option would swing some previous opinions? Of course people who prioritize retaining the existing "TLS 1.3" mindshare will be just as unhappy with "TLS 2017" as with "TLS 4", but they'll get over it within a few years. :-) The Ecmascript standards body, TC39 has moved to year === version. It seems to work well for them. I don't think that using a year means that there will be a new standard every year. In the unlikely event that there is a standard bug bad enough to need a second standard in one year, decimal version(s) could be used e.g 2017.1. It would be understandable and act as punishment for us who screwed up. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
On 9/28/16 at 4:27 PM, melinda.sh...@nomountain.net (Melinda Shore) wrote: That said, IETF participation is dominated by large equipment and software vendors and the problem space, at least until recently (there's been a crop of data center-related problems coming up in OPS and routing), has tended to cover service provider-related questions. We have poor participation and representation from enterprise networks. So now we've got someone showing up from the enterprise space and saying "I have this problem related to protocol changes." And yeah, he's very, very late in this process, although it's worth pointing out that it's in the best tradition of the IETF to deal with technical problems that crop up with documents at any point in their development. While I fully support trying to design protocols so applications and networks can be managed by enterprises (and indeed home users), I do not want to see IETF security protocols become more complex as a result. That will only make them easy targets for attackers. The Clipper chip shows what happens when even experts design key recovery systems. I hope one outcome of this thread is that industry groups which use IETF protocols will realize that the best way to have their needs recognized is to be active in the relevant groups from the beginning and for the long term. I know of no other way to make the proper tradeoffs except to have all the issues in front of the working group from the beginning of their process. That involvement will strengthen the IETF while making sure enterprise issues are addressed. Even as late comers to the process, BITS Security has gotten a number of suggestions for ways forward which do not change the emerging TLS 1.3 standard. Given that it will be several years before regulators require TLS 1.3, vendors will be able step forward to fill this need with endpoint logging as well as other techniques embedded in "install and run" products. Given the list of companies that Tony linked, these products should enjoy a profitable market. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Industry Concerns about TLS 1.3
On 9/23/16 at 2:24 PM, bitssecur...@fsroundtable.org (BITS Security) wrote: But general-purpose messaging services (and other collaboration services) which don’t have an explicit man-in-the-middle (and don’t permit server-side access to user plaintext and can’t be observed by other means) can’t be used in supervised environments. This rules out many cloud-hosted services today. I see a train wreck coming and it looks like this: The public internet, Google, Cloud services, Facebook, Twitter, etc. etc. move in the direction of improving security using things like PFS, because the idea of protecting human rights advocates in the parts of the world where people are routinely tortured sells well to the general public, people like me, and others on this list. On the other hand, some major enterprises continue to depend on being able to break the security of their employees to monitor their networks in ways that the bad guys can easily use, as opposed to installing endpoint or gateway monitoring. This train wreck results in fewer and fewer public internet services being available to users within these enterprises. Eventually, employees give up on the corporate network and start using their cell phones to communicate with customers, research investments etc., completely bypassing the regulatory required monitoring. This scenario says it doesn't matter whether TLS 1.3 and successors allows RSA. If they have any PFS modes, these will be the only ones public internet servers will accept. If they are turned off in enterprise clients, they will not be able to connect without going through a gateway which turns them on. My conclusion is that enterprises that depend on being able to decrypt traffic without involving the endpoints should start moving to systems that do involve the endpoints. Cheers - Bill --- Bill Frantz| Ham radio contesting is a| Periwinkle (408)356-8506 | contact sport. | 16345 Englewood Ave www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
We could call it TLS 3.4 which would match the internal ID. :-) BTW, I think using something other than 1.3 is a good idea. Cheers - Bill - Bill Frantz| When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simpler backward compatibility rules for 0-RTT
On 6/22/16 at 5:24 PM, martin.thom...@gmail.com (Martin Thomson) wrote: To be clear about this, I expect that browsers will do some fairly horrific things in response to this. We will attempt to use 0-RTT, get TLS 1.2 and abort as described. But then we will do the shameful thing and fall back to 1.2. Plotting out the alternatives, I don't really see a better option. Well, it seems like a browser could try TLS 1.3 without 0-RTT first. If it connects with 1.3 non-0-RTT, then it could mark the host as not supporting 0-RTT for a day or so and after that time retry to see if the host has been fixed. Cheers - Bill --- Bill Frantz| Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]
On 6/3/16 at 2:28 AM, hka...@redhat.com (Hubert Kario) wrote: That being said, I would prefer the solution to be a compliance test suite that checks if servers do handle correctly future versions, future extensions and future ciphersuites correctly. I agree with Hubert. The big question is how you get the bug report to the server operator. With servers which are currently maintained, it should be possible, although difficult in specific instances to contact the owner. With servers which aren't being maintained, e.g. those in imbedded devices, the problem becomes much harder. If the client has a UI, it could explain the problem to the user and ask if the user wants to continue with degraded security. If so, then always use the remembered highest supported version with that server domain name, with perhaps occasional reminders to the user of the situation. In any case, we should be addressing our efforts to getting bugs fixed, not just coding around them. Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Asymmetric TLS
To avoid a lot of "Over my dead body" comments, these requirements should be met with a very visible man in the middle and two (or more) TLS sessions. This architecture should provide some security from unwanted men in the middle, as well as making it obvious to the endpoints who that man in the middle is. Cheers - Bill On 4/5/16 at 10:29 AM, s...@sn3rd.com (Sean Turner) wrote: With my chair hat on, I won’t comment one way or the other on whether this should be done, but we have gone down this path before. As I recall, the proposal was pretty resoundingly rejected. But, what I will say as chair is that this would most definitely require a charter change for the WG. spt On Apr 04, 2016, at 14:24, Phil Lello <p...@dunlop-lello.uk> wrote: Hi, I have a use-case for allowing an MITM to monitor traffic, but not impersonate a server, and to allow MITM signing for replay of server-responses to support caching. As far as I'm aware, TLS currently only supports a shared-secret once session initialisation is complete, so I'd need to extend the protocol to support asymmetric encryption for the session. Would there be interest in extending TLS to: - allow monitoring-with-consent (based on asymmetric encryption)? - allow re-signing from an authorised MITM to support caching? Best wishes, Phil Lello --- Bill Frantz|"Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges" - Mark Miller www.pwpconsult.com | ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
+1 for the change. On 3/30/16 at 1:26 PM, ynir.i...@gmail.com (Yoav Nir) wrote: That brings up another question. How do things move from “approved” to “not-approved”? Does it require a diediedie document? What happens when we decide that 3DES is just too limited and there’s not good reason to use it, but there’s really no security issue with using it? Certainly for downgrading any widely deployed algorithm, e.g. RC4, there needs to be a IETF process. The RFC process works, so we don't need to invent a new wheel. Therefore a diediedie RFC seems the logical choice. I hope algorithms don't get on the approved list unless they are likely to be widely deployed. (But I expect to see counter-arguments.) Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS1.3 status/expectations
On 2/29/16 at 6:45 AM, s...@sn3rd.com (Sean Turner) wrote: One thing that was reinforced at TRON and we think the TLS WG should be aware of is that the research community needs time to do their analysis. With that in mind, the chairs are very strongly leaning towards an extended WGLC of 6 weeks. I strongly support giving the research community enough time to analyze the protocol. Their methodology offers a different way of looking at security issues, and has already demonstrated its effectiveness at discovering protocol bugs. Cheers - Bill --- Bill Frantz| Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345 Englewood Ave www.pwpconsult.com |- Jeff Frantz | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Controlling use of SHA-1
On 10/23/15 at 2:02 PM, ynir.i...@gmail.com (Yoav Nir) wrote: That is true only if your application’s client component and server component are using the same library. That is not guaranteed in a protocol. Specifically that is not the case with the web. There are some version intolerant servers out there that will choke on seeing a TLS 1.3 ClientHello. If the client uses some library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that has TLS 1.3. All of the sudden your application is broken. On the web this means that some websites don’t work. This incompatibility cuts both ways. Another way of looking at it is that all of a sudden your website has lost viewers and you should fix your problem. Perhaps I am unusual, but if I go the a website that doesn't work, I usually conclude that I don't need to see that web site. My problem is too little time, meaning I don't want to bleep with things that don't work, not extra time to futz with different browsers to get things working. Cheers - Bill - Bill Frantz| Airline peanut bag: "Produced | Periwinkle (408)356-8506 | in a facility that processes | 16345 Englewood Ave www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032 ___ 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 9/23/15 at 4:17 PM, noloa...@gmail.com (Jeffrey Walton) wrote: IMHO, compression adds too many security vulnerabilities to a general purpose secure communication protocol. I think TLS 1.3 is right in eliminating it. It is too big a foot gun. To play devil's advocate: if (1) compression increases attack surface and (2) people use compression, then wouldn't the best place to address it be in a protocol or security library rather than pushing it into a higher level in the stack where it likely won't be addressed? Well, it depends. How much security do people need. In the NNTP case, I can't see a strong argument for confidentiality. There may be a need for compression, which is why I suggested a "TLC" (Transport Level Compression) facility, which is, to the extent possible, API compatible with a TLS library. I do have a lot of sympathy with those who have been using compression in previous versions of TLS. Probably the best solution for them is to have a TLS like library which only does compression. It could be largely API compatible so switching between TLS and compression is a relatively easy programming job. I'll let the TLS implementers say just how hard such a library would be to produce. OpenSSL currently has an configuration option to build without compression methods (no-comp). I usually build OpenSSL without compression, and OWASP recommends building without compression (https://www.owasp.org/index.php/C-Based_Toolchain_Hardening). What we need for NNTP is a build without security, but with compression option. Cheers - Bill --- Bill Frantz| Ham radio contesting is a| Periwinkle (408)356-8506 | contact sport. | 16345 Englewood Ave www.pwpconsult.com | - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On 9/16/15 at 4:23 PM, n...@cryptonector.com (Nico Williams) wrote: Whichever one is removed, I shall oppose the removal of the other. On 9/17/15 at 5:21 PM, ietf-d...@dukhovni.org (Viktor Dukhovni) wrote: The costs are likely noticeable for 4096-bit RSA keys. In the end though, if dropping anon_(EC)DH increases the chance that RPK gets widely implemented, I can live with the cons. I agree with both Nico and Viktor. For me the big win of RPK over anon_(EC)DH is it allows TOFU. If TOFU isn't needed, short public keys should ease many of Viktor's cons. I also like the idea of simpler implementations. For the question that started this thread, I am neutral. Cheers - Bill -- Bill Frantz| There are now so many exceptions to the 408-356-8506 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
