[BXXPwg] new penultimate version available

Ben Feinstein bfeinste@odin.ac.hmc.edu
Fri, 22 Jun 2001 15:31:26 -0700 (PDT)


On Fri, 22 Jun 2001, Roy T. Fielding wrote:

> Right, but it should be noted somewhere that this only applies to
> per-connection TLS, whereas things like https indicate the entire
> application route must be TLS (or equivalent) secure.  The difference
> is encountered when you have a chain of peers acting in the same way as
> an HTTP proxy chain -- if the client must wait for the origin to tell
> it the type of profile, then how does the first peer tell the second
> peer to contact the third peer to get the profile and send it back to
> the first peer before the first peer makes a non-secure request on the
> second peer?
> 
> I'm not saying that a separate URL scheme is the right way to handle
> this in BEEP (I'm not even sure if peer chains are a reasonable application
> of BEEP), but people who are coming from HTTP-land need to understand
> the difference between hop-by-hop security and tunnelled security.
> Something to think about, in any case, before somebody thinks that
> http-over-beep is a no-brainer.

For an example of BEEP peer chains and tunnelled security, see the TUNNEL
profile
(http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-tunnel-01.txt).  
In IDXP
(http://www.ietf.org/internet-drafts/draft-ietf-idwg-beep-idxp-02.txt) we
use the TUNNEL profile to provision a chain of peers, then tune with the
desired security profile (most likely TLS) before binding the endpoints to
the IDXP profile.

Cheers,

Ben Feinstein
me@benfeinstein.net