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

From: <[email-masked]>
Date: Sat, 27 Jan 2007 21:03:09 -0800

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: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, January 26, 2007 6:21 PM
> Subject: Re: [TLS] Please discuss: 
> draft-housley-evidence-extns-00<
>
>> "Omirjan Batyrbaev" <[email-masked]> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Jan 2007 16:58:08 +0100 (MET)

[email-masked] wrote:
> the client auth operation in SSL.

The "secure trust path(es)" in Windows (Vista) might be sufficient
to apply digital restrictions management to "premium content"
but it is insufficient for "digital signatures" replacing traditional
end user signatures.

For that, you will need a secure trust path between the user(s intent)
and the digital signing device, means that it must include the
entire visualization device and the user input device(s) which
can add to that data pre-signature and which can trigger the
signature generation.  The visualization device is actually the
more important part, because it will provide
(application-specific) preformatted data that is to be signed.
Keep in mind that the entire visualization device must be
trusted, not just the path to it.

I've been asking several interesting questions about TLS Evidence
that have gone unanswered so far:

  - applications that receive communication with significant
    preprocessing by middleware have absolutely no chance
    to verify now or later whether a received application-level request
    matches the contents of a signed TLS Evidence blob.  Not when
    receiving it, at never in the future.

TLS Evidence applied to a traditional "notary" operation would look
like this:

 A surveillance video camera records you when you enter the building,
 it records your entire walk to the office, including all details of
 a potential "pit stop".  It records how you fill out the paperwork
 how you "apply the signature", and how the notary verifies your
 identity and counter-signs.
 Then that entire video-tape together with the paperwork is archived,
 however, it is impossible to verify whether the paperwork that is
 archived matches the paperwork that is captured on the video-tape.
 (TLS Evidence equals the video-tape here).

There really is no need to secure anything other that the
paperwork, the identification and the signing process.

The other serious issue with TLS Evidence is its interference with
middleware and application design.

Think about the "signed HTTP(S) FORM" idea that was mentioned.
Somehow the application must tell the TLS stack to start TLS Evidence
before sending the Form.  How is the app going to identify the communication
channel?  Actually, it can not.  It could guess and "tell" the TLS
stack to request TLS Evidence for the SSL session ID through which
the FORM was returned.

But as we know, an SSL session is not unique, Web Browsers duplicate SSL
sessions massively to speed up communication with the Server, and both
servers and clients will terminate HTTP/1.1 keep-alive sessions that are
idle for some amount of seconds (30-60 seconds is not uncommon) --
so a Form that isn't filled an POSTed within that timeout will be
sent on a different communication channel, although it might reuse
the same SSL session ID.

Basically all the web-shops, online-banking and online-brokerage and
ebay do not hold the user responsible for the data entered into the
forms for serveral reasons.  Instead, some amount of processing is
applied to the data and a preformatted page is presented to the
user for confirmation.  Reasons may be manyfold, like computing
a total or checking availability or consistency of an order,
but it is also a means to catch some amount of typing (or copy&paste)
errors by giving the user a chance to re-think his decision or
fix a typo, re-check terms&conditions, re-think warranty or shipping
options, what-have-you...

For brokerage-style operations, I consider it likely that the decision
to by a particular stock how many is determined _before_ either
the price/bid and/or the time when to issue, e.g. while watching
the ticker.  So a signature on the entire communication at the
TLS layer might span a significant amount of time and collect
large amounts or garbage in between due to how TLS session
caching/resumption/duplication is designed to work.

I'm wondering whether any one of those who thinks TLS Evidence is
useful for applications has ever seen an auditor check a system?
They expect to be able to browse through the audit trails and look
at (random) samples of their choice, like "show me all audit records
for this user during that day between this and that hour" and look
at the details.  For these auditors, TLS Evidence gobbledigoo blobs
will be pretty useless, as they can not programmatically verify whether
certain data as processed by the application maps to a particular
archived TLS Evidence record.
If app-level signed XML was used instead, it will be possible
at any time (before processing and during future audits) to verify
the signature and check whether the data which the application
actually processed really matches the signed audit trail.

-Martin