Re: [TLS] Comments on TLS identity protection

[EKR <ekr@xxxxxxxxxxxxxxxxxxxx>]

<home_pw@xxxxxxx> writes:

>>
>>> In SSLv3 one can choose to changeCipherSuite to a null encryption and
>>> null mac state, and merely use the fragmentation, sequencing and
>>> reassembly
>>> functions of the SSL protocol machine.
>>
>> The what? SSL offers no capabilities here that are not offered
>> by the reliable transport it must ride on top of.
>
> Your missing my point.

Obviously.


> Im not putting SSL record layer over TCP.... My SSL application is not
> https, it is
> itself an SSL Connection, sending record_layer records data
> over... record_types of
> an currently active (underlying) TLS Connection.

SSL requires that the transport over which it is carried be a reliable
stream transport. For starters, it's implicit in the design of the
crypto (the use of stream ciphers and CBC chaining between
records).


>>> (Nothing in SSLv3 states how the
>>> seq_num is calculated , note. It can be simple or fancy (provided
>>> it starts
>>> at zero, when the connection state is initialized or assigned).)
>>
>> I don't have the v3 spec in front of me, but if that's true, it's
>> a bug in the spec, IMO.
>
>
> Perhaps!
>
> "Each party maintains separate sequence numbers for transmitted and
> received messages for each connection. When a party sends or receives
> a change cipher spec message, the appropriate sequence number is set
> to zero. Sequence numbers are of type uint64 and may not exceed
> 264-1. "
>
> For TLS1.0, one may assume that increment means uint64++ (which seems
> reasonable, when writing a
> conformance/value/state checker)

I believe that it is the consensus of pretty much all SSLv3 and TLS
implementors that it means start at zero and increment by one for all
versions of the spec.
                                   

> FOr SSL3,
> its changedfor any variant of the change cipher spec message. For TLS, its
> the :first: message under "a particular connection state". If TLS Evidence
> changes the notion of Connection state (which it seems to do, being an
> extension of connection state machine), we now now have alerts setting
> seq_num=0.

The anti-replay guarantees of SSL/TLS (and the security guarantees if
you have an IV that depends on record seq #) depend on the property that
any given set of cryptographic keys may only be used once with a given
record sequence number. Since the Evidence extensions do not change
the cryptographic keys, they cannot allow the sequence number to
be reset.

-Ekr

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