[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Comments on TLS identity protection
----- Original Message -----
From: "EKR" <ekr@xxxxxxxxxxxxxxxxxxxx>
To: <home_pw@xxxxxxx>
Cc: "Bodo Moeller" <bmoeller@xxxxxxx>; "Martin Rex" <martin.rex@xxxxxxx>;
<tls@xxxxxxxx>
Sent: Tuesday, December 26, 2006 7:51 AM
Subject: Re: [TLS] Comments on TLS identity protection
<home_pw@xxxxxxx> 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
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls