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

Eric Rescorla <ekr@networkresonance.com> Thu, 06 July 2006 19:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZRN-0007R3-6z; Thu, 06 Jul 2006 15:23:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZRL-0007Qc-P3 for tls@ietf.org; Thu, 06 Jul 2006 15:23:07 -0400
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZRK-0007Qg-Dt for tls@ietf.org; Thu, 06 Jul 2006 15:23:07 -0400
Received: by raman.networkresonance.com (Postfix, from userid 1001) id F04AE1E8C21; Thu, 6 Jul 2006 12:23:05 -0700 (PDT)
To: "Kyle Hamilton" <aerowolf@gmail.com>
Subject: Re: [TLS] KH comment (tls 1.2 draft)
References: <6b9359640607061007q5d2a5d24ha55ecc6c06f871c1@mail.gmail.com>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Thu, 06 Jul 2006 12:23:05 -0700
In-Reply-To: <6b9359640607061007q5d2a5d24ha55ecc6c06f871c1@mail.gmail.com> (Kyle Hamilton's message of "Thu, 6 Jul 2006 10:07:43 -0700")
Message-ID: <86slley1uu.fsf@raman.networkresonance.com>
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
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>
Errors-To: tls-bounces@lists.ietf.org

"Kyle Hamilton" <aerowolf@gmail.com>; 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.

-Ekr


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