Re: [TLS] TLS or HTTP issue?

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sat, 07 November 2009 08:01 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 D10343A693D for <tls@core3.amsl.com>; Sat, 7 Nov 2009 00:01:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Y6HdPrggS4Xl for <tls@core3.amsl.com>; Sat, 7 Nov 2009 00:01:24 -0800 (PST)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 8D83D3A687E for <tls@ietf.org>; Sat, 7 Nov 2009 00:01:24 -0800 (PST)
Received: by bwz23 with SMTP id 23so1910738bwz.29 for <tls@ietf.org>; Sat, 07 Nov 2009 00:01:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Tjw696Ln5KSI8yPJiYOeerx2xiObMVaPUxhZqinTs7Q=; b=CERzDLqPt3R4pFVMHid1TkVuDxUIEAyS1pit1mCbKKSoNyZIV+7tV1xjU+wTzUIfLx HpuOakk4rJmK9OY+1GnxzWG4L9aY5ZsY4Yi7SuOmOguLsbKw7WrlZK3sYvIScipP8Xu6 q0x+/WYfGB6hVm71ktfPVhlEw3XG/S37LU3ak=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=oJj/zwmw0LS3VKtnnaqwPcxhP8I1ngkfz4JM3BXmjypL7AualESQ2vbEgM5U+rudOM t2/aY/7h0Mg098RjFAiU2Unr5fg6Wy3ICtUWqBzKECvC7t5oAYebBHBSCY0nqm+4mrR2 mu33mOhRdlHgihpSVHrMHvfmbLW8ryljH9JZ4=
Received: by 10.204.156.203 with SMTP id y11mr5338535bkw.200.1257580905240; Sat, 07 Nov 2009 00:01:45 -0800 (PST)
Received: from ?10.100.1.196? (adsl27-67.ath.forthnet.gr [77.49.218.67]) by mx.google.com with ESMTPS id d13sm1516994fka.22.2009.11.07.00.01.43 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Nov 2009 00:01:44 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4AF52966.3070400@gnutls.org>
Date: Sat, 07 Nov 2009 10:01:42 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: mrex@sap.com
References: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp>
In-Reply-To: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.95.7
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: ekr@rtfm.com, tls@ietf.org
Subject: Re: [TLS] TLS or HTTP issue?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Sat, 07 Nov 2009 08:01:25 -0000

Martin Rex wrote:

> For re-negotiations, the following requirement from
> rfc5246 6.2.1. Fragmentation  (last paragraph):
> 
>    Note: Data of different TLS record layer content types MAY be
>    interleaved.  Application data is generally of lower precedence for
>    transmission than other content types.  However, records MUST be
>    delivered to the network in the same order as they are protected by
>    the record layer.  Recipients MUST receive and process interleaved
>    application layer traffic during handshakes subsequent to the first
>    one on a connection.
> 
> Provides and interesting additional challenge, and documents that
> at least some of the original protocol designers didn't sufficiently
> reflect on the implications.
> 
> Similarly rfc-5246, 7.4.1.1. Hello Request
> 
>       Since handshake messages are intended to have transmission
>       precedence over application data, it is expected that the
>       negotiation will begin before no more than a few records are
>       received from the client.  If the server sends a HelloRequest but
>       does not receive a ClientHello in response, it may close the
>       connection with a fatal alert.
> 
> I think it is underspecified what "interleaved application data
> and handshake messages" and "handshake message have transmission
> precedence over application data" is supposed to mean, and
> what kind of signalling would be necessary between the
> TLS protocol stack and the application caller in order
> to convey the underspecified semantics unambiguously.

Actually as far as I remember this was the most tricky part of TLS (any
version) to implement in a sensible transparent way. Moreover the way I
have implemented it, although not so transparent, the application layer
cannot distinguish between the two sessions (one before renegotiation,
one after). The problem was for me that you could receive any amount of
application data even after a rehandshake was requested, thus I had to
cache them and present to the application after rehandshake was finished.

[...]

> From the original design, and in the two quoted paragraphs above,
> it appears that SSL and its successor TLS was intended to be
> _very_ transparent, and the spec contains guidance for
> security-relevant signaling to the application only for
> the initial TLS handshake on a connection (full initial handshake,
> and session resume), but _NOT_ for the session renegotiation.
> 
> Therefore, I think, we do have a real shortcoming of the
> SSL/TLS protocol, and we really should scramble to fix it.
> 
> That includes improving on the guidance for the signaling
> and semantics of a TLS session renegotiate of the TLS
> protocol stack to the application -- in a fashion so that
> it can be folded back into rfc5246bis.

I agree this part of TLS needs to become more clear in semantics and
more strict in specification. For example what has to be done by a
client if a handshake request was received. Currently some client may
ignore it. How long is the server going to wait to understand that it
was ignored and no reply is expected?


regards,
Nikos