[BEEPwg] Trouble with TLS and transport mappings

Jered Floyd jered@permabit.com
20 Nov 2001 16:24:07 -0500

"Marshall T. Rose" <mrose+mtr.netnews@dbc.mtview.ca.us> writes:

> doesn't this fall under the category that people doing stupid things
> deserve what they get?

I'm not sure I follow.  I agree that the example I gave was rather
contrived, but only because I was trying to demonstrate the issue
with minimal setup.  

> it seems to me that it's worthwhile to note in the discussion on processing
> the "<ready>" element, that the window isn't going to get updated and that
> when a reply is generated it must fit within the window advertised...

Because a peer must process any pending replies before a <proceed/>
element may be returned, and some of these replies may be on the same
channel that the <proceed/> is to be returned upon, the window size
could be arbitrarily small; in fact, the advertised window could be
full even before the response to the <ready/> is generated.  In the
case of a connection that is significantly active before tls
negotiation occurs, I believe that in some cases there is nothing that
the peer can do to avoid deadlock.

Anyway, while that sits I have some slightly less pedantic tls-related

1) Once transport layer security of any kind has been negotiated, may
   a different tls negotiation occur?  Section 4.1 makes it clear that
   this is *not* allowed with SASL profiles ("Once transport security
   is successfully negotiated for a BEEP session, then a SASL security
   layer must not be negotiated; similarly, once any SASL negotiation
   is successful, a transport security profile must not begin its
   underlying negotiation process"), but RFC 3080 isn't clear on tls
   in general.

2) Re: TLS, Section says:
      When a BEEP peer sends the "ready" element, it must not send any
      further traffic on the underlying transport service until a
      corresponding reply ("proceed" or "error") is received;
      similarly, the receiving BEEP peer must wait until any pending
      replies have been generated and sent before it processes a
      "ready" element.

   Consider the case in which several frames (but on the final frame)
   of a request have been sent on channel 1, and the same peer wishes
   to request TLS in a piggybacked message on channel 0. Should this
   be interpreted to mean:

      a) A BEEP peer must not sent a "ready" element until there are
         no partially-sent messages on any channel, or

      b) A BEEP peer should not consider partially-received messages
         to be pending replies?

   I greatly prefer the former interpretation, but I'm not sure this
   is correct.