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

[<[e-mail]>]

Imagining a TLS Evidence work item to exist, I went a bit 
further in my ESIGN analysis, contemplating what has changed 
in the 10 years since I last looked at the issues 
surrounding SSL's client auth. Its one conception of how TLS 
Evidence might be approached; its radically different in 
concept from the design of the protocol in the ID under 
review. Though different in protocol and assurance claim 
design, its endgoal is presumably the same as those sought 
by the authors of the ID.

My latest machine happens to have an Infineon TPM chip in 
the motherboard, that "assists" the IE7/Vista perform the 
"trusted path" feature of that OS (as described in an 
earlier missive addressing UI Popups that control 
interaction with rendered HTML pages). The TPM chip is 
(amongst other roles) a motherboard-based RSA HSM. The 
associated windows CSP helps https (in Windows OS) perform 
the client auth operation in SSL. However, its not the chip 
nor the client auth evidence that is the "cue" of my 
interest in all this, concerning TLS evidence management, 
really. Rather, it's the insertion of the (enhanced) 
authentication device that ARMS the TPM, that then RSAs the 
certificateverify message, that matters. And, its not so 
much the "recording" of this secure arming _event_ that 
matters, but that said event is part of the well-defined 
"trusted path" feature of an evaluated trusted OS.

If one was to put this the other way around: certs, 
signatures on SSL messages, storage of PDUs, and even TPM 
assurance themselves are NOT what really counts in assessing 
the validity of a signature protocol element conforming to 
the TLS Evidence spec: it's the insertion of the arming 
device in the secure signing device that really matters - 
when you swipe the arming finger on my bio-armed TPM, or 
insert the smartcard that arms the TPM  in other machines.

So compared to where we were in 1995, when folks where 
demoing RSA smartcards signing "client auth" messages in 
SSLv3 and thereby asserting "NR!", we have moved on in the 
conceptual understanding of the issues surrounding technical 
evidence - thanks in part to TPMs role in providing 
technical evidence to the integrrity protected boot, AND 
trusted path.

For TLS Evidence to constitute a "writing" or a record, we 
are going to have to combine (1) Assurance of the TPM (or 
other motherboard-assured peripheral), (2) a trusted path 
security service from an OS, (3) a "(soft-)signing device", 
(4) an intent and consumer consent affirmation, (5) an RSA 
signature on the certificate verify message PLUS (6) 
"appropriate evidence of the arming" of the TPM.

Just because TLS might standardize protocols elements and 
procedures for a signature record_type on the read and write 
channels, and link their hashes back to the controlling 
handshake... this is not enough. We would have to build upon 
such protocol elements to also address within the layer 7 
https-v2 or a higgins/saml/was-federation layer all the 
related processes that I mentioned above. And the key (pun) 
may be to move the focus away from magical unicorns of NR 
and PKI to the practice of showing that "trusted path" 
assurances were in effect for the stored records - a claim 
we know how to CC evaluate, even across _networked_ trusted 
components, these days.



----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, January 27, 2007 8:51 PM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

> There has been a fair amount of support for experimental, 
> when I look back over the thread. Assuming the authors 
> could live with this, we could proceed, despite some clear 
> and absolute "never-never-never votes". TLS WG could then 
> lead the next generation of the privacy debate - moving 
> privacy beyond black/white strong pairwise encryption 
> claim into being a protocol for asserting "agreed limits 
> for privacy expectations". This would enable SSL to get on 
> with higher value transactions, and move beyond "SSL is 
> great for $1000 e-commerce - that is assured by visa cards 
> anyways". I know in my industry this _is_ being called 
> for, where the transactions are generally 500,000USD or 
> more, and involve a whole slew of regulated activities and 
> licensed parties who required higher assurance from https 
> RECORDS than we have addressed to date.
>
> I do think we would have to go back to basics tho. if the 
> work item is accepted - starting with a requirement 
> analysis and call for (competing) protocol designs - 
> designs that can take into account wider understanding of 
> various privacy/data-protection/data-retention regulatory 
> regimes that must be taken into account.
>
> And, we must distinguish between TLS Evidence and TLS 
> Authorization. The spec as-is currently is a design that 
> says to me: "create an infrastructure that enforces 
> mandatory data retention in the US, controlling 
> communication capabilities at the router based on testing 
> for "voluntary" optin to that policy regime. If the 
> challenged party rejects the policy optin, deny 
> communications - to show the evidence retention subpoena 
> is being complied with". This apparent ultimate focus of 
> the current concept (TLS Authorization) needs to be 
> separated out of the TLS Evidence. A separate work item 
> should be sought, to justify a place for working on TLS 
> Authorization - a control plane protocol that clearly 
> distinguishes itself from TLS Evidence (a data plane 
> service).
>
> By starting with requirements, we would get back to 
> (technical) evidence and its relationship to an enhanced 
> privacy service, addressing such as the role of sessionid 
> cache data retention, the new ticket data retention (and 
> the role of MS key wrapping) and - similarly - 
> ciphertext/cleartext data retention. Several other topics 
> would probably need to get included.
>
> If the work item is accepted, this could be some of the 
> underlying work that a section of the working group would 
> need to address and reduce to issue/requirement form., 
> Then, folks can worry about which protocol elements shall 
> represent/control/enforce/store information, at which 
> layer: https-v2/higgins, or TLS1.x.
>
>
> ----- Original Message -----
> From: "Peter Gutmann" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; 
> <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> Sent: Friday, January 26, 2007 6:21 PM
> Subject: Re: [TLS] Please discuss: 
> draft-housley-evidence-extns-00<
>
>> "Omirjan Batyrbaev" <[e-mail]> writes:
>>
>>>And what it takes to be Experimental RFC?
>>
>> See http://www.ietf.org/u/ietfchair/info-exp.html, in 
>> particular the
>> Guidelines section which explain the Rules section:
>>
>> # If the IETF may publish something based on this on the 
>> standards track once
>>  we know how well this one works, it's Experimental. This 
>> is the typical case
>>  of not being able to decide which protocol is "better" 
>> before we have
>>  experience of dealing with them from a stable 
>> specification. Case in point:
>>  "PGM Reliable Transport Protocol Specification" (RFC 
>> 3208)
>>
>> # If the document contains implicit or explicit 
>> success/failure criteria, and
>>  it's clear that the outcome can be used as the basis for 
>> a recommendation to
>>  the IETF community, it's Experimental. Case in point: 
>> RFC 1797 "Class A
>>  Subnet Experiment" which led to RFC 1879 "Class A Subnet 
>> Experiment Results
>>  and Recommendations"
>>
>> Peter.
>> 

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