Re: [TLS] Comments on TLS identity protection

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

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.

Like Ldap and HTTP1.1 update an TCP session to turn TLS Connection's on and 
off
for certain TCP fragments, I do the same with my outer SSL connection. When 
my upper layer
(inner SSL connection) sends a certain custom record_type into the stream, 
this is
recognized by the outer SSL Connection which does a certain class and type 
of handshake...

I'm doing nothing here that TLS Evidence is not suggesting (albeit by 
abusing alerts!)

Hopefully, I can read the 2nd half of your TLS/SSL book tomorrow, focusing 
on the
engineering discussion, rather than the protocol discussion.

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

    "Sequence numbers are of type uint64 and may not
       exceed 2^64-1. A sequence number is incremented after each
       record: specifically, the first record which is transmitted under
       a particular connection state should use sequence number 0."

I think SSLv3 is clearer than TLS, concerning when sequence number is set to 
zero. 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.
They jury is only going to ask what went before .... if the seq_num for
the audited handshake starts at 9225.

Hmm.

> -Ekr
> 

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