[Cryptography] TLS2

[ianG]

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