[standards-jig] A few thoughts on JEP 0035

David Waite mass at akuma.org
Wed Jul 10 00:38:42 UTC 2002


How about having the initialization consist of sending a request and 
closing the stream?

i.e.
C: <stream:stream xmlns='jabber:client'
                  xmlns:stream='http://etherx.jabber.org/streams'
                  xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt'
                  to='jabber.org'>
S: <stream:stream xmlns='jabber:client'
                  xmlns:stream='http://etherx.jabber.org/streams'
                  xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt'
                  id='12345678'>
   
C: <tls:starttls/></stream:stream>
S: </stream:stream>

{begin negotiation, etc.}

-David Waite

Robert Norris wrote:

>>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!
>
>Rob.
>
>--
>Robert Norris                                       GPG: 1024D/FC18E6C2
>Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
>  
>




More information about the Standards mailing list