Subject: RE: Finding PKIX Servers!

From: Andrew Probert <[email-masked]>
Date: Mon, 15 Feb 1999 09:44:25 +1100

Disagree on some items..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Saturday, February 13, 1999 3:36 AM
> To:	[email-masked]; Andrew Probert
> Cc:	David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
	[Andrew Probert]  <snip>
> Actually, the idea we had was to remove the unnecessary work from
> the application. FTP's twin connection is far more complex for any
> application to manage than the HTTP 'idempotent request' model.
> Similarly the LDAP BIND operation achieves nothing of real value.
> 
> The 'complexity' of HTTP/1.1 is due to the caching model. No other
> retrieval protocol I am aware of has any caching model - the applications
> were too busy performing unnecessary operations such as BIND and UNBIND.
> Caching is not a particular burden on applications however.
> 
	[Andrew Probert]  I am not taking a dig at HTTP, merely stating a
partitioning example of functionality up into infrastructure, the work's got
to be done somewhere!

	Why do you think BIND/UNBIND is unnecessary?  

> Even with every 1.1 boondoggle, HTTP is by far the most straightforward
> protocol to implement at the application level.
> 
	[Andrew Probert]  My personal experience is that strong
authentication has been pushed down into SSL model, then I had to do lots of
backflips and spend real development $$ to intercept SSL strong
authentication, encode it as HTTP header vars and pass it back up to my
applications which were on top of HTTP.  (Live ecommerce site, now doing
20,000 transactions per month)

	Where's the integrated authentication in this model?
>  
> In retrospect I think that the confusion that HTTP ended concerned
> the interface between the authentication/authorization model (an
> application concern) and the transport connection. 
	[Andrew Probert]  Disagree, see above.
> For some reason it
> was assumed to be a good idea to keep TCP/IP sessions going
> indefinitely - instead of simply caching the access control context
> at each end.
> 
	[Andrew Probert]  Agree SSL is a good model and does cache access
control.  However, policy regarding timeouts of SSL sessions and generation
of new session keys is weak e.g. do I need to re-authentication every 10
minutes, 1 hour etc, normally a server side setting!

> Unfortunately some folk took this a bit far, maybe Eric can remember
> the name of that chap from Chicago who he used to work with who had
> the idea of downloding every image in a page as a separate TCP/IP
> connection. That was definitely a bad idea!
> 
	[Andrew Probert]  Agree..

> 		Phill

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Tue, 16 Feb 1999 10:26:36 -0500

> partitioning example of functionality up into infrastructure, the 

Not if it is make work. The problem with FTP and to a lesser extent 
X.500 DAP is that the model is of a user at a terminal interfacing 
to a database. So the protocol follows the steps the user would take,
first login, then perform a series of transactions, then log out.

> 	Why do you think BIND/UNBIND is unnecessary?  

The authentication handshake need not be separated from the data
request. In general the authentication handshake and a URL will
easilly fit into a packet. Combining the two is much more efficient.

> 20,000 transactions per month)

Which is why Eric and myself were integrating strong authentication 
at the transfer/message layer. I still don't believe it is necessary
to waste a round trip delay on a separate BIND operation.

I don't see why an SSL implementation should have difficulty providing
the necessary information to the application. Certainly I am familliar
with several APIs which have provided the necessary information.

> minutes, 1 hour etc, normally a server side setting!

I believe the TLS folk have been addressing this.

		Phill

---

From: EKR <[email-masked]>
Date: 16 Feb 1999 08:17:05 -0800

> to waste a round trip delay on a separate BIND operation.
Neither do I. 

> with several APIs which have provided the necessary information.
Correct. If you have to jump through hoops to get this information,
it's not because of a deficiency in SSL, but merely because of
your implementation. (Not that I haven't seen such implementations).
This is encouraged by the use of CGI, where pretty much everything
has to be stuffed in such variables.

> I believe the TLS folk have been addressing this.
Not particularly well. There's a sort of consensus that a day
is about right, but it's not written down as a requirement.

That said, it can't be only a server setting. Both client and
server have to agree. To see why, realize that clients typically
store this information in memory, so there's got to be a way
for the client to not cache the information. 

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]