Re: [TLS] Comments on TLS identity protection

[<[e-mail]>]

----- Original Message -----
From: "EKR" <[e-mail]>
To: <[e-mail]>
Cc: "Bodo Moeller" <[e-mail]>; "Martin Rex" <[e-mail]>; 
<[e-mail]>
Sent: Tuesday, December 26, 2006 7:51 AM
Subject: Re: [TLS] Comments on TLS identity protection

> <[e-mail]> writes:
>
>> Normally, client auth is not allowed on a PKI-class ciphersuite, if
>> the server has not performed server auth. (In a mix of PKIand non-pki
>> ciphersuites -during a change-ciher-spec between the two - things are
>> admittedly more ambiguous.)
>>
>> On a PKI-class limited renegotiation case (or a session resumption
>> case), server auth is implied, of course - assuming both enc and mac
>> ciphers mechanism are not NULL.
>
> There's no way in TLS to currently have a NULL MAC algorithm.
> I doubt there is lilkely to be one soon.

There was no way for a client to directly control the encryption keys/IVs of
a connection, until Fortezza_dms defined itself a way in its
ciphersuite/serverkeyexchange! Clearly, we cannot say the SSL
architecture denied that practice, or akin practices someone
defines local for a (weird) MAC regime!

We should learn to say "IETF standardized/endorsed ciphersuites don't...". 
TLS
has clearly evolved, as a defined term, under the tutelage of IETF. We
now understand that an "IETF-Conforming TLS implementation"
may process local cipersuites, and its necessarily associated key agreement
mechanisms, opaque handers, custom types, ephemeral handling. This
is a consequent of  standardizing  the very means of denoting local
ciphersuites - an excellent  IETF move, if I may deliver an architectural 
compliment.

>
>> For SSL3 using the RSA ciphersuites, one can ask for client auth on
>> handshake#2, without having provided server cert chain on that second
>> 'shake; server auth being established in the TLS resumed session (and
>> renewed Connection) state.
>
> I don't believe that this is correct. The state machines for the
> two handshakes aren't really related. What language leads you
> to believe that this is OK.


Perhaps its my mental model at fault; this is not uncommon! (And I
known I'm pushing the envelope, here; repeating questionable reasoning
used - and previously challenged - 10 years ago, in a similar debate.
I'm only interesting in RSA optimization, remember. And, I'm not
interested in hobbling RSA, to be only used in modes
equivalent to the limits facing other PKC schemes. And,
lots of multi-key/multi-phase RSA computational variants
exist, awaiting exploitation by designers of local ciphersuites.)

Anyhows, Session Handshakes create pool(s) of TEKs/IKs/MEKs... using PKC 
algs,
with centralized cache and cache protocols based off of sessionid and 
closure
rules (per TLS and per app) that only influence connections that are yet to 
be
active. Connections spawn off of these entries, by embodiment-specific means 
(perhaps
each NIC uses an IEEE protocol to talk to the common session cache on the 
local or
remote master switch in the subnet/vlan's STP, overcoming its vlan 
partioning sandbox
that otherwise limits access to the particular session cache instance shared
by all entities on the (tunneled) vlan)

I see each such entry as being an "instance-factory pattern"; several
runs of the truncated hello->final protocol on some bearer may each then 
renew the
random components of the connection state(s), per connection duplication of 
an
active session. Perhaps the http flows within may be pipelined, which 
includes how TLSconnections
and per-connection TLS messages are mapped to bearer(s). This is 
particularly
relevant if there is natural  parallelism or streaming protocols in effect 
(e.g classical
HTML page resolution where inline DHTML duplicates the active session to 
strongly
name the address(es) resolved for relative URLs subordinate to that page).

Now, for given cached session state (created by shake#1), and the connection
stated with "renewed random values" are the two handshakes not linked by 
values
used in the final protocol of the duplication session?

Particularly, where we are are using unique TLS transports for each TLS 
COnnection, don't we
need to rely on "inter-handshake linkage" using cryptographic strength - 
such that a client
auth done on one TCP connection is carried forward onto the TLS Connection 
duplicated from
its parent that as in turn communicated a different TCP (but still active) 
connection?

(This seemed to be one of the areas in SRP that they had not quite got 
correct, yet.)

And, then turning the argument around, doesn't the same reasoning apply for 
server auth?
>
> -Ekr

Some fun in 2818, also, (half-)reasoning by analogy:-

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.) In such cases, it is important to narrow the scope of
   acceptable certificates as much as possible in order to prevent man
   in the middle attacks.  In special cases, it may be appropriate for
   the client to simply ignore the server's identity, but it must be
   understood that this leaves the connection open to active attack.
 


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls