Re: [TLS] KH comment (tls 1.2 draft)

Eric Rescorla <> Thu, 06 July 2006 19:23 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FyZRN-0007R3-6z; Thu, 06 Jul 2006 15:23:09 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FyZRL-0007Qc-P3 for; Thu, 06 Jul 2006 15:23:07 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1FyZRK-0007Qg-Dt for; Thu, 06 Jul 2006 15:23:07 -0400
Received: by (Postfix, from userid 1001) id F04AE1E8C21; Thu, 6 Jul 2006 12:23:05 -0700 (PDT)
To: "Kyle Hamilton" <>
Subject: Re: [TLS] KH comment (tls 1.2 draft)
References: <>
From: Eric Rescorla <>
Date: Thu, 06 Jul 2006 12:23:05 -0700
In-Reply-To: <> (Kyle Hamilton's message of "Thu, 6 Jul 2006 10:07:43 -0700")
Message-ID: <>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

"Kyle Hamilton" <> writes:

> Comments on protocol and TLS 1.2 draft:
> AMBIGUITY: Section 6.0
> The draft states "If a TLS implementation receives a record type it
> does not understand, it SHOULD just ignore it."  Does this mean that
> the implementation does NOT update its read_sequence_number when it
> receives it?  Or should the application attempt to decrypt it with the
> current state and verify that its MAC at least matches the updated
> sequence number?  (Ignorance in this fashion allows TCP injection
> against unmatched servers and clients, and possibly-vulnerable
> implementations that do not properly check the record type it received
> against the record types defined in a particular version of the
> protocol -- i.e., a newer version of the protocol may define new
> record types, and on a communication with an older client might act as
> though it "knows" about the record type that was sent and attempt to
> process the record any case, thus forcing a bad_record_mac error.)

Well, there are lots of ways to force a bad_record_mac error...

> So, what is the correct handling?  Ignore completely, or decode and
> update the sequence number?

The latter.

> ASSUMPTION: Entire Document
> It is universally assumed that this protocol will only be used over a
> sequenced network.  It is advantageous in certain circumstances to use
> this protocol over other types of transports, such as packet radio or
> dial-up serial EDI.  In both of these cases, "line noise" (the bane of
> SLIP, since that protocol didn't update the IP checksum properly) can
> cause data packets to fail to decode properly. 

See RFC 4347 (Datagram TLS).

> It should be stated
> exactly what the assumed network parameters are: Error
> detecting/correcting (to prevent errors between the two systems
> communicating with this protocol), reliability (the TLS implementation
> will have unequivocal knowledge of what data has been successfully
> received by the remote implementation, as far as signalling will
> allow), and sequencing (data packets will not be presented to the TLS
> implementation out-of-sequence).

This is what "reliable transport protocol" is generally taken to
mean in the IETF.


TLS mailing list