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

From: <[email-masked]>
Date: Thu, 11 Jan 2007 09:03:28 -0800

> In military varieties of this, the sessionid sticky state 
> controls which 803.11q vlan paths trunks that fragment can 
> go over...

Sorry: 802.1Q, above.

I was thinking about 802.11i, EAP-TTLS and then AEAP for 
TLS1.2 fragments going over a connectionless bearer, or TCP 
(with those 2**64 fragments under the AES-CCM "hold 
plaintext till the mac verifies" rule!)

But, its fascinating to watch SSL evolve for different 
embodiments, with distinct tunings to each type of 
engineering. I can finally see what motivates TLS1.2 now. 
And, it is good. I was wrong to argue against TLS1.2 
procedurally, I now see.

But, as Martin hinted: one has to read behind the lines too 
much, to really review the new features of the TLS spec 
these days. Its almost impossible to do a conventional 
requirements trace...so that the crypto feature justifies 
the mechanism, which justifies the service, which responds 
to the use case, which is appropriate for application sphere 
X, and the ciphersuites and their modes are appropriate for 
the implementation assumptions (UNIX thread pools, switched 
ethernets with PVLANs, NIC/port ASICs etc). Thus is getting 
ever harder to (a) understand the (implied) rationales, and 
(b) evaluate the technical proposals 

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Jan 2007 15:13:27 +0100 (MET)

Benjamin Black wrote:
> 
> section 6.2 doesn't nearly address the problem in the abstract, much
> less give enough information to determine whether a specific
> implementation would or would not be deemed compliant with PCIDSS.  as
> just one specific example, 6.2 gives no guidance whatsoever on access
> control and auditing, both of which would prove especially challenging
> (do you monitor access to byte ranges?  do you index the streams before
> encryption so that semantically meaningful byte ranges are properly
> monitored?  how do you even enforce access policies when someone can
> access one byte range but not another when the whole stream is
> encrypted?  the complexity seems to be going up rapidly...).

This is what I meant with "distributing an egg on every access".

If TLS Evidence is used as described in a multi-level security environment,
the "wire-tap" data will likely have to carry the highest security label
that is permitted to travel the TLS-Endpoint, because of the braindead
raw capture approach that is entirely blind to the meta-data of the
communication contents.  It could re-use the labelling from the peers
certificate (policies), but it might still inflate the amount of data
with high security labelling.  The only positive side-effect might
be some extra jobs for IT tech guys with high security clearance
that are unlikely to be outsourced/off-shored. :-D

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Jan 2007 16:24:23 +0100 (MET)

Benjamin Black wrote:
>
> Martin Rex wrote:
> > So an application-level approach should not only standardize the
> > tagging of to-be-signed content, it should actually provide two
> > seperate tags resulting in two independent signatures, one
> > over all the data that ought to be authenticated during
> > processing of the transaction and one signature over only
> > the data that is to (and legally permitted to be) persisted.
> 
> sounds like a job for ws-*, not tls.

XML/XMLsig is probably OK.

WS-Security (SOAP,SAML) - better not.

There appears to be a serious misconception about what value
"assurance" and "assurance levels" could provide to the business
world.  In many areas it is not only painful and entirely useless,
it is even counter-productive in providing a false sense of security.

High assurance in software, hardware, policies and policy processing
is not going to improve accuracy and/or truth of the communicated
or stored information or communication.  And digital signatures
blindly applied to arbitarary collections of data are a real problem
for fixing or deleting inaccurate or untrue information.

Appropriately engineered cryptographic integrity protection for
data (in transit AND at rest) to provide resistance to tampering
is perfectly sufficient.

Businesses are collecting and producing data in the multi-megabyte
per day range.  9 years ago, the largest database among our
customers was 700 Gigabytes.  I don't know what is common today,
but I assume that several have long crossed the Terabyte mark.

So it is a sad fact that a lot of inaccurate information is processed
and stored by businesses every day, and applying digital signatures
on raw communication data will hardly have any benefits for the
businesses, but TLS Evidence will come at a cost and
create a significant performance impact (latency).

I mentioned it before, for Online shopping it will be pretty useless.
See
      http://www.heise.de/newsticker/meldung/83574

(sorry, it's all German).  Amazon had put up Sony&IBM laptops at less
than EUR 20 in their online shop and of course, several customers
ordererd them.  This is why businesses make sure that such offers
are not binding, because error like these happen every once in
a while.  This illustrate just what a stupid idea TLS Evidence would
be in these scenarios.

Maybe the President could claim that he received [EAL6] assured evidence
from intelligence that Saddam was working on nuclear WMD without
actually lying.  He probably is using highly assured equipment and
is communicating over highly assured communication links only.
Highly assured equipment higly assures that garbage in will
result in highly assured and expensive garbage out.

I also think that trying to provide any level of "non-repudiation"
on content (especially raw content) is just the opposite of where
everyone should be going.

Many US supermarkets have had a customer friendly return policy
for many years.  In Germany we didn't have it for quite a long time,
it came up a few years ago.  For online&telephone shopping, a very
customer-friendly return policy was enacted as law just 3/4 years ago.
Today, we usually do not have disputes about the content of an order
that was placed, but rather about characteristics or quality of the
product, inaccuracies of the advertisement and intend of the customer
placing the order.

-Martin

---

From: Peter Williams <[email-masked]>
Date: Tue, 30 Jan 2007 10:11:23 -0800

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: [email-masked]> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<> To: [email-masked]> Date: Tue, 30 Jan 2007 03:14:57 +0100> CC: [email-masked]> > 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> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Live Search: New search found
http://get.live.com/search/overview