On Tue, Feb 05, 2008 at 08:17:32AM +1000, James A. Donald wrote: > Nicolas Williams wrote: > > Sounds a bit like SCTP, with crypto thrown in. > > SCTP is what we should have done http over, though of > course SCTP did not exist back then. Perhaps, like > quite a few other standards, it still does not quite > exist.
Proposing something new won't help make that available sooner than SCTP if that something new, like SCTP, must be implemented in kernel-land. > > I thought it was the latency cause by unnecessary > > round-trips and expensive key exchange crypto that > > motivated your proposal. The cost of session crypto > > is probably not as noticeable as that of the latency > > of key exchange and authentication. > > The big problem is that between the time one logs on to > one's bank, and the time one logs off, one is apt to > have done lots and lots of cryptographic key exchanges. > One key exchange per customer session is a really small > cost, but we have a storm of them. This is what session resumption is all about, and now that we have a way to do it without server-side state (RFC4507) there should be no more complaints. If the latency of multiple key exchanges is the issue then we should push for deployment of RFC4507 before we go push for a brand new transport protocol. > Whenever the web page shows what is particular to the > individual rather than universal, it uses a session > cookie, visible to server side web page code. > Encryption, the bundle of shared secrets that enable > encrypted communications, should be visible at that > level, should be a session cookie characteristic rather > than a low level transport characteristic, should have > the durability and scope of a session cookie, instead of > the durability and scope of a transaction. If I understand what you mean then the ticket in RFC4507 is just that. Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
