Re: [TLS] Please discuss: draft-housley-evidence-extns-00

[<home_pw@xxxxxxx>]

> Since the proposal is quite secretive about the specific 
> requirements
> and usage scenarios leading to this proposal, it is 
> difficult to assess
> whether adequate enigneering went into the proposed 
> solution to meet
> the requirements and minimize risk and security 
> impacts/collateral damage.
>
>
> -Martin

The document was very much like the document on a PRF 
pattern, done in collaboration with Eric, which didn’t even 
pretend to be a complete disclosure! That one said to me: 
shut up and rubber stamp, аппаратчик! But, there was a 
commonality of writing style style with TLS Evidence; but 
only one that is in common with the better levels of 
American security engineering.

And, both reeked of excellence. American writing style for 
technical English, minimalism of words, extreme binding of 
word use to concepts, and no explanation (except through the 
style itself). Good engineers don’t explain, they specify.

The first group and last groups of paragraphs of the 
document are the most revealing, once you infer the 
underlying security/legal/business doctrines that belie the 
design reasoning. And Mark revealed the background art he is 
applying, to be fair to him: a cross of ABA-ISC digital 
evidence project goals and mandatory integrity levels for 
some NCTS project routers doing risk compartmentalization 
(old Biba stuff, presumably).

For the former, the motivation seems to be addressing the 
practices required for the revised rules for Federal 
evidence (lalala lawyer/CPA land security "controls", 
"audit", "operational risk management"... doctrine) and for 
the latter, the motivation is applying multi-level message 
routing (where he kept referring to EAL6 "functional" 
assurances and multi-level A-routers whose critical SEFs for 
this TLS_evidence-enhanced https are implemented using the 
TCB doctrine). (N.B. it reminds of the $50M that 
DeloitesTouche spent on trying to work up a similar VAN 
business concept for their assurance practice, about 1996 
trying to get in on the .com boom, inserting :assured: X.400 
MTS relays into the flow of business email)

So, lets look in more detail. The first group provides 3 
assurance building blocks: 1) collect admissible evidence 
pertaining to a battle-of-the-terms negotiation, 2) apply 
the accord to control access to communication capabilities, 
and 3) audit stored/"wiretapped" records of the handshake 
agrement sand the APDUs within the recording regime of the 
alert blocks. #3 includes mandatory storage of all the 
"private" sessionids and ciphersuites, security labels..., 
Swedish QUALIFIED CERTS with Pseudonyms... and any and all 
custom record_types used in a second and later full/resumed 
handshake. Its clearly a BigBreak, from the privacy goal of 
the (currently) Proposed Standard, that has been unchanged 
since the SSLv3 I-D submissions.

The last group makes it clear that material that was 
expected to be private, being "confidential" on the wire 
(because of the bulk ciphering between the T-bridges, or 
between the MTS/https relays at layer 7) MUST NOW get 
cleartext stored, SECURELY. it gives the example of just 
storing the entire SSL (ciphered) stream, presumably with 
(escrowed) copies of all the asymmetric key used to unwrap 
it all again, later, during court testing.

For Stefan's point, finally, I could see the "TLS Evidence" 
signature mechanism being an "event signing" mechanism (like 
is done in vista today on my TPM'ed machine, for all the TPA 
integrity  benefits due to "technical evidence" management). 
But, does THAT (a) REQUIRE (secure) storage of the SSL 
stream and the handshakes and (b) hashes of the handshake 
messages in the signature block?





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