Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt

Eric Rescorla <ekr@networkresonance.com> Thu, 12 January 2006 15:41 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4Zs-0006Xf-9y; Thu, 12 Jan 2006 10:41:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4Zq-0006XL-Fu for tls@megatron.ietf.org; Thu, 12 Jan 2006 10:41:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25415 for <tls@ietf.org>; Thu, 12 Jan 2006 10:40:04 -0500 (EST)
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex4gy-0007lw-Qy for tls@ietf.org; Thu, 12 Jan 2006 10:48:49 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 171931E8C4C; Thu, 12 Jan 2006 07:41:06 -0800 (PST)
To: jimmy <jimmyb@huawei.com>
Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt
References: <43C5FF00.5040704@ssh.com> <43C6285D.4040107@huawei.com>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Thu, 12 Jan 2006 07:41:06 -0800
In-Reply-To: <43C6285D.4040107@huawei.com> (jimmy's message of "Thu, 12 Jan 2006 15:28:53 +0530")
Message-ID: <86y81l314d.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Sender: tls-bounces@lists.ietf.org
Errors-To: tls-bounces@lists.ietf.org

jimmy <jimmyb@huawei.com> writes:

> Sami Lehtinen wrote:
>> Hello,
> ...
>> Also, there is conflicting text regarding message precedence
>> (handshake vs. application data):
>> In section 6.2.1. Fragmentation:
>>  Note: Data of different TLS Record layer content types MAY be
>>        interleaved. Application data is generally of higher precedence
>>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        for transmission than other content types and therefore handshake
>>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        records may be held if application data is pending.  However,
>>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> and in 7.4.1.1. Hello request:
>>        with a no_renegotiation alert. 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
>> Which text is correct? In RFC 2246, the text is
>>  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.
>> and text to the same effect is also in section 7.4.1.1 of RFC2246.
>>
>
> I too had pointed this out in an earlier mail, but got no replies. It
> seems in a previous thread in this list Eric had replied to someone
> posing a similar query. He had actually mentioned data had lower
> precedence (similar to what's in tls1.0 & the earlier tls1.1_drafts.
>
> So, it's a bit confusing. tls1.1 is in the rfc editor queue, so is
> that why no clarifications are coming in (are these going to be
> addressed in tls 1.2?)

This will be clarified in TLS 1.1 "Authors 48 hours"

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls