W3C home > Mailing lists > Public > ietf-discuss@w3.org > February 1999

Re: APPLCORE: An architectural question

From: Vern Paxson <vern@ee.lbl.gov>
Date: Wed, 10 Feb 1999 12:43:07 PST
Message-Id: <199902102043.MAA10117@daffy.ee.lbl.gov>
To: spreitze@parc.xerox.com
Cc: discuss@apps.ietf.org, ietf-applcore@imc.org
> > > > PS:  is T/TCP alive or dead these days?
> > > 
> > > AFAIK, it is rather dead, due to problems inherent in the 1/2 RT
> > > startup.  There is a comment on this in the minutes of the RUTS BOF ...
> > 
> > Which comment in the minutes are you referring to?
> In the minutes in the proceedings, under "Other (unattributed comments)",
> item 3 identifies a dilemma that T/TCP faces and points to a discussion
> in the next full paragraph.

That comment isn't specific to T/TCP.  Any single-round-trip transaction
protocol faces that problem.


> Other (unattributed comments):
> 	...
> 	(3) Dilemma: eliminating the three-way handshake to make for faster
> 	    transactions reduces security [see below].
> 	...
> Steve Bellovin then discussed some security implications of the requirements.
> First, removing the three-way handshake opens up security holes.  The issue
> of sequence number guessing attacks is serious.  IPSEC is reasonably cheap
> for 'over the wire' security, but a key question is where do you get the
> IPSEC keys?  Unfortunately, multiple RTTs are needed to connect with a
> key manager, and one needs loosely-synchronized clocks (to address replay
> attacks).  Other public key management systems will be similarly expensive.
> The best you can hope for is to cache key management state.  But this
> doesn't work if you talk to a lot of other entities over a short time.
> However, it might be that object security is in fact cheaper than transport
> security (though you still need to watch for replays).

[there's a bug in the minutes above - it should be "*or* one needs loosely-
synchronized clocks ..."]
Received on Wednesday, 10 February 1999 15:44:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:05 UTC