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

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 6 Jul 2006 10:07:43 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 12:23:05 -0700

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

> update the sequence number?

The latter.

> cause data packets to fail to decode properly. 

See RFC 4347 (Datagram TLS).

> It should be stated

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

-Ekr