[TLS] KH comment (tls 1.2 draft)

"Kyle Hamilton" <aerowolf@gmail.com> Thu, 06 July 2006 17:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXKN-0002AD-7J; Thu, 06 Jul 2006 13:07:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXKM-0002A5-2E for tls@ietf.org; Thu, 06 Jul 2006 13:07:46 -0400
Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXKK-0005Xn-P2 for tls@ietf.org; Thu, 06 Jul 2006 13:07:46 -0400
Received: by nf-out-0910.google.com with SMTP id y38so221506nfb for <tls@ietf.org>; Thu, 06 Jul 2006 10:07:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qVu26rc+VR23+D7OMm65VDgCzOl5WXlbUgaldjbM7t7P1EAQWnExgdL6qHj7G5CX2JWyC9XA2zzk/azqUp2x2YlbSZXIBrnSBirtnDP0avO1thrDsZN1b9zGdMd7nJMdXQttfXy2J0GoyX0TyNZVbTC4ZXyBIWA/bzyV9Iddlao=
Received: by 10.49.43.12 with SMTP id v12mr621693nfj; Thu, 06 Jul 2006 10:07:43 -0700 (PDT)
Received: by 10.48.12.19 with HTTP; Thu, 6 Jul 2006 10:07:43 -0700 (PDT)
Message-ID: <6b9359640607061007q5d2a5d24ha55ecc6c06f871c1@mail.gmail.com>
Date: Thu, 6 Jul 2006 10:07:43 -0700
From: "Kyle Hamilton" <aerowolf@gmail.com>
To: tls@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc:
Subject: [TLS] KH comment (tls 1.2 draft)
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

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.)

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

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.  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).

-Kyle H

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