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

"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