Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata

[<home_pw@xxxxxxx>]

If it's the intent to solve the problem mentioned, this was 
not stated in the document. Not even a hint!

What I am hearing is that its intended that TLS does more 
than name a communication port, open it, and secure record 
flow over the wire; it will henceforth address the Proof 
problems (PoO, PoS PoD, PoR) for (opaque) information 
objects by linking signatures flowing over the read and 
write channels. If the un-definable NR conditions are 
satisfied when asserting a X.509 bit flag called NR, one can 
even assert it has PoXwithNR semantics. A (signed) SAML 
assertion might accompany the signature, to enable 
mechanism-specific authorization functions (like dual 
signing is required, no signing on holy days, 
signature-capture required, the officer's secretary can 
generate delivery - but not read - receipts).

Specifically, its intended to address the SSL offloading 
pattern in data centers, where loadbalancers often strip SSL 
in the aggregation layer of the data center, before 
delivering http payload to the access layer of the server 
farm (or one of its colos). Thus TLS Evidence also addresses 
engineering issues to do with (I) managing sticky TLS 
sessions so TLS fragments and/or cleartext fragments/records 
are forwarded appropriate through the switches (II) 
establishing the assurance of particular SSL deployment 
models in data center configurations (c) complex cases of a 
hypermedia application multiple managing parallel 
session/connections, the impact on whom TLS Evidence will 
now consider in detail.

I'm supportive of ALL this, to the level of experiment. I 
don't think it will be long before we have reinvented the 
CCITT X.400 1988 security model ("mostly trust the messaging 
relays, dummy!" )... but lets see where it goes, and how it 
differs. Whereas with secure X.400 one attached the 
semantics of the generic signing mechanisms by defining yet 
another toolkit service APDU to the trusted MTS 
transport/relaying protocol, in TLS Evidence this will be 
signaled by cert extension values that signal the service 
intended for a given "TLS Evidence". And, again like X.400's 
MTS-based security model, multiple signatures/evidences 
might be involved to implement a bidirectional assurance 
such as PoR (which builds upon the PoD signature attached by 
the loadbalancer, to become a PoR signature/evidence created 
by the TLS endpoint identified by the full https URI)

I think this has to both an https.next and SSL effort tho. 
And, https is woefully underspecified as to the core, layer 
7 security model that is shared widely amongst the many 
usage model out there. But ,there is plenty of expertise in 
trusted messaging relay security models. We can draw upon 
this, to flesh out https properly, particularly if its URIs 
and connection practices are going to be a critical 
component of the TLS Evidence semantics. I would see some 
backlash tho, from certain IETF quarters: it could get 
political quickly; a lot of ego is involved, here.

It WOULD BE quite amusing if, via SSL/TLS and TLS Evidence, 
the MTS trust model wins out over the writer-to-reader model 
of S/MIME (and its predecessors).



----- Original Message -----
From: "Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>
To: <home_pw@xxxxxxx>; <tls@xxxxxxxx>
Cc: "'Kemp, David P.'" <DPKemp@xxxxxxxxxxxxxx>
Sent: Thursday, January 11, 2007 7:35 AM
Subject: RE: [TLS] Please discuss: 
draft-housley-evidence-extns-00 - use to create 
integrity-assured metadata

> Peter,

I can see how TLS Evidence could be used as David suggests 
in his terse
> comment about: "(1-to-many) persistent authentication". 
> You're right we
> haven't talked about this use of TLS Evidence before.



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