Re: [TLS] permitted client behaviour when rejecting renegotiation

Martin Rex <mrex@sap.com> Wed, 20 January 2010 23:12 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF4C3A67D4 for <tls@core3.amsl.com>; Wed, 20 Jan 2010 15:12:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.135
X-Spam-Level:
X-Spam-Status: No, score=-10.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVzdUZ2FYf6F for <tls@core3.amsl.com>; Wed, 20 Jan 2010 15:12:18 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E24533A6992 for <tls@ietf.org>; Wed, 20 Jan 2010 15:12:17 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0KNC391015503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jan 2010 00:12:04 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001202312.o0KNC2kr016804@fs4113.wdf.sap.corp>
To: nmav@gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 21 Jan 2010 00:12:02 +0100 (MET)
In-Reply-To: <4B5740B7.4010805@gnutls.org> from "Nikos Mavrogiannopoulos" at Jan 20, 10 06:43:19 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] permitted client behaviour when rejecting renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 23:12:22 -0000

Nikos Mavrogiannopoulos wrote:
> 
> Martin Rex wrote:
> 
> >> I always wondered how this behavior was supposed to work. For gnutls an
> >> error is returned if the request is ignored.  I think the use cases of
> >> these packets for renegotiation should be clearly defined (i.e. why send
> >> this packets and what should be expected from peer). I don't know how
> >> easy it is to implement the semantics precisely, but so far I didn't see
> >> any compelling reason to do so.
> > 
> > 
> > To me, this sounds like the server's gnuTLS switches to half-duplex
> > communication when it _sends_ a HelloRequest and expects the next
> > _received_ TLS record to carry a ClientHello handshake message
> > (or a warning-level no_renegotiation alert).
> > 
> > Can you describe/confirm the exact behaviour for gnuTLS?
> 
> Indeed, and this is intentional. I decided to error on any received
> application data, because the only use case of renegotiation I had so
> far seen was the client authentication upgrade. In that case I had no
> easy way to distinguish data received on the previous session and
> "client authenticated" data received on the session after renegotiation.

I should clarify this:  Prohibiting app data exchange _during_ a
renegotiation handshake is something that I advocated for myself
(and would likely implement myself if I would implement TLS), see

http://www.ietf.org/mail-archive/web/tls/current/msg04091.html

But given the full-duplex nature of the TLS exchanges before
and after renegotiation, I would cut the "renegotiation handshake"
differently, and _not_ consider a HelloRequest message to be part
of that handshake.  Because of the full-duplex nature, the handshake
is not guaranteed to be started synchronously on both directions
of the communication.  The TLS handshake itself is half-duplex
by nature (which might be the reason why the SSL spec defined the
interleaving of renegotiation handshake and application data
in the first place).

The implementation challenge is to get back in sync for the
TLS handshake.  Implementations like OpenSSL seem to use a half-duplex
protocol state engine for the TLS handshake (which is perfectly OK
for the initial handshake!), but that makes it little trickier to
implement the semantics that I outlined in my above message.


> 
> > From its design, the TLS protocol is full-duplex, so such behaviour
> > would not be compliant to any existing SSL/TLS protocol spec.
> > The full-duplex requirement, which is implied by the definition
> > of the HelloRequest message in SSLv3 already is probably the reason
> > why the "may ignore" was written out for TLS:
> > 
> >    The hello request message may be sent by the server at any time,
> >    but will be ignored by the client if the handshake protocol is
> >    already underway.  It is a simple notification that the client
> >    should begin the negotiation process anew by sending a client hello
> >    message when convenient.
> 
> Then you have the issue to distinguish data on the session "before" and
> the session "after" which is doable but not trivial (and probably
> depends on the application layer to interpret this information as well).

Singling out the HelloRequest message from the TLS handshake protocol
engine is likely simpler than allowing the handshake to begin on
a per-direction basis, i.e. the client sending side starts the handshake
with sending the ClientHello handshake message, the client receiving
part starts the handshake when it receives the ServerHello.

For the server side this might be easier to implement, because the
ServerHello or a no-renegotiation alert can normally be created
in a fairly synchronous fashion, but the difficulties may depend
much on the API between TLS and app (and whether TLS is transport-less
or in direct control of the communication channel so that it can
reply without the help of the application).


> 
> > That "when convenient" accounts to the fact that the (app) client
> > may be writing and the TLS implementation therefore not even
> > looking (read) whether there might be a HelloRequest handshake
> > message waiting -- and continue sending application data.
> 
> My limited experience with renegotiation shows that it is used in
> coordination with the application layer to upgrade the session with new
> security parameters. This is typically done on a silent phase of the
> application protocol (not during a file transfer that would require full
> duplex communication). Thus my decision was to implement this use case
> of renegotiation and wait for some compelling reasons (use cases) to
> implement the rest, which as I mentioned is not trivial.

I don't have any real experience with HTTPS-Servers that perform
on-demand TLS authentication, but HTTP pipelining might already
break an assumption about most communication being half-duplex.

(In which case a HTTP client app might have to drop to not-pipeline
over HTTPS)
 

-Martin