Re: [cryptography] [Cryptography] TLS2
On Mon, Sep 30, 2013 at 11:49:49AM +0300, ianG wrote: On 30/09/13 11:02 AM, Adam Back wrote: no ASN.1, and no X.509 [...], encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits [...] support soft-hosting [...] Add TOFO for self-signed keys. Personally, I'd do it over UDP (and swing for an IP allocation). I think lack of soft-hosting support in TLS was a mistake - its another reason not to turn on SSL (IPv4 addresses are scarce and can only host one SSL domain per IP#, that means it costs more, or a small hosting company can only host a limited number of domains, and so has to charge more for SSL): and I dont see why its a cost worth avoiding to include the domain in the client hello. There's an RFC for how to retrofit softhost support via client-hello into TLS but its not deployed AFAIK. The other approach is to bump up security - ie start with HTTP, then switch to TLS, however that is generally a bad direction as it invites attacks on the unauthenticated destination redirected to. I know there is also another direction to indicate via certification that a domain should be TLS only, but as a friend of mine was saying 10 years ago, its past time to deprecate HTTP in favor of TLS. Both client and server must have a PP key pair. Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. However whether its password based or challenge response based, I think we ought to address the phish problem for which actually EKE was after all designed for (in 1992 (EKE) and 1993 (password augmented EKE)). Maybe as its been 20 years we might actually do it. (Seems to be the general rule of thumb for must-use crypto inventions that it takes 20 years until the security software industry even tries). Of course patents ony slow it down. And coincidentally the original AKE patent expired last month. (And I somehow doubt Lucent, the holder, got any licensing revenue worth speaking about between 1993 and now). By pinning the EKE or AKE to the domain, I mean that there should be no MITM that can repurpose a challenge based on phish at telecon.com to telecom.com, because the browser enforces that EKE/AKE challenge reponse includes the domain connected to is combined in a non-malleable way into the response. (EKE/AKE are anyway immune to offline grinding of the exchanged messags.) Clearly you want to tie that also back to the domains TLS auth key, otherwise you just invite DNS exploits which are trivial across ARP poisoning, DNS cache-poisoning, TCP/UDP session hijack etc depending on the network scenario. And the browser vendors need in the case of passwords/AKE to include a secure UI that can not be indistinguishably pasted over by carefully aligned javascript popups. (The other defense with securid and their clones can help prop up AKE/passwords.) Both, used every time to start the session, both sides authenticating each other at the key level. Any question of certificates is kicked out to a higher application layer with key-based identities established. While certs are a complexity it would be nice to avoid, I think that reference to something external and bloated can be a problem, as then like now you pollute an otherwise clean standard (nice simple BNF definition) with something monstrous like ASN.1 and X.500 naming via X.509. Maybe you could profile something like openPGP though (it has its own crappy legacy they're onto v5 key formats by now, and some of the earlier vs have their own problems, eg fingerprint ambiguity arising from ambiguous encoding and other issues, including too many variants, extra mandatory/optional extensions.) Of course the issue with rejecting formats below a certain level is the WoT is shrunk, and anyway the WoT is also not that widely used outside of operational security/crypto industry circes. That second argument may push more towards SSH format keys which are by comparison extremely simple, and are recently talking about introducing simple certification as I recall. Adam ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
On 30 September 2013 10:47, Adam Back a...@cypherspace.org wrote: I think lack of soft-hosting support in TLS was a mistake - its another reason not to turn on SSL (IPv4 addresses are scarce and can only host one SSL domain per IP#, that means it costs more, or a small hosting company can only host a limited number of domains, and so has to charge more for SSL): and I dont see why its a cost worth avoiding to include the domain in the client hello. There's an RFC for how to retrofit softhost support via client-hello into TLS but its not deployed AFAIK. Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
Hi Ben, Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
On 30 September 2013 07:07, Ralph Holz h...@net.in.tum.de wrote: Hi Ben, Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? I think you're testing that wrong. The major websites run one website at multiple IPs - not multiple websites at a single IP. So connecting with/without SNI will usually get you the same result. You want to test the Alexis 2,000,000 - 3,000,000 sites and see if you get a different result - hit shared hosting sites, where multiple sites run on a single IP. As far as software support, there are a few clients where support isn't there (most notable Java 1.7 and anything on Windows XP), but server support is there.[0] -tom [0] https://en.wikipedia.org/wiki/Server_Name_Indication ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
Hi, I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? I think you're testing that wrong. The major websites run one website at multiple IPs - not multiple websites at a single IP. So connecting with/without SNI will usually get you the same result. To clarify: we did not hunt SNI-enabled sites. We were after cases where a server on the Alexa lists shows the default certificate for another site, but will show the correct one if SNI is enabled. We thus did two scans back then, one with and one without SNI enabled, and determined whether we saw different certificates for some domains. In the setup you describe, we'd fully expect the same certs -- and I agree it seems to be the much more prevailing setup. You want to test the Alexis 2,000,000 - 3,000,000 sites and see if you get a different result - hit shared hosting sites, where multiple sites run on a single IP. Ideally, I'd combine an IP scan with DNS information from zone files (which we have, but I don't have the time to do it). [0] https://en.wikipedia.org/wiki/Server_Name_Indication Yes, but our scans back then did not determine deployed server versions. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
On 30/09/13 10:47, Adam Back wrote: Well clearly passwords are bad and near the end of their life-time with GPU advances, and even amplified password authenticated key exchanges like EKE have a (so far) unavoidable design requirement to have the server store something offline grindable, which could be key stretched, but thats it. PBKDF2 + current GPU or ASIC farms = game over for passwords. what about stronger pwd-based key exchange like SRP and JPAKE? Passwords don't scale up and are very inconvenient, but are you sure your argument PBKDF2 + current GPU or ASIC farms = game over for passwords really holds? what about scrypt? And theoretically, you can always increase the number of rounds in the hash... I refer to this link too: http://www.lightbluetouchpaper.org/2013/01/17/moores-law-wont-kill-passwords/ Looking forward to ur comments. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
