On 1/10/13 23:13 PM, Peter Fairbrother wrote:
...
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?
I would see that as optional. If a designer thinks it can be done, go
for it. Let's see what the marketplace
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.
Believe me, that way is a disaster.
The first thing that happens is someone says, let's get together and
we'll fix this. Guys, we can do this!
The second thing that happens is they form a committee. Then the
companies insist that only their agenda be respected.
End of (good) story, start of rort.
Also, the banks and the CA's should have an input. But not a say.
I'm sorry, this is totally embarrased by history. The CAs have *all*
the say, the vendors are told what to say by the CAs. The banks have
*none* of the say. We can see this from the history of CABForum, which
started out as I suggested above.
(The users were totally excluded from CABForum. Then about 2 years
back, after they had laid out the foundation and screwed the users
totally, they invented some sort of faux figurehead user representation.
I never followed it after they announced their intent to do a facade.)
More rules:
IP-free, open source code,
Patent free or free licences provided, yes.
no libraries (*all* functions internal to each suite)
Fewest dependencies.
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.
3 too many!
Each suite has fixed algorithms, protocols, key and group sizes etc.
I agree with that. You'll find a lot of people don't agree with the key
size being fixed, and people like NIST looooove yanking the chain by
insisting on upping the numbers to some schedule.
But that resistance is somewhat of an RSA hangover; if the one
cryptosuite is based on EC then there is more chance of it being fixed
to one size.
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.
And that opens pandora's box. It requires a WG. I have a vanity need.
Trouble begins...
Separate authentication and sessionkeysetup keys mandatory.
I like it, but DJB raises a good point: if EC is fast enough, there may
be scope to eliminate some of the phases.
Maybe use existing X.509? but always for authentication only, never
sessionkeysetup.
I see this as difficult. A lot of the problems in the last lot happened
because the institutions imposed x.509 over everything. I see the same
problem with the anti-solution which is passwords.
How the past is rectified and future auth needs are handled will be part
of what makes a winning solution the winner.
No client authentication. None. Zero.
That won't get very far. We need client auth for just about everything.
The business about privacy is totally dead; sophisticated websites are
slopping up the id info regardless of the auth. Privacy isn't a good
reason to drop client-side auth.
(Which isn't to say privacy isn't a requirement.)
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.
Well, they want a complete solution. Not the crapola they have to deal
with now, where they have to figure out where CIA stops and where their
problems start.
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.
So, it seems that there is no consensus on the nature of client auth.
Therefore I'd suggest we throw the whole question open: How much auth
and which auth will be a key telling point.
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
