At 6:27 PM -0500 11/2/09, Rob Austein wrote:
At Mon, 2 Nov 2009 17:56:39 -0500, Steve Kent wrote:
>I think we are talking slightly past each other, and have been on this
>topic all along. I said "HTTP", you seem to have read "TLS".
What Russ and I proposed was TLS, so that's why I am talking about TLS.
I'm not sure when the suggestion to use TLS was translated into HTTPS.
The protocol you reviewed back in 2007 was already running over HTTP,
so when you started talking about TLS, everybody interpreted it in the
context of the existing HTTP-based protocol and heard it as HTTPS.
Fair enough.
..
I assume you mean PDUs throughout here, not IP packets. Your
description makes some sense, but is not what I think we heard at the
time. I think you're more concerned about channel-level access
control here than I am (as I said to Terry, the access control I care
about all hinges on the CMS signatures). It is of course possible
that you're right about this and I'm wrong. In any case, I agree that
if we had done what you describe here, replay protection would have
fallen out of it as one of the consequences.
yes, I mean PDUs, since TLS runs on top of IP and TCP.
But the real question now is where do we go from here, given that we
have interoperable implementations that didn't do it this way.
Do you agree with my concern that what we ended up doing does not
provide replay protection?
Not sure that I do.
I understand your comment that HTTP per se has no real session
flavor. Not surprising since it was designed to support stateless
query/response exchanges. That was changed as cookies were added to
enable better support of state, without changing the base protocol in
a fundamental way. I am not enough of
an HTTP guy to know what are appropriate ways to get the session
flavor that we want, taking advantage of the TLS/HTTPS combination.
I'm tempted to suggest use of IPsec, but I'm biased :-).
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
