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

[Peter Williams <[e-mail]>]

Martin:
The privacy world is changing in the transactional Internet, and we (generally) are not. Just today, in attempting to respond to your own email, my overly-sensitive UA asserted: "You cannot reply to/forward an unopened fraudulent message. Please open the message and read it before replying." This is "Policy-based Control" - in the interests of my security against the service provider's assumed-Martin-fraud . The UI option to "reply" is only available to me (after two overrides), when my peer can assert that I opened its envelope first. This is an nice example of the tradeoff between security and control, where control by the service provider over the freedom of the user to choose is a design trend that is evidently in the ascendant (at least in mind of the team designing "Microsoft Windows Live Desktop beta").
I personally find the objection to TLS Evidence experimentation even more troubling than the probable intent to subvert the traditional (pairwise) privacy goal of SSL. If the I-D were worded to be upfront about its probably architectural and social intentions, I'd actually support its evolution more than I would support the practice of resisting experiment-based discovery. With clear disclosure, Id remove the "subversion" label, happily. In making that judgment, I'd be supporting the lesser of two evils. After all, corporate wiretapping (of SSL) is a totally normal and everyday practice (in the USA), whereas limiting Computer Science is generally not.
 
Whilst I don't believe that cryptopolitical devices that hinder experimentation or resist corporate data retention policies will have any actual limiting effect upon the evolving practice of SSL in corporate/consumer world, here is my summary of the resolutions asserted in the debate to date:-

1. digital signatures are an appalling abuse-laden idea as custom record_types, but they are fine if they are an application_record or a handshake message
 
2. an endpoint's mixing of key exchange keys with seperate signing keys is an appalling idea, unless its signing a temporary RSA cert with a subjectDN
3. repurposable mechanisms that facilitate corporate wiretapping are contrary to the Danvers doctrine, unless one is repurposing the session cache or tickets for data escrow/retention
 
4. storage of the handshake and application data wiretext/cleartext is unacceptable, unless its a loadbalancer's SSL offloading syslog configuration or a promiscuous ethereal/IDS forensic trace
 
5. using anti-wiretapping policy arguments against technical measures is not itself a violation of the Danvers protocol.
So, given one cannot experiment and publish the method in IETF) without consensus, and one cannot work on the spec without an agreed workitem, how does now achieve some of the features that folks have identified as possible architectural benefits:-

a. with SSLVPNs at intermediate load balancers offloading decryption and data retention, have end-end signatures represent the interests of the true endpoints
 
b. in DTLS bearing a sipv2 UDP call setup, prior to the RTP connection setup, the called party should be able to obtain an affirmative evidentiary signature from the calling party representing "I consent to the call being recorded for quality purposes"
 
c. In a transactional stack (e.g. WTLS), TLS-layer signatures can be leveraged as session-layer tokens, for transaction resumption across (failed) TLS transport/connections
 
d. Satisfying writings and records standards for higher-value SSL application subject to intense, anti-fraud regulation
 
---------
 
If we now roleplay Galileo, and attempt to be too-clever and publish heretical experimental conjectures (in a discourse between imaginary scientists), let see if I too end up a broken old man humbled through torture into recanting. To avoid Galileo's fate, presumably we need to do something that is only ever conforming:-

I. its layer 7. e.g. cert-based
 
II. The protocol element is an existing handshake message, not a custom record_type
 
III. additional data is transferred in those fields that are under application control (vs state machine control)
 
IV. its use does not interfere with connection state
 
V. Adopts https://www.ietf.org X.509 v1 certificate practice, with its OU subject naming practices
 
VI. does not offend the sensibilities of the learned assembly - by saying "I" rather than "We", hereon after.
So, lets presume the liberating force of RSA will be useful, again, and exploit it within the confines of the TLS standard. In summary, thus, let's use the feature of issuing temporary (signed) RSA certs, in the KEYEXCHANGE state. Then, leverage the ability of either party to abort a re-handshake without (1) dropping the TLS Connection, (2) affecting the session caches
 
So to get an (authorized) TLS Evidence-style experiment going, with (the heretical) signatures , I should advance a five msg flow, on an active connection: ClientHello, ServerHello, ClientKeyExchange, Server KeyExchange, non-fatal-alert.
 
I presumably need to assure folks that this does not de-stabalize current sessionid caching, as a sessionid is not invalidated by the ServerHello until a finished message is exchanged; something I do not propose doing.  I should offer assurance , furthermore, that the hash values that we take from the (locally extended) TLS protocol machine and put in the sessionid value are conforming to the TLS standard, in size, syntax and security guidance. I should give assurance that I will not populate the signed certificate with any private extension, but use an subject naming field whose (base64-encoded) value will take into account the nonces from the latest hellos, the running mac values from the associated read/write connection state, and will otherwise conform with normal X.509 practice in IETF concerning the OU RDN
 
Now, may I have permission to proceed? I recognize that I'm ending up with the heretical SSL digital signature in disguise, but  I do plead in my favour that I am none the less meeting every rule over (conforming) experiments identified to date.
 
I would put a final appeal to the learned assembly: that the assumed heresy is the actual cause of the angst in this debate. Focusing on denying signatures in SSL is assuredly going to have no impact upon the adoption of data retention practices; for these are motivated by socio-political forces, not limits imposed on standarization of technology.  



> From: [e-mail]> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<> To: [e-mail]> Date: Tue, 30 Jan 2007 03:14:57 +0100> CC: [e-mail]> > Russ Housley wrote:> > > > Martin:> > > > >The XMLsig guys seemed to have realized that problem too far down the road> > >(stringified distinguished names may be pretty to look at, but close to a> > >dead-end road for futher PKI processing), so the SubjectKeyIdentifiers> > >had to be invented and retrofitted later.> > > > You look at the world differently than me, and that is okay, but I > > feel a need to correct this historical inaccuracy.> > OK, I'm sorry. Thanks for the clarification.> I just happend to read (parts) of the XMLsig spec and the> WebServices Security spec, and from one spec to the other,> issuer&serial for identifying the signer cert was basically> deprecated and subject key identifers were pushed significantly.> > The problem with distinguished names is that they don't have a> canonical encoding, so while a binary issuer&serial still works> as a unique database key, the printable ones created by XMLsig> don't.> > > > > Subject key identifiers were added to CMS by me. They were not in > > PKCS #7 as specified by RSA Labs. They first appeared in > > draft-ietf-smime-cms-10.txt in December 1998. They were added in > > recognition that the combination of issuer name and serial number was > > quite large.> > Distinguished usually aren't that long.> > (well, unless stupid CAs are involved that treat the name a digital> junkyard and put stuff in there that really doesn't belong there.> When one of our customers wanted to get an SSL cert renewed,> one particular (susidiary) of a well-know CA choked severely> on the name components which it had added...)> > Admittedly, a fixed short length for a subject key id looks attractive.> Unfortunately, they're not unique (re-newed and cross-certs), and> when you don't have the cert matching a subject keyid, you don't> have the slightest clue where to start looking. Significant> added complexity with moderate added value.> > > > > This was long before XMLDSIG effort got under way. The -00 draft > > XML-Signature Requirements document appeared in June 1999.> > The original XMLsig specification seems to prefer Issuer&Serial> for identifying the signer cert -- however due to the stringification> of the issuer name, lookup of the signer cert becomes somewhat difficult,> which might be the reason why WS-Security uses the subject key id> (and includes the entire cert). > > -Martin> > _______________________________________________> TLS mailing list> [e-mail]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Live Search: New search found
http://get.live.com/search/overview

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