[standards-jig] A few thoughts on JEP 0035
rob at cataclysm.cx
Tue Jul 9 23:25:47 UTC 2002
> 1) There is an asymmetry in the shutdown of the initial <stream:stream>s
> described in section 2.3; only the server/host sends a </stream:stream>.
> Is there some specific reason that the client/node does not
> also close his stream prior to the new stream initialization?
Because the server is expecting the next thing the client sends to be
the start of the TLS negotiation, the only real reason to have the
stream shutdown is for completeness. My thought was that this isn't
really necessary (the server could just free the XML parser context for
the client), and possibly problematic - OpenSSL, for example, expects to
be able to manage the negotiation itself via SSL_accept(), which means
the server has to read the stream end off the wire one byte at a time,
to make sure it doesn't overshoot into the start of the negotiation.
I realise thats an implementation detail, but I know its one that would
cause me problems when implementing, and I didn't want to just add it in
there for the sake of it.
> 2) <whiny> Would it make more sense to choose a namespace identifier other
> than the reference to RFC2595? </whiny>
The namespace identifier is completely up for grabs - that was the only
thing I could think of that was even remotely relevant. Suggestions?
> 3) Section 3 is a great companion to the use of SASL presented in JEP 0034.
> To make the protocol specification complete, I think some statement needs
> to be made about the use of the CertificateRequest message:
> o is it, as in "vanilla" TLS, strictly a matter of server choice?
> o or, is there some way for the client to indicate a preference for
> TLS based authn in advance?
> I'm fairly neutral, though eager to see this important feature of TLS used.
I don't quite understand what you mean, though I'll freely admit that my
understanding of TLS is not particularly good. As far as I understand it
though, the server says "I support these client certificates", to which
the client can choose to offer a certificate or not. If the offered
certificate matches, then the SASL EXTERNAL mechanism is offered, which
the client may select if it wishes.
If I've misunderstood the way this works, please let me know - I'm still
new to this.
> 4) For completeness, are any statements needed about the circumstances
> in which the client and server can resume an existing session during
> the handshake? Should this simply be one of those "local matters"?
For the sake of simplicity, I'd imagine we'd simply allow one session
per connection, as we do now.
> 5) For completeness, are any statements needed about the circumstances
> in which the client side might want to send a new ClientHello message and
> renegotiate the session's security parameters on the fly? Should this also
> simply be one of those "local matters"?
Again, for simplicity, I'd say that once the stream is established then
thats the way it stays until disconnect.
I'm not sure of the benefits of (4) and (5), but I haven't had alot of
exposure to TLS-aware systems. I'd be interested in your input.
Thanks for the comments!
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards