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
- [TLS] KH comment (tls 1.2 draft) Kyle Hamilton
- Re: [TLS] KH comment (tls 1.2 draft) Eric Rescorla