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

From: <[email-masked]>
Date: Wed, 10 Jan 2007 16:52:24 -0800

> The purpose of the proposal is to explore options to
> allow certificate-enabled clients to provide broadcast
> (1-to-many) persistent authentication without having to
> install SOA (WS-*) or other signing-capable plugins on
> the client.  It may or may not be architecturally a better
> choice to do signing through Web Services vs. TLS.  But
> while you're crying crocodile tears over TLS's
> "reputation" should it ever gain the ability to do
> digital signatures, save a few for Vista and digital IDs.
>
> Consumer-to-provider authentication (as opposed to
> consumer-to-provider's-TLS-accelerator) is needed,
> has both benefits and the abuse potential you are
> worried about, and is happening regardless of whether
> TLS is extended.

This is a fascinating interpretation of the purpose of the 
work item. So, lets explore it. I had personally NOT got ANY 
of this from the doc/author-disclosures , so far. Right now, 
it reads as "enforce subpoena on evidence retention". And it 
says, block connections, if you (once authenticated) are not 
clearly authorized and conforming to a mutually agreed data 
retention policy.

But let assume its an "exploration"; i.e. it targets an 
experimental standard status. That I SUPPORT. Why ever would 
one not?

Its for certificate-enabled clients. Well this only includes 
about >50% of the wifi(*) bindings made in the last 5 years 
of explosive wifi adoption by consumers...using EAP-TLS/TTLS 
to generate Russ Housley's TKIP keying material, for RC4 
packet encryption of [TLS/TCP] fragments, by a nic/vlan 
(counter mode with nonce, and CBC-mode mac/mic/moc/muc). 
Given AEAP is entering TLS1.2, we can see connectionless TLS 
coming down the pipe (pun), where after 2**64 bytes, the 
plaintext of the fragment is finally released, post mac 
verification. That I support. Make the TCB's secured data 
store rather large, of course, if you are supporting 1000 
connections! (1000* 2**64)

Said "exploration" is about investigating (I) broadcast, and 
(II) persistent authentication.

Lets take each, one at a time.

Broadcast (1:n): ok I didn't get anything from the text that 
followed, except that its semantics will be ~equivalent to 
WS-Security. I didn't see any furtherance of the broadcast 
notion (which is an interesting term, to me). Presumably, 
given TLS1.2 will accept non-X.509 certs (e.g. SAML2/WS-Fed 
assertions), TLS Evidence will be an alternative to 
SAML/WS-Fed . It will keep the control in the network 
(where, arguably, it belongs). At the same time, if we look 
at the connectionless TLS fragment that comes with AEAP, 
perhaps we do have broadcast keying, in the final/connection 
KDFs?

Persistence:  Are you claiming this to intend to be an 
"https-connection-related stickiness mechanism"?I did NOT 
get this from ANY reading todate. But, its interesting 
(being clearly about "security engineering", at least). This 
would be in scope. They could have said that MORE OBVIOUSLY 
though! Why do I have to work so hard? I'm an awful writer, 
but these guys are Grade A students! That spec was 
beautifully written, apart from gross lack of context.

Consumer-provider: I'll assume here you are making an 
allusion to the writer-to-reader concept from the DoD/NSA 
email world (which started out as something simple: the user 
agent software needs proof of user (I.e. human) presence, 
before rendering the de-ciphered confidential blob in the 
clear on a trusted display). I assume, we are attempting to 
now take that notion and evolve it...to a connection/session 
(versus an connectionless email). I'm interested. (I tried 
years ago, but could not convince you!! to even start 
thinking that we might go there...)

(*) I had one of the earliest UFO-shaped Apple access 
points, that dialed out on a 33k modem upon 802.11 binding. 
I went out and got my own NIC, as I was one of the "wrong 
class" of participant to get one to play with, at an IETF) I 
could never figure its key management scheme was, so never 
turned it on! Apparently, I was one of a million grandpas, 
in this; we all just gave up.

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

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 11 Jan 2007 09:35:52 -0600

Peter,

> of this from the doc/author-disclosures , so far. 

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.

One use for the TLS Evidence two-signature approach is to generate
integrity-assured data and metadata.  Integrity-assured data/metadata is a
create-write-once, read-many thing, and could be considered "(1-to-many)
persistent authentication".  TLS Evidence can be verified by any third
party, so if you choose to share it in this way, many could read it.
Obviously the choice to share data should be made in light of legal and
moral obligations stemming from the data contents.  TLS Evidence is content
agnostic.  But for the case of integrity-assured data/metadata, perhaps it
is useful to transmit and share TLS Evidence in addition to persisting it as
an audit trail.  So far we've really only talked about the audit trail uses
(and potential abuses) of TLS Evidence where (presumably) very few should
read it.

For example, if any of the final recipients are not attached via trusted
connection to the TLS server (for example, if any of the recipients are not
on the box with the TLS server, or if you just can't trust the connection
for some other reason), those recipients might benefit from integrity
assurance / proof of origin for the data/metadata that was received.  This
may be relevant to the TLS accelerator scenario David mentions.  In that
case an app may feel a little queasy about the client's identity since the
app never gets let in on -- and has no recourse to -- the client
authentication process.

Here's an integrity-assured data and metadata creation scenario.  A note for
clarity: a sender usually only writes metadata when that sender is also
writing data (i.e. sender is writing/sending but not reading/retrieving).
In the TLS Evidence two-signature approach, the sender might not be highly
assured, but provides a sender's-signature over the data and metadata.  The
sender's signature supplies provenance data, proving the origin was this
particular sender.  Additional knowledge of/about the source (via the
source's PKC or some other trusted records) may help qualify "who" sent it
and "what" is being sent.  For example, the PKC or trusted records
pertaining to the PKC might indicate the sending machine (physical location,
classification level, sensitivity level, hardware and software in use, etc.)
and the originating PKC may also imply the sending user (sender's rank,
sender's role, sender's authorizations, etc.).  

Of course the sender could use any digital signature method and achieve the
same result as what has been described so far.  TLS Evidence might add some
convenience.  But an assurance transformation in TLS Evidence happens when
the sender's transmission is authorized / granted access by the receiver.
Obtaining high assurance is the main goal in this scenario.

When the receiver performs the act of access control, for example if the
receiver uses a separation kernel to enforce mandatory information flow
policies, then the receiver's countersignature can add value.  Just about
any kind of access control works here.  The receiver does not have to
send/receive "authorizations" here -- it is common for just client
authentication results to be sufficient to decide whether to allow or deny
access.  All of this happens naturally in TLS handshakes; whether you use
mutual authentication, TLS Authorizations, etc., the protocol generates
fatal alerts if any step fails or loosely speaking, isn't good enough.  So
naturally in TLS you can't generate TLS Evidence until the handshake
completes successfully, which implies that access is allowed and
application_data can flow.  

To the level (only to the level) that the access control / information flow
policy enforcement can be trusted, that is the value of the
countersignature.  For example, if the receiver is subverted, then the
receiver's countersignature adds no assurance.  Even if the receiver seems
likely to be subverted, still the countersignature adds little assurance.
If on the other hand the receiver is EAL6 or EAL7, then you have a high
degree of confidence that the information flow was authorized.  EAL6 or
better is what's in view for integrity-assured metadata.  

The receiving router is never expected to be able to interpret the data or
the metadata.   Instead the receiver only verifies that current policy
allows the sender's requested information flow (access control check) and
that the sender's signature is correct.  Those verifications are its only
job.  If verified, then the receiver's signature (aka countersignature)
transforms the sender's metadata into integrity-assured metadata;
countersignature adds assurance to the metadata and data asserted by the
(now) authorized sender-source.  

So, in the case of a write of data and metadata, you know who wrote it
(sender's digital signature and receiver's validation of the computation's
correctness) and you know exactly what was said, but now (upon
countersignature) you also know that the write was _authorized_ (in a
military case, by policy).  So it is correct to infer the sender had the
authority to create both the data and the metadata.  When you have high
assurance that sender was authorized to write this data & metadata, and the
data & metadata is digitally signed, then no matter what the contents are, a
lot of worries about forged data / metadata go away.  Doubts may still exist
i.e. that this twice-signed stuff may be the perfect preservation of the
sender's erroneous misstatements or lies, but it is certainly NOT
unauthorized.  However, if the sender repeatedly speaks lies, it would be
very easy to change the policy for that sender, revoking that sender's
authorization.  Relying on this natural feedback loop, TLS Evidence
purposefully and absolutely separates itself from the task of discerning
lies, misstatements, sender's intent, etc.  In other words, TLS Evidence
NEVER looks into the application data.  

The two-signature approach follows from other useful security
models/methods.  You could see the two-signature approach as dual controls.
You could call it separation of duties.  I have compared its design to John
Rushby's 1981 proposal for the "separation kernel" as different from a
"security kernel".  Lawyers I have spoken to indicate that the two-signature
approach seems fair and not biased towards either sender or receiver.  All
of these are my goals.  The point is that in TLS Evidence each signature
accomplishes something different, and nothing can be accomplished by only
one signature.  This is useful when you want to avoid all-powerful keys (if
you believe as I do that such keys can be dangerous).

The policy question here is, How can we limit and focus what we authorize
subjects to "say" so that they are never authorized to "say" stuff that will
hurt the policymaking organization?  Policy makers should try to put only
those sorts of authorizations on the whitelist, and not for example
introduce broad, sweeping authorizations that apply to a large group of
nearly anonymous subjects.  Pinpoint accuracy when building the
authorizations whitelist is the preferred policymaking approach.  

Benefits / Commercial Application
Integrity-Assured Metadata (IAM) can be used to label data with a range of
classification levels, sensitivity levels, integrity levels, origin and
other information and tags.  IAM can provide useful and trustworthy metadata
to inform personnel and systems, which in turn can improve efficiencies and
accuracy.  Correctly formulated IAM should be useful outside of the context
of the originating system and/or a high assurance intermediary;
specifically, IAM should be especially useful to applications and consumers
after it has exfiltrated from a secure originating system.  IAM may help
enable MILS solutions to scale beyond a single processor system.  IAM can be
assembled into histories to describe who / what / when for access,
transmission and processing for an object.  IAM is a tagging, sharing,
searching, publishing aid that can help enable the data-sharing "post before
processing" paradigm proposed in DoD Directive 8320.2.  Metadata, including
security IAM, is widely applicable to numerous military and commercial
systems.

--mark

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 17:42:23 +0100 (MET)

Thank your for your explanations.

I don't understand why this proposal is brought to the IETF.

>From what I read, the IETF originally started out with government
funding, an a large part came from the department of defense.
The IPv4 spec says something like there was a secretive variant
of IP(v4) with support for all the esoteric stuff that you
are talking about for use in the military and by secretive agencies.
The academic and public wasn't bothered with any of this.

Today, the IETF is an open international forum and producing
standards for use in COTS (commercial of the shelf) software and
Open Source, for the masses (private and business use).

There is a huge gap between the concepts that you described
and the software that we're using today, at home and in the office
--it's not even in the same galaxy.

I think you should carry this proposal and the concepts back down
into the secret cellar where it comes from, and where those guys
dwell who believe that they need it, and that they continue
playing on their own.  They probably need multi-level security
in order to contain the evidence why something fucked up, who was
responsible and who else knew about it.

In the IETF we should try to produce standards for the needs of
the general public and remain on a level playing field with
e.g. the IETF apps area.  For years they have been complaining
that IETF security protocols are already to difficult and too
complex for them, and there is some truth in it, they are
already pretty secure and pretty complex.

A chain is only as strong as its weakest link, and the TLS Evidence
proposal is such an enormous and heavy link, it is going to rip
this chain apart all alone by its own weight.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 11 Jan 2007 12:07:42 -0500

> > [Dave] The purpose of the proposal is to explore options to
> [Peter] This is a fascinating interpretation of the purpose of the

I got it from Page 12 of the I-D:

         For example, a client
         may request access to a resource provided by the server,
         provide sufficient authentication and authorization information
         grounds to convince the server to grant the requested access,
         and receive an affirmative response from the server.  A record
         of TLS Handshake protocol messages representing this example
         may provide a sufficient record of the intent of both the
         client and the server.

I loathe the use of "intent of the client" here because it
smacks of NR and lawyers and judges.  But if the client generates
a request for a particular resource, then the provider of the
resource can assume from the mere existence of a request that
the client "intends" to perform some function (such as GET)
on that resource.

The motivation is separation between outward-facing interfaces
contained in a DMZ and back-end transaction processors separated
from the DMZ by a high assurance content-validating proxy.
I'd much rather see "TLS Evidence" called "Authenticated
Stream-to-Transaction Conversion" since that is my motivating
scenario, but I don't speak for the authors.  The "evidence"
in this case is not intended to be used by courts or snoopy
governments, it is intended for a transaction processor that
receives a request and needs to authenticate the original
requestor directly rather than accepting the word of a hackable
front end contained in a DMZ.  "Broadcast" authentication
doesn't mean that there are necessarily many recipients of a
specific request (although there could be, for load sharing),
just that the requestor has no need to know anything (including
certificate info) about the provider back-end in order to enable
the back end to authenticate the requestor.  It's just another
way to express the difference between persistent and
session-oriented data authentication.

Dave

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 11 Jan 2007 12:01:38 -0600

Martin,

Metadata is not esoteric.  Nearly every file system and storage format (from
file systems to file formats to databases) uses metadata.  "Metadata" does
include mundane things like file name, path to file,
owner/originator/author, last update, access control lists, etc.  Metadata
is increasingly (has always been?) recognized as useful in COTSs.

It is nearly universal that if you move data from one file system or format
to another, metadata gets wiped out, then recreated.  Just ftp a file.
During the ftp, original metadata gets stripped out and lost (though it is
often recreated with new values).  I'm saying that it could be valuable to
share metadata from one system to another, and TLS Evidence could be used to
provide assurance for it.  For example, party A could create a purchase
order for a system.  Party B could receive that purchase order and assemble
the ordered system from parts.  Party B might share TLS Evidence together
with party A's purchase order with suppliers C, D, E.  The suppliers might
find value in being assured that the purchase order originated with A and
has not been altered.

I see no gap between the concepts I've described and the systems we're using
today.  I think it's useful to have some assurance for metadata and/or data
in a transmission between systems (for example over an untrusted network,
which is common when using TLS).  Sometimes it's nice to know that the data
hasn't changed since you received it.  I don't think that's esoteric.

The system that creates TLS Evidence's second signature doesn't need to be
esoteric either; simple separation (i.e. the fact that the TLS client and
server don't have the same private keys) is often sufficient.  In a
commercial setting, "assurance" is more loosely defined than with the
military's EALs.  That's fine.  If someone uses a "secure" (not "highly
assured") TLS implementation to create TLS Evidence, they may be perfectly
happy with the level of assurance that the system provides.

Regarding the "secret cellar where it comes from," TLS Evidence is not dark;
I'm obviously publishing my designs.  My personal background is probably
irrelevant, but I've never worked for any part of any federal government
prior to my involvement on the US Navy contract acknowledged in the I-D.  To
date I exclusively use COTS and I interact freely on the 'net.  RedPhone
Security proposed determining "if a low-assurance encryption protocol
implementation can feasibly deliver messages while assuring system-wide
message integrity," which is not incompatible with an Open Source software
protocol implementation.  

--mark

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: Thursday, January 11, 2007 10:42 AM
> To: Mark Brown
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use
> to
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 20:08:17 +0100 (MET)

Mark Brown wrote:
> 
>                                      I'm saying that it could be valuable to

This example is full of flawed assumptions.

One the one hand, you keep on insisting that TLS Evidence is data
agnostic, meaning that it can at most verify signatures but has no
clue whatsoever about the data.  So any assurance is entirely
derived from assurance levels of the participating software on
either end combined with the policy tied to the signing certs
on the assumption these are only issued to highly assured software.

So the assurance level that you can get is at most as high as the
lowest assurance level of all of the software components involved
in the process on both communication peers.  Which means that
in theory you might get to EAL4, but you're unlikely to find
that in any real-world use.

TLS is a complex, expensive and completely unnecessary bell&whistle
that will result in massive collateral damage when used and
I haven't heard of any plausible usage scenario so far,
and I can not think of one either.

A well engineered approach would not use a shotgun approach to
security, but instead a tailored design that meets exactly
the needs of the application, can be used for programmatically
checking consistency an can create digital tamper-resistant
proofs of transactions that contain all and only the necessary
information that is necessary -- in which case it will be
possible make it conforming with individual, case-specific
legal and buisiness requirements.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Jan 2007 19:39:24 +0000

> legal and buisiness requirements.

Yes, don't we all wish we had that. Especially that we could agree on what "all and only the necessary
information that is necessary" is.

Another 10 years will pass before we get there unfortunately. In the meanwhile we will continue to conduct business based on passwords and totally spoofable security. In security, perfect has always been the enemy of the good.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: <[email-masked]>
Date: Thu, 11 Jan 2007 12:37:44 -0800

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "'Kemp, David P.'" <[email-masked]>
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

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 22:03:26 +0100 (MET)

Stefan Santesson wrote:
> Martin Rex wrote:
> > information that is necessary
> 
> Yes, don't we all wish we had that. Especially that we could agree on
> what "all and only the necessary information that is necessary" is.

You got me wrong.

> >                                -- in which case it will be

Instead of having to redesign and rewrite the entire application protocol
stack for every use case in order to accomodate what data will and
will not become part of the TLS Evidence, one can make it a configuration
option for the customer in the application.  So all of the attributes
that the backend wants to get signed will be tagged as such in
the request from the backend to the frontend.  Auxiliary information
will go untagged and not be included in the signature.  Because
the app knows what it wants signed, it can actually verify that it
receives what it is looking for.

> 
> Another 10 years will pass before we get there unfortunately.
> In the meanwhile we will continue to conduct business based on
> passwords and totally spoofable security.

A data-agnostic TLS-Evidence is still spoofable because of a lack
of assurance of the participating software components.

>
> In security, perfect has always been the enemy of the good.

Perfect forward secrecy is an enemy of TLS Evidence, and
I prefer the former by a significant margin. (I mean Perfect Forward
Secrecy as a design goal of the entire system, not only as
an isolated characteristic in the threat model for a particular
network link).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 22:50:38 +0100 (MET)

> app never gets let in on -- and has no recourse to -- the client

Now I'm slighlty confused about how that should work.

As you said, TLS Evidence is content agnostic, and covers the raw
datastream plus the TLS handshake.

What the application is going to receive is only a fraction of
the stuff that was signed and various middleware layers in between
will have likely aggregated, reformatted, canonicalized, modified,
stripped protocol layers and converted to local character set
before the application gets its hands on the request data.

So in general, even if the application jumps hoops to retrieve
the raw TLS evidence, it can only perform a consistency check
on the opaque blob checking the signature, it will usually have
zero chance to verify that the request it has received through
the regular protocol stack really matches to what is scattered
somewhere with in the opaque TLS Evidence blob.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 11 Jan 2007 17:20:03 -0500

-----Original Message-----
> an isolated characteristic in the threat model for a particular

You keep saying that, but please explain why data retained by
"network trace" components that log all levels of the protocol
stack is not an enemy of perfect forward secrecy.  If data is
retained, it is retained, regardless of whether a signature
exists to authenticate that data.

--------------
6.2. Storage Considerations

   Parties that choose to preserve a plaintext record of Application
   Data or Handshake Protocol messages for evidence verification at a
   later time must ensure must ensure that this data is not
   inappropriately disclosed by employing suitable physical protection
   or cryptographic mechanisms that are at least as strong as the
   selected TLS ciphersuite.

---------------

That's true enough, but isn't it just as true that parties that
choose to preserve plaintext records of *normal TLS sessions*
must apply the same level of protection?  When evaluating
secrecy as a design goal of the entire system, the same operating
policies (what data is stored where and for how long) must be
applied to signed evidence and to unsigned evidence, otherwise
a comparison between TLS extension and unextended TLS is
meaningless.

---

From: <[email-masked]>
Date: Thu, 11 Jan 2007 14:27:43 -0800

> > worried about, and is happening regardless of whether

[David] I got it from Page 12 of the I-D:

         For example, a client
         may request access to a resource provided by the 
server,
         provide sufficient authentication and authorization 
information
         grounds to convince the server to grant the 
requested access,
         and receive an affirmative response from the 
server.  A record
         of TLS Handshake protocol messages representing 
this example
         may provide a sufficient record of the intent of 
both the
         client and the server.

Wow. you got a lot more out of that paragraph than I did! 
Obviously the words must have much more loaded meanings that 
I realized (sufficient, convince, grant, affirm, record, 
intent). I thought it meant: (i) do a conventional client 
auth (and accept the TLS evidence extensions), and (ii) a 
signature comes back saying "you just authenticated to 
website URI x; we agree that use of this URI is subject to 
the terms and conditions attached in the signer's cert").

But. Ive clearly learned this is actually all about: 1 
intent 2 SSL offloading.

Your 1 point does clearly indicate out that the designers 
are FURTHERMORE making very specific (legalistic) claims 
about facilitating the signaling (and acceptance of?) 
intent. Perhaps this is too strong: its an issue that they 
are focused on, and intend their design to address its 
nature. IETF would be adopting that as a work item, if TLS 
Evidence becomes a work item.

on point 2: I like the general analytical model your 
developing tho ...and the problem definition that IETF can 
certainly address, if it wants. Your essentially asserting 
that the signature may come from the website, rather than 
the loadbalancer that is doing SSL offloading, in an 
increasing number of IDCs. And, the semantics of the 
signature would involve reliance on a (signing) cert for the 
app-server - whose X>509 extensions express which Ts&Cs are 
now binding for that URI, located way back in the server 
farm. This is all good, and was stock VeriSign design work 
early on, that never went far, pending adoption of digital 
signatures for e-commerce.

Again, the authors need to cater for grade C students (like 
me), not only grade A students. It has to be a "bit more" 
spelled out (e.g. loadbalancer, SSL offloading, 
consumer-to-provider-vs-loadbalancer). Its ever more 
interesting, tho., assuming the protocol's hashing of 
handshakes can be designed not to auto-fall foul of 
regulations affecting 450 million of the Internet's users.

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Jan 2007 00:06:30 +0100 (MET)

> exists to authenticate that data.

The incentive factor.

Creating TLS Evidence has a significant higher cost that persisting it,
and as it is somewhere between fully unclear to impossible to interpret
the signed contents programmatically, there is a certain likelyhood
that someone how goes through the effort to create it will want to
persist it.  Remember, if it was _just_ about signature verification,
you could either use a secure channel bindings approach or just "sign"
a secure random challenge, depending on your exact requirements.

Although I generally dislike channel bindings, I think they are
a much better fit than TLS Evidence (at least for the IETF).

If you can get management to approve the cost of having it
after having convinced them how useful and valuable digital
signatures on the entire communications  may turn out to be
(e.g. for lawsuits), that management might want that
expensive TLS Evidence to be retained/archived.

Probably everyone will agree that retaining a full network level
trace is most often a waste of resources.  Unfortunately,
the TLS Evidence blob is an all-or-nothing thingy with the lowest
possible signal-noise-ratio.

-Martin