[147418] in cryptography@c2.net mail archive
Re: [Cryptography] TLS2
daemon@ATHENA.MIT.EDU (Peter Fairbrother)
Tue Oct 1 16:19:53 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 01 Oct 2013 21:13:01 +0100
From: Peter Fairbrother <zenadsl6186@zen.co.uk>
To: ianG <iang@iang.org>,
Cryptography Mailing List <cryptography@metzdowd.com>
In-Reply-To: <524A7FD3.2010108@iang.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 01/10/13 08:54, ianG wrote:
> On 1/10/13 02:01 AM, Tony Arcieri wrote:
>> On Mon, Sep 30, 2013 at 1:02 AM, Adam Back <adam@cypherspace.org
>> <mailto:adam@cypherspace.org>> wrote:
>>
>> If we're going to do that I vote no ASN.1, and no X.509. Just BNF
>> format
>> like the base SSL protocol; encrypt and then MAC only, no
>> non-forward secret
>> ciphersuites, no baked in key length limits. I think I'd also vote
>> for a
>> lot less modes and ciphers. And probably non-NIST curves while
>> we're at it.
>>
>>
>> Sounds like you want CurveCP?
>>
>> http://curvecp.org/
>
>
>
> Yes, EXACTLY that. Proposals like CurveCP.
I have said this first part before:
Dan Boneh was talking at this years RSA cryptographers track about
putting some sort of quantum-computer-resistant PK into browsers - maybe
something like that should go into TLS2 as well?
We need to get the browser makers - Apple, Google, Microsoft, Mozilla -
and the webservers - Apache, Microsoft, nginx - together and get them to
agree "we must all implement this" before writing the RFC.
Also, the banks and the CA's should have an input. But not a say.
More rules:
IP-free, open source code,
no libraries (*all* functions internal to each suite)
a compiler which gives repeatable binary hashes so you can verify binary
against source.
Note to Microsoft - open source does not always mean free. But in this
case it must be free.
Maximum of four crypto suites.
Each suite has fixed algorithms, protocols, key and group sizes etc.
Give them girls' names, not silly and incomplete crypto names - "This
connection is protected by Alice".
Ability to add new suites as secure browser upgrade from browser
supplier. ?New suites must be signed by working group?. Signed new
suites must then be available immediately on all platforms, both browser
and webserver.
Separate authentication and sessionkeysetup keys mandatory.
Maybe use existing X.509? but always for authentication only, never
sessionkeysetup.
No client authentication. None. Zero.
That's too hard for an individual to manage - remembering passwords or
whatever, yes, global authentication, no. That does not belong in TLS.
I specifically include this because the banks want it, now, in order to
shift liability to their customers.
And as to passwords being near end-of-life? Rubbish. Keep the password
database secure, give the user a username and only three password
attempts, and all your GPUs and ASIC farms are worth nothing.
-- Peter Fairbrother
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography