Re: [TLS] Still more on Record Layers

Marsh Ray <marsh@extendedsubset.com> Mon, 02 August 2010 22:15 UTC

Return-Path: <marsh@extendedsubset.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 7180F3A69DA for <tls@core3.amsl.com>; Mon, 2 Aug 2010 15:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.704, 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 qFgLLI3ZaIO2 for <tls@core3.amsl.com>; Mon, 2 Aug 2010 15:15:21 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 4ED973A6869 for <tls@ietf.org>; Mon, 2 Aug 2010 15:15:21 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1Og3IT-0004kM-2r; Mon, 02 Aug 2010 22:15:49 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 225756086; Mon, 2 Aug 2010 22:15:48 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+u+bBKlmQK/pyJZa2vwYOWneoSaJ9L1J8=
Message-ID: <4C574391.2070903@extendedsubset.com>
Date: Mon, 02 Aug 2010 17:15:45 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6
MIME-Version: 1.0
To: JCA <1.41421@gmail.com>
References: <AANLkTikVyJAdS1MW791Naqf8_U7FWW+uhQ3j1DzBEc50@mail.gmail.com>
In-Reply-To: <AANLkTikVyJAdS1MW791Naqf8_U7FWW+uhQ3j1DzBEc50@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Still more on Record Layers
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: Mon, 02 Aug 2010 22:15:25 -0000

On 08/02/2010 10:37 AM, JCA wrote:
>     I am somewhat confused about the meaning of the length field in a
> Record Layer. I believe that when the protocol messages, MAC and
> padding (if any) are encrypted in a Record Layer, the length field
> contains the length in bytes of this encrypted blob

I don't think that's how it works. The record layer length "doesn't 
care" whether the records are encrypted or not.

> (otherwise I guess
> it would be difficult to determine when a Record Layer being received
> ends.)

Yeah, we could have some fun parsing challenges if the type, version, 
and length fields were modified by the connection state. Probably an 
especially fun challenge for the attackers.

> Now it would seem that with the exception of the
> TLS_NULL_WITH_NULL_NULL cipher suite (which seems to be equivalent to
> what happens during the initial handshake, where no cryptographic
> cipher suite has been agreed on yet) if you have encryption you
> necessarily have MAC, but you can have MAC without encryption.

Here's the record layer:
http://tools.ietf.org/html/rfc5246#page-19
> struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           opaque fragment[TLSPlaintext.length];
>       } TLSPlaintext;

IMHO, it's a little misleading to call it TLSPlaintext since after the 
CCS record it's what we usually call "ciphertext".

It's not perfectly "opaque" to the record layer either since "The Record 
Protocol takes messages to be transmitted, fragments the data into 
manageable blocks, optionally compresses the data, applies a MAC, 
encrypts, and transmits the result."

But, IIRC, the length field represents the length of the record on the 
wire, so it doesn't know about how the data has been slice-n-diced. This 
makes it possible to always find the start of the next record by looking 
at t-he length field without knowing anything about the specific 
ContentType.

> What
> does the Record Layer length field contain in the latter case?

The length of the "opaque fragment" in every case.

> Is it
> the length of the (unencrypted) encapsulated protocol messages alone,
> or the sum of this plus the length of the MAC?

It's the count of bytes between (exclusive) this record's length field 
and the next record's content type, regardless of either content type.

- Marsh