Dutch Transport Card Broken

[Nicolas Williams]

On Sun, Feb 03, 2008 at 09:24:48PM +1000, James A. Donald wrote:
> Nicolas Williams wrote:
> >What, specifically, are you proposing?
> 
> I am still writing it up.
> 
> > Running the web over UDP?
> 
> In a sense.
> 
> That should have been done from the beginning, even before security 
> became a problem.  TCP is a poor fit to a transactional protocol, as the 
> gyrations with "Keep-alive" and its successors illustrate.

In the beginning most pages were simple enough that to speak of
"transactional protocol" is almost an exageration.  Web techonologies
grew organically.  Solutions to the various resulting problems will, I
bet, also grow organically.

A complete revamping is probably not in the cards.  But if one should be
then it should not surprise you that I'm all in favor of piercing
abstraction layers.  User authentication should happen that the
application layer, and session crypto should happen at the transport
layer, with everything cryptographically bound up.  In any case we
should re-use what we know works (e.g., ESP/AH for transport session
crypto, IKEv2/TLS/DTLS for key exchange, ...).

> In rough summary outline, what I propose is to introduce a distinction 
> between connections and streams, that a single long lasting connection 
> contains many transient streams.  This is equivalent to TCP in the case 
> that a single connection always contains exactly two streams, one in 
> each direction, and the two streams are created when the connection is 
> created and shut down when the connection is shut down, but the main 
> objective is to support usages that are not equivalent to TCP. This is 
> pretty much the same thing as T/TCP, except that a "connection" can have 
> a large shared secret associated with it to encrypt the streams.  For an 
> unencrypted connection, it can be spoof flooded the same way as T/TCP 
> can be spoof flooded, 

Sounds a bit like SCTP, with crypto thrown in.

>                       but the main design objective is to make 
> encryption efficient enough that one always encrypts everything.

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.

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com