[Cryptography] TLS2

[Adam Back]

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