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. > >Remember that the reason we were originally told to use TLS here was > >replay protection. I know you keep saying server protection, but > >that's not how we originally got here. I'm not seeing much replay > >protection in what we've implemented to date, which concerns me, as we > >added a fairly heavyweight mechanism that as far as I can tell has not > >solved the original problem. > > My recollection differs somewhat. I think what Russ and I suggested > was using TLS to enable session-level protection, which includes > two-way authentication at the time of session creation (as an input > to access control for the server), session integrity (i.e., dropped > or re-ordered packets are detectable), and session authentication > (i.e., all packets belonging to the same session are verified as > such). Anti-replay at the session level and within a session are two > facets of this protection suite. 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. 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? _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
