Re: [TLS] TLS 1.2 draft comments

[<home_pw@xxxxxxx>]

Its true, they have gone, as has the calculation. And I didn't
even notice. Wow. After:-

All that crap about no RSA standard (1986 Geneva, State)
All that crap about LEAFs on IVs (1993 Fort Meade, NSA/NSC)
All that crap about dual certs & cross-certs (1992/1994 Ottawa, CSE)
All that crap about low entropy KDFs. (1995 Mountain View, Commerce)
All that crap about TTP CAs enforcing key escrow (1996 935 Pennsylvania 
Avenue, FBI)
All that crap about dual channel keying (1996 Royal Holloway, F&CWO)
All that crap about Bridge CA Assurance enforcement (2000 Washington, GSA)

Talk about shunting a bad policy around the agencies, to get rid of it!
I mean, it was just a career killer!

We need rapidly to bring back Fortezza technology back into a general
purpose SSL ciphersuite: KEA and key wrapping are well worth having. Now
Rumsfeld has gone, someone get DoD to put CAC firmware for javacards
(and driver libraries) into the open source community, where they
belong. It will go far, and will multiply. Keep the PIV stuff proprietary
and controlled for now, till public confidence is higher.

All we need now is dissolution of the stooge ANSI X9 RSA group, and
some test vectors from NIST for RSA key transport.

And, is IESG ready to have a look at moving SSL beyond Proposed, yet!?

----

The real test is of course Microsoft Windows, looking at the China
distribution of Vista next month.

Does it conform (I.e. refuse to negotiate export ciphers, with a TLS 1.1 
client)
Does it conform (I.e. perform negotiation with them, with a TLS 1.0 client)

But, I have the highest regard for Microsoft on cryptopolicy matters.

Lets wait and see how they do.


-----


----- Original Message -----
From: "Omirjan Batyrbaev" <batyr@xxxxxxxxxxxx>
To: "EKR" <ekr@xxxxxxxxxxxxxxxxxxxx>
Cc: <home_pw@xxxxxxx>; <tls@xxxxxxxx>
Sent: Sunday, December 31, 2006 1:02 PM
Subject: Re: [TLS] TLS 1.2 draft comments

> see inserted:
> Subject: Re: [TLS] TLS 1.2 draft comments

> > Because there's no good reason for them to exist and the key
> > weakening primitive adds substantial complexity to the
> > protocol.

There are lots of good reasons now to have lots of different KDFs
for setting connection state! There are many dual purposes of
the control technology used in export enforcement, for business &
legal purposes (not just the obvious purposes of mandatory data
retention, wiretapping etc).

I think Ill bring back my connection-NR for TLS, where handshakes punctuate
the transaction, like Russ's alerts do. With TLS Evidence also making
a signature, we gets lots of assurance toys to play with and apply
to a wide range of orchestrated business flows.




_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls