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

[<home_pw@xxxxxxx>]

I'm convinced the term "corporate wiretapping" is proper, 
and that is one that grandma will inevitably associate with 
the scheme. And, for that reason, we must recognize that we 
have in our hands the power to destroy consumer trust in the 
"SSL brandname".  Even this debate could be picked up by 
journalists, today, to SSL's disadvantage. It doesn't take 
much to destroy trust.

In purer circles, TLS Evidence might be called a "mandatory 
data retention" scheme, to be enforced in the 
router/loadbalancer infrastructue when your company gets a 
subpoena demanding evidence retention, for example. And, one 
should assume every company will be forced there anyways, 
within 5 years, via best practices policy, to be enforced by 
the insurers.

----------

SO, having given the scheme a name, we can turn to the 
policy. The policy behind the scheme smells like mandatory 
"data/key escrow": but it has clearly evolved, perhaps to 
something more palatable. But there is no doubt in my mind 
what the intent is, masked behind several policy enforcement 
constructs.

I can _only_ bring myself to characterize the design intent 
as a "subversion" - a subversion of the assumed privacy goal 
of SSL. I've tried for two weeks to convince myself to find 
a better spin, but cannot honestly do so. And, its not 
because of the signatures, but because it requires the 
mandatory storage of the handshake cleartext, even in a 
double handshake case. (This allow a third party to validate 
the _stored_ signatures, not only authorize the realtime 
communication of _recorded_ data).

----------

With all that said, however, the privacy debate _has_ moved 
on, from its earlier forms: it has both expectation AND 
obligation components these days  These do need suitably 
designed enforcement constructs, preferably policy driven. 
And, then, policies need to be tuned for either the 
corporate or the individual cases. So, I feel that Marc and 
I _are_ tuned to the same fundamental frequency, in 
repurposing the SSL handshake in this way. As I indicated 
earlier, however, connection-NR was my attempt and it was a 
resounding flop (I turned a sequence of re-handshakes into 
means of performing legal-obligation-passing protocols; and 
in my abortive PhD I did the same with a cross-certification 
protocol for inter-domain obligation passing; both flopped, 
miserably).

Given this characterization of the debate, I believe that 
David Kemp to be "inappropriately" characterizing the scheme 
in terms of it being merely an "enhanced DAO" security 
service (like an aeap/AES-CCM scheme specialises DOA, to 
adds semantics that enforce "timed" release of the plaintext 
blocks to the socket user, for example, as well as 
authenticating a header for a connectionless TLS fragment ). 
And, I don't believe Russ Housley if he now claims that he 
is merely exploiting DAO for 
business/legal-obligation-passing protocols; the prelude 
presented for the mailing list clearly stated that it is the 
intent to support multi-level, realtime routing decisions. 
It is thus my opinion that the scheme aims to "instrument 
flow control policies in realtime" based on identities and 
evidence. From Marc's explanations, he intends to apply it 
to the authorization to even communicate, subject to access 
control policies - a la TNI.

> From what I can deduce, this _is_ all working towards router 
that do (realtime) testing for the existence of (and 
presumably validation of) the signature. This will require 
validating the id certs (from the PIV card, presumably) that 
sign the evidence, and validating the SSL certs used in the 
communication endpoints. These combined assurances may then 
authorize delivery of the applciation data to the layer 4 
port, but ONLY once its signed/validated/recorded/stored. 
Together, these assertions would "authorize" opening the 
"internet" port, which only open opening would pass TLS 
fragments (or complete records) to the assured application 
entities up the stack.

Whilst Martin is right to worry about the obvious case of a 
wiretapping application here, he is wrong to assume the 
handshake certs/keys are used in the signing process. The 
scheme does not mandate that one mixing client auth and NR 
EKUs; they can be in separate certs, on distinct endpoint 
devices. Perhaps the SSL client cert in one's PC's TPM will 
be a DSSsignedRSA key, created by one's national id card?

----------

Having used all this control plane terminology, I'll remark 
on the WG procedural question before us.

The debate about voice/data wiretapping has moved on from 
where it was.

So, where has it moved on to?

Well, privacy is now no longer only about facilitating your 
assertion of your expectation of privacy, and providing the 
strong and assured confidentiality channels; it is also now 
imposing social obligations on you, in turn. To get the one, 
you have to accede to the other, in a quid pro quo. At least 
we have more advanced political concepts, and a vocabulary 
for concluding a useful debate.

For the types of agreement construction being contemplated, 
its true for me that the SSL handshake and mandatory 
signature-based flow control regimes are more than an 
appropriate set of technical measures. But, this is true 
only when supported by very, very high assurance crypto and 
recording/storage hardware.

-----------

So Ill conclude my contributing to the wiretapping issue by 
re-posing the only actual question before us: does this 
group want to adopt this work item, now its (potential) 
nature is apparent.

It's a bold step to turn TLS into a flow control apparatus. 
It may or may not fit what IETF is about, these days, in my 
irrelevant opinion.


----- Original Message -----
From: "Stefan Santesson" <stefans@xxxxxxxxxxxxx>
To: <martin.rex@xxxxxxx>



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