On 30/09/13 11:02 AM, Adam Back 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
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. And support soft-hosting by sending the server domain in the
client-hello. Add TOFO for self-signed keys.  Maybe base on PGP so you
get web of trust,
thogh it started to get moderately complicated to even handle PGP

Exactly. By setting the *high-level* requirements, we can show how real software engineering is done. In small teams.

Personally, I'd do it over UDP (and swing for an IP allocation). So it incorporates the modes of TLS and UDP, both. Network packets orderable but not ordered, responses have to identify their requests.

One cipher/mode == one AE. One curve, if the users are polite they might get another in v2.1.

Both client and server must have a PP key pair. 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.


On Sun, Sep 29, 2013 at 10:51:26AM +0300, ianG wrote:
On 28/09/13 20:07 PM, Stephen Farrell wrote:

b) is TLS1.3 (hopefully) and maybe some extensions for earlier
   versions of TLS as well

SSL/TLS is a history of fiddling around at the edges.  If there is to
be any hope, start again.  Remember, we know so much more now.  Call
it TLS2 if you want.

Start with a completely radical set of requirements.  Then make it so.
There are a dozen people here who could do it.

Why not do the requirements, then ask for competing proposals? Choose
1.  It worked for NIST, and committees didn't work for anyone.

A competition for TLS2 would bring out the best and leave the
bureaurats fuming and powerless.

The cryptography mailing list

The cryptography mailing list

Reply via email to