Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?
On Wed, 05 Oct 2022 13:39:32 +1100 "Martin Thomson" wrote: > The integrity of TLS doesn't depend on the key holder presenting > proof of possession toward the issuing CA. Perhaps we could define > an extension that produced an empty signature, so that it could be > used for any algorithm without these complications... You are of course right that from the basic security properties of TLS there is no need for a certificate requester to show key possession. However I always considered this self-signature a kind of safeguard that will in practice prevent a number of issues: * People don't understand how keys and certificates work and will use a public key from someone else. * It will likely prevent various kinds of malformed or corrupted keys to be present in certificates that are unable to generate valid signatures. I find these desirable features that likely let things fail early in various situations where things go wrong. -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP in RFC7525bis
Reading the discussion so far I want to raise something to consider. There are separate questions that shouldn't be confused: 1. Is OCSP stapling with soft-fail (absent further enforcement mechanisms like muststaple) actually useful? 2. Should server operators enable OCSP stapling? For 1. one can reasonably argue that it is not, as an attacker can potentially rely on the softfail property. However for a server operator the question isn't just whether OCSP stapling serves its purpose. A server operator naturally will have to deal with a variety of clients that have a variety of behaviors. Some clients will do OCSP requests when no stapled response is sent. Thus even if you think OCSP stapling and the whole process of revocation is useless, there are still good reasons for a server operator to enable stapling: 1. It avoids an extra connection for clients to the OCSP server, thus making client connections potentially faster. 2. It avoids a potential privacy issue for clients who would otherwise leak their intent to connect to a specific host to their CA. tl;dr I think enabling OCSP stapling on servers almost always makes sense. -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP in RFC7525bis
Hi,
On Wed, 19 Jan 2022 16:57:07 +0200
Yaron Sheffer wrote:
> But this raises a larger question: many client-side implementations
> soft-fail if they don’t get an OCSP response within the handshake,
> i.e. they just ignore the problem. As far as we understand, this
> makes OCSP stapling completely ineffective for what it’s trying to
> solve.
I think the missing piece here is the so-called OCSP "must staple"
extension (RFC 7633).
This allows telling a client in the certificate that a certificate may
only be used if it has a valid staple.
This hasn't seen widespread use yet as far as I know, and one reason is
that up until recently major OCSP stapling implementations were quite
fragile and would behave strangely under conditions like the CA being
offline (kinda also defeating the purpose of stapling). Adding a
hard-fail stapling requirement to a fragile stapling implementation is
not a good idea. This has improvde in Apache recently, however requires
a maybe not widely known option ("MDStapling") that is not the default.
I'm not sure about the situation in nginx.
--
Hanno Böck
https://hboeck.de/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Does TLS support ECDHE based SEED cipher suites?
On Thu, 30 Dec 2021 15:56:02 +0800 M K Saravanan wrote: > Does anyone know whether any ECDHE based cipher suites were added for > SEED for TLS? I don't know what the background for this request is, but I'd like to point out that we had similar discussions in the past about obscure ciphers (look for brainpool curves) in the past. This is my personal opinion, but I think it is widely shared among many in the community: It used to be that the TLS community valued supporting as many ciphers as possible. But this has more or less ended with TLS 1.3, which is part of a larger realization in IT security that unnecessary complexity is usually bad and should be avoided. Instead the trend is to support a small set of algorithms that are generally considered "okay-ish" (there are always minor ups and downs of certain cipher choices) and leave it with that and not seek to support a wide variety of algorithms. I'd oppose any specification of new cipher suites without a good justification, and I think this is an opinion many here share. -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] supported_versions in TLS 1.2
On Tue, 16 Nov 2021 08:36:31 -0700 Peter Saint-Andre wrote: > By our reading, it doesn't make any difference to a TLS 1.2 > implementation whether it sends or receives the "supported_versions" > extension. Corrections welcome, of course! If this is the case, we'd > prefer not to recommend that TLS 1.2 implementations specifically add > support for this extension, since upgrading to TLS 1.3 is best anyway. I have a question about this question: I think it's generally agreed that TLS 1.3 provides much better security than TLS 1.2 (that was ultimately why it's been created). Why would you even write a recommendation for what people should do with TLS 1.2-only implementations? (I understand this is merely relevant for implementations not supporting TLS 1.3 at all.) Shouldn't the recommendation be: "Don't. Please support TLS 1.3." ? -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS RRC and heartbeat
On Thu, 21 Oct 2021 10:35:54 +0100 Thomas Fossati wrote: > One problem is - as Hannes put it - that heartbeat has a "somewhat > tricky history", making its marketing a slightly intricate operation, > and the code reuse story a bit more complicated than desired (see for > example [3]). I think there were a few things that went spectacularly wrong with the original heartbeat extension. Some of them are implementation issues (like merging code without proper review and testing), but others are in the spec itself. I think this boils down to two things that added unnecessary complexity, which is always bad in security: 1. The use cases were all UDP, but the extension was defined for both UDP and TCP for no good reason. 2. The extension contained a completely unnecessary length-encoded message that was sent forth and back. That's a very risky construction in terms of memory safety. I feel this may be enough justification to define a hearbeat-simplified spec that doesn't have these problems. If you decide to go with the old heartbeat extension then I'd still wish you at least adress 1. I think many people have just compiled openssl without heartbeat, which is a good thing as long as it's not used anyway. If it gets used in DTLS then at least make sure that doesn't mean it also has to be enabled in TCP-based normal TLS at the same time. -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Obsoleting SCSV in draft-ietf-tls-oldversions-deprecate
On Tue, 10 Nov 2020 20:40:57 +0200 Yaron Sheffer wrote: > I think marking the “oldversions” draft as “obsoletes RFC 7507 > (SCSV)” is not great from an ecosystem point of view. People will > interpret it as “no need to implement SCSV in new code, no need to > expose it as a configuration option in existing code”. And we know > that some admins will continue to allow downgrade to TLS 1.0/1.1 no > matter what we tell them. Is this true? To clarify: We're not talking about people supporting TLS 1.0/1.1 (of which there are obviously still many), we're talking about clients doing out-of-protocol downgrade dances where they will attempt to connect via TLS 1.0/1.1 if TLS 1.2 connections fail. That's the only scenario where SCSV is needed. AFAIK the only clients that ever did these out of protocol downgrades were browsers and they all disabled this behavior in the meantime. I would assume it's very likely that SCSV serves no useful purpose today and hasn't done so for years. -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Sending Custom DHE Parameters in TLS 1.3
Hi, There was a reason custom DH parameters were removed. Custom DH parameters were the source of plenty of problems. I suggest reading: https://blog.hboeck.de/archives/841-Diffie-Hellman-and-TLS-with-nonsense-parameters.html https://eprint.iacr.org/2016/644 https://www.openssl.org/news/secadv/20160128.txt There's also a more general theme I think what we have learned over time: Moving parts in crypto protocols are bad, simplicity is good. Fix as much as you can, avoid negotiating stuff. This is not talked about that much explicitly, but it is a major change of how crypto protocols were designed in the past (i.e. TLS 1.2 times) where it was often considered desirable to add as much flexibility as possible. (Also FWIW the relevance of DH is pretty small these days. I think the largest web clients simply don't support it at all.) -- Hanno Böck https://hboeck.de/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC
Hi, On Tue, 26 Feb 2019 21:26:45 + Jack Visoky wrote: > We have done tests on this and it there is a difference. Have these tests in any way been published? Because otherwise it's a very weak argument. There are some obvious questions, e.g.: * What algorithm implementation was tested, was it optimized for the architecture in question and was it considered whether the optimization could be improved or maybe even whether already a more optimized implementation exists? * Have you tried both AES and chacha20? And in both cases the most optimized implementation for the target plattform? * If the bottleneck is the cipher have you considered whether a different cipher that provides reasonable security, but can be implemented better on lightweight hardware, would be an alternative? (Not keen having that option, I believe fewer options are better.) > This probably goes without > saying but of course the best line of defense is to properly design, > build, and configure the implementation. I'm inclined to say that this is an outdated view of how to best do security in protocols. We had plenty of situations in the past where the TLS spec was a minefield of possible implementation mistakes that led to long descriptions on how to properly design things to avoid these mistakes. History shows it didn't work. (Let me just throw in "Padding Oracles" or "Bleichenbacher attacks" as very obvious examples.) My takeaway and I believe that of many people is that the protocol should avoid implementation pitfalls whereever possible. And I believe an authentication-only ciphersuite is a dangerous implementation pitfall. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Authentication Only Ciphersuites RFC
I think I have raised my concerns before, but I have serious doubts there's real need for such ciphersuites. The reasoning seems to be that performance constrained devices are unable to do "normal" TLS. I don't have benchmarks, but it's my experience that people vastly overestimate the costs of symmetric encryption operations (by far the largest computational cost of TLS is the asymmetric handshake). I wonder if the people who believe they need an authentication only ciphersuite ever ran tests. I also see a non-neglegible risk in standardizing such ciphersuites. Some implementations will end up adding them and coupled with implementation flaws we may end up in a situation where inadvertently insecure ciphersuites are chosen. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 updates from Chrome
Hi, Thanks for that interesting explanation. I just learned about another TLS 1.3 "intolerance" issue that people deploying it should be aware of: It seems some servers don't consider TLS 1.3 cipher suites as "safe" for HTTP/2 and this breaks connections: https://bugzilla.mozilla.org/show_bug.cgi?id=1488240#c39 While HTTP/2 is not necessarily the focus of this group I wonder what that means, how HTTP/2 implementations should be made future proof and if there can be a GREASE-like mechanism for it. Whitelisting "safe" ciphers seems to be a bad idea and almost inevitably will lead to more trouble in the future. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG: New Version Notification for draft-bruckert-brainpool-for-tls13-00.txt
On Sun, 2 Sep 2018 13:30:45 + "Bruckert, Leonie" wrote: > We submitted an Internet Draft defining the usage of the Brainpool > Curves for TLS 1.3. This draft doesn't contain any motivation on why anyone would want this. I believe it's not desirable to have a maximally large number of algorithms specified for TLS. To the contrary, I believe it'd be good to keep things as simple as possible and limit choices if there's no good reason for them. I don't think there's any reason for the brainpool curves except NIH syndrome. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?
Hi, I think there's been a mentality change in the TLS community that explains this. Back when Brainpool curves were standardized there was a "more is better" mentality when it came to algorithms. I.e. if an algorithm is not broken it's good to have it in TLS. Particularly all kinds of nationalized algs made it into TLS. There's a very strong reason against this: It creates complexity. More opportunities for attacks, more fragmentation of the ecosystem. I believe I speak for a lot of people here when I say that fewer algorithms is better and having more algs "just because" is not a good reason. With that in mind an algorithm doesn't have to be weak to be removed from TLS. It's reason enough if it's rarely used and doesn't have a significant advantage over alternatives. Brainpool curves were never widely used in mainstream deployments of TLS (aka browsers). They have no significant advantage over the other choices. They pretty much exist because Germany wanted to have their homegrown crypto algorithm, too, meaning they exist for nationalistic reasons, not technical ones. So deprecating them has the same reason we don't have SEED or Camellia in TLS any more. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI
So-called "Enterprise" infrastructure has delayed the work of this group for at least a year. Noone of the people creating that mess has reached out to this group to explain why they constantly break TLS - let alone apologize for it. I believe there's a large overlap of the actors breaking TLS with the actors who are worried about things like SNI encryption. I'm not sure I see any reason not to consider these actors as anything but opposed to the work of this group. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The future devices that will break TLS 1.4
On Fri, 12 Jan 2018 15:53:05 -0800
Dan Wing wrote:
> Those bugs that interfere with TLS handshakes are un-related to
> Cisco's Encrypted Traffic Analytics ("ETA"). Different technologies.
I haven't claimed that.
I just think it's very plausible to assume that a company that
already created two independent problems for TLS 1.3 will do the same in
future products that mess with TLS in "new and exciting ways".
And for the unlikely case that Cisco is able to learn from past mistakes
I'm absolutely sure there will be others creating similar products that
won't.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] The future devices that will break TLS 1.4
Hi, This working group just went through a painful process of realizing that deploying a new TLS version on the Internet is a hard task due to broken devices. If you're not aware David Benjamin just gave a great talk summarizing the issues: https://www.youtube.com/watch?v=_mE_JmwFi1Y Today I found this article: https://www.theregister.co.uk/2018/01/11/cisco_sniff_malware_inside_encrypted_traffic/ tl;dr Cisco now says they can identify malware in TLS traffic by carefully looking at it. (For context: devices from Cisco were responsible for many of the issues that made deploying TLS 1.3 hard, e.g. version intolerance on load balancers and recently by not correctly terminating TLS in a firewall.) I'll dare to have a look into the future and make this imho very plausible claim: Cisco won't be the only vendor selling such things. We will see more products that magically can identify "bad things" in TLS traffic by applying everything from AI to Blockchain. We will almost certainly see a whole new generation of devices doing weirdness with TLS and who will drop or manipulate packages that contain things they don't know (like... a version negotiation field with TLS 1.4 or a large post quantum key exchange message). The question I want to ask: What can we do *now* to stop this from happening when TLS 1.4 will be deployed? I have the feeling GREASE won't be enough... -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
On Fri, 15 Dec 2017 11:47:54 -0500 Kathleen Moriarty wrote: > Is there a reason why a migration to PCKS #1 v2.2 doesn't help for TLS > 1.2 and prior? I haven't noticed any discussion on that previously. Is > it just the code base and not those using it being unwilling to > upgrade supporting libraries? It depends... particularly if we talk about encryption or signatures. With Bleichenbacher attacks there are plenty of cross-protocol attack possibilities, this was one of the papers at the TRON workshop: https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf While I believe we certainly can't get rid of PKCS #1 1.5 signatures any time soon, I think we can get rid of PKCS #1 1.5 encryption (at least on the server side for HTTPS). The number of legit connections is really low. If you run servers please check if you can do that. (I'm also considering writing an RSA-kex-diediedie RFC when I find time for it.) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
On Thu, 14 Dec 2017 16:45:57 -0800 Colm MacCárthaigh wrote: > But what would that look like? What would we do now, in advance, to > make it easy to turn off AES? For example. I think this is the wrong way to look at it. From what I'm aware nobody is really concerned about the security of AES. I don't think that there's any need to prepare for turning off AES. The problem with PKCS #1 v1.5 is that it survived so long *after* its was known that it was bad. I really recommend everyone who wants to know how protocols go bad to read up on the Bleichenbacher countermeasures in TLS 1.0, 1.1 and 1.2 - and particularly the last one. The chapter in 1.2 is a nightmare and I seriously fail to understand how anyone could have seen that and think it's a good idea to do that in order to stay compatible with a standard that was already deprecated at that point. We know that when this group decided to deprecate both PKCS #1 1.5 and RSA encryption that there were people trying to lobby against that. I'm glad that this wasn't successful. I think the takeaway is just as simple as this: If you know an algorithm is bad get rid of it and don't try to "rescue" it over into the next protocol. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ 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
Hi, The deployment of TLS 1.3 was delayed because Internet middleboxes broke when they saw unknown TLS data. I guess it's plausible to assume that the same problem will show up with compressed certificates. Has any thought been given to that? -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 draft 22 middlebox interaction
On Fri, 01 Dec 2017 09:47:45 -0500 R du Toit wrote: > The middlebox in question supports TLS 1.3, but only drafts 18 > through 21. The FF Nightly ClientHello supported_versions extension > advertises support for TLS 1.2 and TLS 1.3 (draft 22), Sorry, can you please name names here? In what universe does this make any sense? The middlebox shouldn't look at specific TLS versions. And it certainly shouldn't look at specific TLS 1.3 drafts. It should just leave the traffic alone. Doing anything of the form "we'll accept traffic of TLS version X, but not of any version unknown to us" is certain to cause breakage in the future. Whoever built this is harming the Internet, full stop. I really don't understand why there is such intransparency over this issue. Why can't we at least make clear who are the companies responsible for this nonsense? -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Update on TLS 1.3 Middlebox Issues
Hi, On Fri, 6 Oct 2017 13:16:37 -0700 Eric Rescorla wrote: > - Fall back to TLS 1.2 (as we have unfortunately done for previous > releases) Thinking about this I honestly hope nobody is considering this seriously. This would be an unfixable security design flaw. And it also quite significantly differs from previous fallbacks. There were workarounds in the past for version intolerance by using SCSV and early versions of 1.3 used some trick with the server random value. However that was for nonconformant servers that allowed conformant servers and clients to prevent downgrade attacks. Such workarounds won't work if we talk about middleboxes, because what's proposed here is to fallback to TLS 1.2 even if both the server and the client speak TLS 1.3. In other words: It's a proposal to make all security advantages of TLS 1.3 irrelevant, as we have a universal downgrade to 1.2. Given that this would also mean there's no visible incentive to fix things it would very likely mean keeping this broken workaround for many years to come. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Update on TLS 1.3 Middlebox Issues
Alternative proposal: 1. Identify the responsible vendors. 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh, it's your customers who don't update? Seems you don't have any reasonable update system. Call your customers, send some support staff to them. Fix this. Now." 3. Call for a boycott of the vendors who are not able to fix this. Seriously... If only 2 or 3 of the large companies that are involved here would do this I am sure we don't have such problems any more in the future. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] adopted: draft-ghedini-tls-certificate-compression
On Tue, 6 Jun 2017 09:20:03 +0200 Sean Turner wrote: > I appears that we’ve got enough consensus/interest to adopt > draft-ghedini-tls-certificate-compression-00 based on the WG session > in Chicago and this thread: Hi, one aspects brought up in that thread was that there is already RFC 7924, which allows certificate caching. There's also AIA, which allows a client to fetch intermediate certificates, however as far as I can see there's no way for a server to decide whether a client supports AIA. All of these technologies seem to try to tackle the same problem: reduce the burden of transmitting certificates. I wonder if there should be more a big picture discussion here. If clients have a good way of caching certificates - would that mean transmitting them is so rare that compressing becomes unnecessary? Also regarding 7924: I tried to find out what server and client software supports that. I didn't find anything. One could see that as an indication that it's not a big deal after all. If people are concerned about the data wasted by transmitting certificates, I wonder if it wouldn't be a more important issue to implement the already existing tech that's available instead of inventing new tech. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Support of integrity only cipher suites in TLS 1.3
On Mon, 3 Apr 2017 16:17:45 + "Fries, Steffen" wrote: > The reason I'm asking is that in industrial communication it is often > sufficient to have source authentication and message integrity while > probes on the network are still able to monitor the traffic for > certain properties or verify allowed exchanges. An example is ICCP > for inter control center communication. The two control center are > connected via an IPSec tunnel terminated in the DMZ. The desire is to > have the TLS tunnel end-to-end to allow for source authentication and > also for message integrity, while doing traffic inspection in the > DMZ. There exist other scenarios, with a similar requirement. Adding such a mode would add additional complexity that might lead to vulnerabiltiies, e.g. implementations that can be tricked into using a nonencrypted mode. It's been a trend in the tls working group to a) reduce complexity when possible. b) not try to accomodate obscure use cases that aren't relevant for the majority of TLS use cases. Thus I assume a null cipher won't find support here. If you want to have traffic inspection with TLS imho the right way is to support that at the end points (let alone any arguments why you're doing traffic inspection in the first place and whether those reasons are good ones). If you don't like that then TLS may be not the right protocol for your use case. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS 1.3 / RSA-PSS and unusual key sizes
Hi, I wanted to warn people about a potential source of bugs with the deployment of RSA-PSS in TLS 1.3. Usually the RSA key modulus is a multiple of 8 (2048, 4096 etc.). However there's no rule that RSA keys can't have other sizes. Implementing PSS with support for arbitrary key sizes is a bit more complicated than implementing it for multiples of 8. I wrote the PSS implementation of NSS as a summer of code project a couple of years ago and I remember that my first implementation completely failed to consider this. (The fix for that never got merged afair, I informed NSS developers about this.) Back then I also reported a bug in OpenSSL: https://rt.openssl.org/Ticket/Display.html?id=2315&user=guest&pass=guest Long story short: It's not unlikely that there are more PSS implementations having problems with this. So I strongly recommend that all implementors of TLS 1.3 test their implementations for key sizes from n*8+1 to N*8+7. Such keys are rare, but they do exist in the wild. If implementations failing on that get shipped widely we may see random unexplained errors when people start migrating to TLS 1.3 in masses. I had actually considered proposing to change TLS 1.3 in a way that such keys would be simply forbidden. But I did a check on the censys data and there were too many of them in the wild, so I thought it wasn't a feasible idea. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ChaCha20+Poly1305 cipher suites with truncted authentication tag?
On Tue, 17 Jan 2017 13:03:35 +0100 "Andreas Walz" wrote: > I know there is some comprehensible reluctance against bloating the > TLS ecosystem with even more cipher suites, but still ... have there > been considerations / discussions on adding ChaCha20+Poly1305 cipher > suites with truncted authentication tags for (D)TLS? The usual question to answer is: why? The general reluctance to add new ciphersuites "just because they are there" is imho very reasonable and in the past TLS got bloated in complexity far too much because of that. If you want a new ciphersuite you should have some good arguments why they offer something that the current ones don't. Ideally these should be specific. (Aka "Someone could need that for hypothetical situation XYZ" is not very compelling. "I am developing a widely used product where this would immensely help for Reasons xyz" is better.) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 3DES diediedie
On Wed, 24 Aug 2016 19:08:02 -0700 Tony Arcieri wrote: > Should there be a 3DES "diediedie"? I think a 3des diediedie rfc would be a good idea. I was wondering yesterday whether I should disable 3des on my servers. I'd likely exclude a small portion of my visitors for a very small security gain. Having a diediedie rfc would indicate that a significant portion of the net agrees that we want to hard-deprecate 3des. I'd feel more comfortable disabling it on my servers if I know that a reasonable number of other servers will do the same thing, because users with a 3des/rc4-only browser will not only see failures on my site, they will see failures all the time and will be forced to switch. Forcing them to switch is also probably almost always a good thing. Even for users who are stuck on Windows XP for whatever reason probably have better options than sticking to builtin IE - e.g. they can use Firefox, which is still supporting XP and offers modern ciphers. Appart from that more operational argument, as far as I can see the attack scenarios for RC4 and 3DES are in the same ballpark of complexity. Not very practical, but practical enough to make us feel uneasy, because we want TLS to provide reasonable protection even against ulikely scenarios. We decided to deprecate RC4 with an RFC, so it seems logical to deprecate 3DES as well. (while we are at it: I'm not sure, do we have any official RFC deprecating the even older ciphers - Single-DES, RC2 etc. - yet? We could just stuff that in) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 pgpOQJMA9gIKG.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3: Deterministic RSA-PSS and ECDSA
Hi, On Sat, 6 Aug 2016 18:54:56 -1000 Brian Smith wrote: > Also, I think it would be great if people working on proofs of > security for TLS could take into consideration the fact that > some--perhaps many--implementations will intentionally or accidentally > use some form of deterministic or less-than-random salt generation for > RSA-PSS. For example, it would be great to see a "What if the salt(s) > in the RSA PSS signature(s) were generated deterministically?" section > of papers describing such proofs. Actually there is some info on that in the PSS spec [1]. What I write here is my limited understanding, but roughly I'd interpret it as this: It says that if you use a non-random salt the security gets reduced to the security of full domain hashing, which was kinda the predecessor of PSS. I'd conclude from that that even in a situation where the salt generation is a non-random value nothing really bad happens. The security of a PSS scheme without randomness is still better than that of a PKCS #1 1.5 signature. Maybe some more knowledgable people want to add something, but the bottom line is I think that we don't need to worry too much about the randomness part here. Unlike with other situations (e.g. ecdsa/dsa) the randomness is not a piece that once you take it away everything blows up. [1] https://tools.ietf.org/html/rfc3447 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpOIJowXJU0B.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Thoughts on Version Intolerance
On Wed, 20 Jul 2016 11:20:46 +0200 Hubert Kario wrote: > so it looks to me like while we may gain a bit of compatibility by > using extension based mechanism to indicate TLSv1.3, Just quick: This was discussed yesterday, David Benjamin had an interesting proposal, but it was largely met with resistance. So from the WG discussion yesterday I had the impression that we will most likely stay with the existing clienthello version mechanism. While that will cause us more trouble, it's probably the cleaner option anyway. So we definitely should continue investigating version intolerance and tell people to fix their stuff. I'm now also collecting some data and have some preliminary suspicion on affected devices. My numbers roughly match yours that we are in the more or less 3% area of 1.3 intolerance. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp5ozrzxnTqc.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Thoughts on Version Intolerance
Hi, Recently both Adam Langley [1] and David Benjamin [2] indicated that they expect with TLS 1.3 Browsers will have to bring back the infamous version falbacks that caused so much trouble in the past (POODLE etc.) to work around broken implementations of the TLS handshake. I don't blame browser vendors for this, I can understand their reasoning why they think they have to do this, although I don't share their opinion. But I think this sheds a light on the sorry state of TLS implementations and I want to ask if there's a better way out of this. Let me quickly summarize how I see the situation: * The issue has been known for a long time. I found a document from Mozilla [3] from 2003 that describes the core issue. * While there is a lot of scattered discussion about the issue, the pure documentation status of this problem is far from ideal. I am not aware of any good documentation that even describes how exactly version intolerance happens. The "classic" variant seems to be implementations that just close the connection if they are contacted with a version number higher than what they support. But there are also weirder variants where a connection attempt with TLS 1.2 will be downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead to an answer with TLS 1.0. Questions I couldn't easily answer is how connections are terminated (TCP disconnect? TLS alert? Timeouts?) Also I'm not fully aware what the different version numbers (ClientHelo + record version number) mean in context of a handshake and how this influences version intolerance issues. * There don't seem to be any straightforward tools that test for version intolerance. The SSL Labs test does detect version intolerance, but it's limited to public facing https servers and it doesn't seem to detect some of the weirder variations (as described above). There's also a test in Hubert Kario's tlsfuzzer, but I've been unable to get it to work. I tried to create a test myself, but the results were highly erratic and I'm not sure why. * We don't have good data on the issue. The latest numbers I could find came from Ivan Ristic in 2013 [4], and from David Benjamin we know he considers the problem to be large enough that version fallbacks are inevitable. That's far from good data. We also don't seem to have any public list of affected vendors, devices and webpages. I want to try to work on some of those issues in the near future. Roughly I'd like to see that we work on a plan to reduce TLS brokenness in general and in particular - right now as this is an issue affecting the deployment of TLS 1.3 - Version intolerance. Things that I think we could and should do: * Talk to developers of test tools (sslyze, testssl, openvas, but also commercial tools etc.) that they include appropriate tests in their tools and warn about these issues. Also it'd be great if e.g. things like the google webmaster tools or any other public test tools for webservers/websites could test for this. * Raise this issue with pentesters and tell them they should include this when they're testing devices / products. (Of course this requires to have test tools in the first place.) * Get some data from internet wide scans and make it public. Maybe have a public shame list of the top X pages breaking TLS. * In general, more and better detailed documentation of this and similar issues, also raise this as a potential research topic. My hope would be that we can avoid the reintroduction of version fallbacks or at the very least reduce the amount of time they have to be used. And hopefully at least avoid them altogether for TLS 1.4 or whatever comes after 1.3. I'm in Berlin at IETF96 in case people want to discuss this. As this is terribly late for this I don't know if this can be included in the TLS WG discussion as it's probably already packed with other issues (but I'd happily introduce the issue if people want to discuss it). [1] https://www.imperialviolet.org/2016/05/16/agility.html [2] https://www.ietf.org/mail-archive/web/tls/current/msg20207.html [3] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TLS_-_SSL_3.0_Intolerant_Servers [4] https://www.ietf.org/mail-archive/web/tls/current/msg10657.html -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Fri, 4 Mar 2016 14:45:13 +0100 (CET) m...@sap.com (Martin Rex) wrote: > What should have adopted for TLSv1.2 already, however, is the less > forgiving PKCS#1 v1.5 signature check, that re-creates the encoding > and then compares the recreated inner encoding with the RSA-decrypted > encoding only. Get rid of the de-padding and get rid of the ASN.1 > decoding of the contents. The Problem with this is that you're relying on the implementor to get it right. Sure, you're giving them a receip how they could implement the check to be correct, but you have no way of checking whether they actually follow that receip. Given all past experiences I'd bet you can write whatever you want in your new standards document, no implementor will replace their (seemingly working, but insecure) PKCS #1 1.5 implementation as long as it works, just because you say they have to do it in a different way than they did in the past. > The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA > signatures is that one can clearly distinguish "wrong public key" > from "signature does not fit plaintext" errors, and loosing this > capability makes certain kinds of programming goofs (plus a few > admin configuration goofs) much harder to distinguish from > data corruption during transfer. Actually I see this as a disadvantage. Separating different error states has been the source of a whole number of vulnerabilities. The original Bleichenbacher attack (and all its variants including drown) is based on separating different errors, the Vaudenay attack is. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpYHTQr5FQIB.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Thu, 3 Mar 2016 15:29:37 + "Blumenthal, Uri - 0553 - MITLL" wrote: > Also, wasn't PSS developed before SHA3 and SHAKE were known, let > alone available? Yeah, more than 10 years before. It's more the other way found: PSS and other constructions showed the need for hash functions with a defined output length. SHAKE is such a function. PSS uses a construction called MGF1, which essentially takes an existing fixed-output-length hash, combines that with a counter and produces some construction. SHAKE deprecates the need for such a workaround. So instead of using PSS+SHA256+MGF1-with-SHA256 you could say you use PSS+SHA-3-256+SHAKE256. I don't think this changes a whole lot in regards to security (as long as we assume both sha256 and sha-3-256 are very secure algorithms). > It may be worth asking the authors what's their opinion of FDH vs PSS > in view of the state of the art *today*. You may do that, but I doubt that changes much. I think FDH really is not an option at all here. It may very well be that there are better ways to do RSA-padding, but I don't think that this is viable for TLS 1.3 (and I don't think FDH is better). PSS has an RFC (3447) and has been thoroughly analyzed by research. I think there has been far less analyzing effort towards FDH (or any other construction) and it is not in any way specified in a standards document. If one would want to use FDH or anything else one would imho first have to go through some standardization process (which could be CFRG or NIST or someone else) and call for a thorough analysis of it by the cryptographic community. Which would take at least a couple of years. Given that there probably is no long term future for RSA anyway (people want ECC and postquantum is ahead) I doubt anything else than the primitives we already have in standards will ever be viable. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpnn2C2wYISN.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Thu, 3 Mar 2016 13:35:46 + "Dang, Quynh (Fed)" wrote: > Why don't we use an even more elegant RSA signature called " > full-domain hash RSA signature" ? Full Domain Hashing was originally developed by Rogaway and Bellare and then later dismissed because they found that they could do better. Then they developed PSS. See http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf So in essence FDH is a predecessor of PSS and the authors of both schemes came to the conclusion that PSS is the superior scheme. > As you know, a SHAKE (as a variable output-length hash function) > naturally produces a hash value which fits any given modulus size. > Therefore, no paddings are needed which avoids any potential issues > with the paddings and the signature algorithm would be very simple. You could also use SHAKE in PSS to replace MGF1. This is probably desirable if you intent to use PSS with SHA-3. PSS doesn't really have any padding in the traditional sense. That is, all the padding is somehow either hashed or xored with a hashed value. I don't think any of the padding-related issues apply in any way to PSS, if you disagree please explain. (shameless plug: I wrote my thesis about PSS, in case anyone wants to read it: https://rsapss.hboeck.de/ - it's been a while, don't be too hard on me if I made mistakes) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpbuzHpqru9V.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Tue, 1 Mar 2016 18:23:25 + Alyssa Rowan wrote: > And so (maybe not entirely coincidentally!): another attack, dubbed > DROWN, just emerged¹, using SSLv2 as - you guessed it - a > Bleichenbacher padding oracle against RSA PKCS#1 v1.5! To be fair, the issues surrounding RSA encryption are different ones than the ones about RSA signatures. We already agreed to deprecate RSA encryption entirely. Therefore DROWN is irrelevant for the discussion here. (What causes often confusion is that Daniel Bleichenbacher is responsible for *two* major and completely unrelated attacks against RSA PKCS #1 1.5, one against encryption and one against - badly implemented - signatures) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpOvHDhmYRgZ.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Mon, 29 Feb 2016 12:35:57 -0800 Andrey Jivsov wrote: > Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, > we have to deal with already deployed hardware. Had vendors and > customers knew that TLS 1.3 will remove PKCS #1.5, we probably would > have ended up with more PSS-friendly Internet. Ok, look, I really would like to understand what you're trying to say here. What would such a warning look like? We have an RFC for PSS since 2003. We had several attacks showing the weakness of PKCS #1 1.5. Wasn't that warning enough? If not, how would such a warning look like? I'd really like to know, because we will have similar situations in the future and I'd like to avoid people lobbying in the background to continue supporting weak crypto. There will be some new TLS version some day and we will try to get better algorithms into it. So how do we warn you next time? -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpNpM6LT2ltE.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSA-PSS in TLS 1.3
On Mon, 29 Feb 2016 09:32:04 -0800 Joseph Salowey wrote: > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. > Please respond on the list on whether you think this is a reasonable > way forward or not. I recently already saw the message here asking for PKCS #1 1.5 compatibilty and was quite angry about it, but as there wasn't much discussion I thought this issue would go away. It seems it did not. RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago. Therefore we can conclude: * Whoever created that hardware implementation either did so more than 13 years ago (probably unlikely) or deliberately created hardware crypto with sub-standard algorithm support. * This can mean a couple of things: a) The hardware vendor knew about it and expected that they could prevent a move to RSA-PSS by lobbying standardization bodies (this is what they seem to do right now). In this case they deliberately want to weaken security and that behavior should not be encouraged. b) They didn't know about RFC 3447. That probably means they shouldn't develop crypto products at all. c) Something else? whatever the reason was, I can't find any reason I would find in any way acceptable. I think the TLS working group should not encourage such vendor behavior. Instead I think the opposite should happen: A clear statement that deploying sub-standard crypto technologies isn't acceptable and whoever does it has to expect breakage in the future. TLS suffered a lot in the past from misguided attempts to provide backwards compatiblity to weak algorithms. Most of the fancy named vulns in the past years can somehow be traced back to this problem. PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related vuln that could've been prevented by using RSA-PSS was found 2 months ago [1]. The last one in a major implementation (BERserk) was in 2014. tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable. Let's not repeat the mistakes from the past. [1] https://blog.filippo.io/bleichenbacher-06-signature-forgery-in-python-rsa/ -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpFny99O0zsR.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
Hi,
I generally like the idea of simplifying the different algorithm
negotiation things, but:
On Fri, 15 Jan 2016 20:45:34 +
David Benjamin wrote:
> [2]
> 0x-0x06ff - Reserved range for TLS 1.2 compatibility values. Note
> this is wire-compatible with TLS 1.2.
> - 0x0101 - rsa_pkcs1_md5
> - 0x0201 - rsa_pkcs1_sha1
> - 0x0301 - rsa_pkcs1_sha224
> - 0x0401 - rsa_pkcs1_sha256
> - 0x0501 - rsa_pkcs1_sha334
> - 0x0601 - rsa_pkcs1_sha512
> - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
> - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility
> but ignored in TLS 1.3.
I think a couple of them (esp. everything with dsa and _md5) should get
a diediedie rfc and never be seen again.
> - rsapss_sha256
> - rsapss_sha384
> - rsapss_sha512
> - ecdsa_p256_sha256
> - ecdsa_p256_sha384
> - ecdsa_p256_sha512
> - ecdsa_p384_sha256
> - ecdsa_p384_sha384
> - ecdsa_p384_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
> - ecdsa_p521_sha512
> - eddsa_ed25519
> - eddsa_ed448
Do we really need that many?
I think the "complexity zoo" of TLS is one of its current downsides and
I really think we should go with fewer options in the future. Can we
strip that down to - below 5 or something? (personal opinion: Strip
down to 2, but this may be too radical for now.)
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpkrBJu0EUUI.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On Tue, 15 Dec 2015 13:14:30 -0800
Eric Rescorla wrote:
> Watson kindly prepared some text that described the limits on what's
> safe for AES-GCM and restricting all algorithms with TLS 1.3 to that
> lower limit (2^{36} bytes), even though ChaCha doesn't have the same
> restriction.
>
> I wanted to get people's opinions on whether that's actually what we
> want or whether we should (as is my instinct) allow people to use
> ChaCha for longer periods.
Let me state the opinion that unlikely will get adopted: Isn't that a
good reason to reconsider whether GCM is a good mode in the first place?
How about: Let's use chacha20, let's not set any limits because we don't
have to, let's deprecate algorithms that can't keep up with that?
(I generally think even TLS 1.3 deprecates a lot of stuff there is
still far too much variation. Let's keep things simpler, let's reduce
the algorithm zoo.)
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpARhQ8AV2Cs.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fresh results
On Thu, 3 Dec 2015 18:45:14 -0500 Watson Ladd wrote: > On Tue, Dec 1, 2015 at 3:02 PM, Hanno Böck wrote: > > So as long as you make sure you implement all the proper > > countermeasures against that you should be fine. (Granted: This is > > tricky, as has been shown by previous results, even the OpenSSL > > implementation was lacking proper countermeasures not that long ago, > > but it's not impossible) > > Can you describe the complete set of required countermeasures, and > prove they work comprehensively? What if the code is running on shared > hosting, where much better timing attacks are possible? What's > shocking is that this has been going on for well over a decade: the > right solution is to use robust key exchanges, and yet despite knowing > that this is possible, we've decided to throw patch onto patch on top > of a fundamentally broken idea. There is no fix for PKCS 1.5 > encryption, just dirty hacks rooted in accidents of TLS. No disagreement here. The thing is, we have a bunch of difficult options to choose from: * Fully deprecate RSA key exchange. The compatibility costs of this one are high. They are even higher considering the fact that chrome wants to deprecate dhe and use rsa as their fallback for hosts not doing ecdhe. ecdhe implementations weren't widespred until quite recently. A lot of patent foo has e.g. stopped some linux distros from shipping it. * Separate keys for TLS 1.3 and TLS <= 1.2. Complicated. Certificates are already too complicated for many people. Do we really want to add more complexity by having different certs for different TLS versions? * Make sure proper countermeasures are implemented. Also difficult. I just learned nss is not bleichenbacher-timing-safe. Sounds like three bad options to me. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpzxAyzgCxz6.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fresh results
On Tue, 1 Dec 2015 14:28:49 -0500 Watson Ladd wrote: > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf > > This one looks very nasty to fix. Short of disallowing the use of RSA > certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I > don't see a good fix. I haven't read this paper in detail yet. > > Cross-protocol attacks are the gift that keeps giving. Correct me if I'm wrong, but as I understand the result (and I had one of the authors explaining it to me a few days ago) the problem appears only if you have a TLS 1.2 implementation with an RSA keyexchange that is vulnerable to a bleichenbacher attack. If it is not then you're fine. So as long as you make sure you implement all the proper countermeasures against that you should be fine. (Granted: This is tricky, as has been shown by previous results, even the OpenSSL implementation was lacking proper countermeasures not that long ago, but it's not impossible) Deprecating the RSA keyexchange just became a bit harder with Google's intent to deprecate DHE in Chrome and use RSA as the fallback if the host doesn't do ECDHE. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpbTiNagGGw2.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-02)
On Mon, 2 Nov 2015 22:52:59 +0900 Yoshiaki Hori wrote: > Name: draft-kiyomoto-kcipher2-tls > Revision: 02 > Title: Use of KCipher-2 with Poly1305 in Transport Layer I feel I've written almost the same on multiple occassions lately, but I'll do it again: I think one of the major problems of TLS (and other crypto) in the past has been that it has grown to be too complicated. I'm therefore strictly against adding new options without any reasonable rationale behind them. The rationale here seems to be "let's have another algorithm just in case". That "just in case" here is that if chacha20 turns out to be insecure we don't have another streamcipher. However we'd of course still have AES-GCM. I think TLS has suffered a lot in the past from feature bloat. I'd propose to go the other way: Lower the number of options if they don't make sense. Therefore: Please don't introduce another algorithm into TLS - unless you have very good arguments (i.e. it is vastly better than the other options or you have serious arguments why you think AES-GCM and chacha20/poly1305 are in danger of being real-world-broken any time soon). -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpyXsPnjb0bl.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt
Not sure if I'm getting anything wrong, but doesn't this open a huge security hole? Scenario right now is that if I want to be secure on a webpage I type in its HTTPS URL (either directly or through a bookmark) and can be pretty much sure that as long as I don't click on external links that I'll stay on that webpage. Basically this proposal would allow a man-in-the-middle to send me to another webpage each time I click on a (supposedly https protected) link. Given that there are many browsers these days (mobile) that hide the URL bar thats even more severe. This severely changes the security expectations one can have from a browser. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpasQL35Nfoo.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, 12 Sep 2015 13:49:49 -0700 Eric Rescorla wrote: > Issue: https://github.com/tlswg/tls13-spec/issues/242 > > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: > > "Nobody must ever be *required* to send an alert. Any requirement for > sending an alert should be SHOULD, at most." Just a quick thought on this: We had vulns in the distant past that relied on different reactions to different errors (Vaudenay / Padding Oracle attack). The Vaudenay attack is history because we agreed long that CBC/HMAC with MAC-then-Encrypt will be gone. But I think making the error alert optional may lead to similar attacks. An implementation may decide to send an error alert in one situation and no error in another. This may leak information valuable to an attacker. I generally think having a more strict spec with less wiggle room is better. Therefore: I think a MUST is better. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpwV5RTpF9Bz.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Mon, 31 Aug 2015 12:13:09 + "Dang, Quynh" wrote: > TLSs are used in more places than just > public servers and common browsers. For the people who use DSA in > TLSs, it would be nice if they could run TLS 1.3 with DSA if they > choose to do so. I think we all know that TLS is more than browsers. However the "people who use DSA in TLS" are currently a mere statement from you, we don't know if they exist. Several people have asked you whether you can name use cases. You haven't answered. As long as that's the case this discussion is pointless. We shouldn't keep DSA just because someone we don't know might have a use case we can't imagine. If you can tell us a) who is using DSA b) why they think this has an advantage we can have a useful discussion. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp_GgoJZKH3_.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DSA support in TLS 1.3.
On Fri, 28 Aug 2015 19:17:39 + "Dang, Quynh" wrote: > DSA is supported in the previous versions of TLS. It would be nice if > someone who uses DSA can use it in TLS 1.3 as well. Do you have a plausible reason why you want to use DSA? Or is this purely a theoretical consideration? Because this discussion came up multiple times here and I can't remember anyone having a real world use case for DSA. From net wide scans it seems DSA certs are almost nonexistent. > I don't see a convincing reason to remove support of DSA in TLS 1.3. The reason is avoiding feature bloat. I think it makes a lot of sense to question the support of features nobody uses. Therefore I'm very interested to hear why anybody would want to use DSA. "Just because someone could" isn't a good reason. (Also DSA has a well-known weakness with bad random numbers.) -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpNMWVrh6boY.pgp Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
