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

From: "Mark Brown" <[email-masked]>
Date: Wed, 3 Jan 2007 13:42:37 -0600

Happy New Year, all.  I'm responding to Eric's initial questions, and I will
avoid topics not relevant to TLS and this group.

Eric,

I think you're right about the problems with the start1, start2, end1, end2
alerts.  They could cause deadlocks, seem to require and multiply
application-level interactions, and chew up alert space.  I'd be open to
abandoning them.  Removing these from the drafts would require some other
changes, perhaps removing any kind of reset over the application data sent &
received hashes, etc.  But removing these alerts would simplify several
things, which seems good.

Also, I think the alerts issue and some other unclear parts of the -00 and
-01 drafts led to some misunderstandings about how TLS Evidence works.  Let
me get back to this in a later email.

Most important, why should TLS WG do this?  Overall, it would be
advantageous to some users to use TLS's crypto to preserve a record of
communications, that is, the bits and bytes that were actually sent and
received.  More specifically, Why should TLS be chosen as a good place in
the 7 layer stack to create this record / evidence of what was actually
sent/received?  

1) Do it once at TLS, and get it right for lots of apps, don't reinvent the
same idea in many standards / apps.  The basic issue of creating a
mirror-image / forgery-resistant record may be useful to most Internet app
protocols.  
2) The TLS layer is the better place to manage keypairs, put crypto
algorithms (TLS vs. the O/S, not app layer, is an equally good question),
verify PKCs within an Internet communications context, and assure crypto
correctness vs. the app layer
3) The TLS handshake guards against replay attacks.  Now that TLS Evidence
and Supplemental Data exist it may contain other relevant and useful TLS
Extensions in it, and you don't get access to this data at the app layer
4) It's better to provide a wide variety of crypto options (using TLS) than
to use just one or two algorithms.  TLS offers one of the best selections of
cipher suites available.  If evidence is implemented at the app layer, each
app will face cost issues that promote their selection of "just the best
crypto algorithm" leading to brittle reliance on that algorithm and
incompatibilities between apps.  Moreover, key agreement and key management
is what TLS does very well and is hard to do well. 

Certainly a choice exists here: should we try to record what the app and the
user "thinks" or "intends" or should we try to record what was, objectively,
sent and received.  TLS Evidence aims at the latter.  Given this choice to
focus, objectively, on the app data that was sent / received then the way
that data looked just before it was encrypted (and HMAC'd) is a good place
to "watch" the data.  The TLS location is a good place to try to avoid "he
said / she said" arguments -- the TLS HMAC ensures that what was sent was
what was received, if anything was received at all.  But, as I point out
below, just storing the TLS packets including their HMAC isn't too durable
against forgery attempts (on the basis of TLS crypto alone). 

More generally, why is -evidence useful?  Here's my mission statement for
TLS Evidence: There are times when parties would like to have a record where
crypto was used so that the objective record of what was sent/received
resists forgery.  

Here's an example to motivate why someone might want an un-forgeable record.
Say you're buying tickets to a popular concert/movie/etc. online (i.e.,
limited inventory situation).  In this case you (buyer) might care even more
about getting a ticket than its price.  So when you show up at the venue you
want your electronic tickets / records of sale sustain a fair verification
effort that they are not forgeries.  You do not want the venue manager to
say, "Sorry, we don't have records of this transaction..."

Simply printing out records from a browser that bear a "https://" prefix in
the URL (etc.) does not preclude forgery.  Also, if either or both parties
retain the full TLS session data, that doesn't preclude forgeries either
(even in the case of TLS mutual authentication; more on this below).
However, the design of TLS Evidence is that if one or both parties retain
the full TLS session data then verification is quick and easy.  A user
should be able to download the TLS session data to his/her handheld/mobile
computer and take that record instead of tickets, in the example above, and
sustain a fair verification by the doorkeepers to the venue.  (If the
doorkeeper has lost the record, then the user can either use software that
is accessible to the handheld and that passes muster, e.g. a well-known
website, or the user may share the TLS session data for the doorkeeper to
verify using the doorkeeper's software, e.g. email it.)  Here, the crypto
properties of the record make it so that anyone's copy is a good copy and is
sufficient to stand up to scrutiny.  The crypto properties make great
records/evidence relatively cheap to create, and you don't need to keep the
records on secure hardware or in a vault.  Again, it's the crypto not the
storage practices that make it a good record.

It was suggested earlier that just storing the traffic keys is useful
evidence in some cases.

> >> Why not just store the traffic keys?

I don't think this helps very much against claims of forgery.  That's
because the symmetric secrets derived from the TLS Pre-master Secret
(including client MAC, server MAC, client write, server write, client IV,
and server IV) are available to _both_ parties.  Both parties may write data
as if they were the other.  So it is easy for both parties to change the
record at any time after the fact.  Either can attack the TLS record between
the handshake and the first packet of application data.  First cut the
packet record between the last FINISHED message and the first application
data record and throw away the old application data (or set it aside to use
as a template).  Now, take the handshake and splice onto it any application
data you want -- making sure to use both TLS client's and server's MAC,
write and IV secrets as proscribed by the specification.  To add realism,
the attacker has the old record of what was actually sent & received so the
attacker can reuse any bits of that record to make the forgery look more
realistic.  My point here is that the cryptography used by SSL/TLS doesn't
preclude forgeries made by client OR server, it only deters third parties
from making forgeries.

I will respond to your detailed comments in another email (this one is long
enough).  I will also supply an example of the TLS Evidence protocol for
this "Sure you can verify my tickets" use case.  

-mark

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 03 Jan 2007 12:49:49 -0800

> things, which seems good.

This makes some problems worse but some better. To the extent to which
one side's behavior is conditioned on the other's (E.g., I require a
signature before taking an action) then having the signature only at
the end causes problems. Plus, in Web contexts TLS connection
closure behavior can be quite complicated due to persistent connections
and bad TLS closure implementation.

> mirror-image / forgery-resistant record may be useful to most Internet app

But the problem is that doing it at the TLS layer entails not
really getting it right for most apps, for the reasons that
people have indicated so far--which is why signatures like
this traditionally go in the application layer.

> correctness vs. the app layer

I don't agree with this claim. The app needs to be cognizant
of many of these properties.

> is what TLS does very well and is hard to do well. 

But this isn't about key management or key agreement. It's about
3rd party proof, which is something that TLS does not at all.

> It was suggested earlier that just storing the traffic keys is useful

That's not what I suggested.

> preclude forgeries made by client OR server, it only deters third parties

Yes, I'm quite aware of this point, but it's not relevant to what I
was saying, which is that it's not necessary to parse the handshake
in order to recover the plaintext: you just store copies of the
traffic keys and then you don't need to parse the handshake.

> this "Sure you can verify my tickets" use case.  

Mark, nobody is doubting tha it's attractive to be able to provide
third party evidence of what happened in a given transaction. That's
why so much work has been put into digitally signing application
layer traffic. The question at hand is where in the stack this
functionality should go.

-Ekr

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 3 Jan 2007 16:37:19 -0600

Eric,

Thanks.  Ok, I'm starting to get on the same page as you (I hope).

> layer traffic. The question at hand is where in the stack this

Again, I think the 00 and 01 drafts are unclear in places.  I'm going to
present a sunny-day scenario and try to consider the applications'
perspectives too.  Hopefully this will flush out where the app could benefit
and if the app-over-TLS Evidence API is clunky.

In this example I will provisionally DROP the four alerts (start1, start2,
end1, end2).  They aren't needed in this example I've suggested it as an
option earlier.

       *  Indicates optional or situation-dependent messages that
          are not always sent.
       +  Indicates messages optional to the TLS handshake that
          MUST be sent when using TLS evidence.

      CLIENT                                 SERVER
      ======================                 =======================
      ClientHello               -------->
                                                        ServerHello
                                                       Certificate+
                                                 ServerKeyExchange*
                                                CertificateRequest+
                                <--------           ServerHelloDone
      Certificate+
      ClientKeyExchange
      CertificateVerify+
      ChangeCipherSpec
      Finished                  -------->
                                                   ChangeCipherSpec
                                <--------                  Finished

At this point, ClientHello included a request for the entire session to use
TLS Evidence, and the ServerHello must have agreed.  Otherwise, this
handshake would have terminated after the Hellos.  Also, mutual
authentication must also have been successful.  All of this must be true
before the Finished messages indicate that a TLS evidence session is born.

Since I've run this example while dropping alerts, no start1, etc. are
required and all application data will generate evidence until the session
is terminated.  If alerts are dropped, then a fairly "safe" rule for
evidence generation is to require that every time client or server dumps a
stream of application data to TLS records and to the wire (a single TLS
write call by the app) an EvidenceRequest also be created and sent.  The TLS
layer simply lets the app layer set the pace in this no-alerts proposal.
Since I'm provisionally dropping alerts here, I think it's best to NOT reset
the TLS Evidence application_data hashes any time during the session -- just
let them accumulate across all Evidence- messages for the session.  My
example of this is shown below:

      ApplicationData-1         -------->    [Client's instructions]
      EvidenceRequest-1         -------->
                                <--------    EvidenceResponse-1
      [Server's response]       <--------    ApplicationData-2
                                <--------    EvidenceRequest-2
      EvidenceResponse-2        -------->

BTW, whether you run TLS Evidence with or without the four alerts (start1,
etc.) you could have generated EvidenceResponse-1 and EvidenceResponse-2.
To repeat from -00 and -01, the EvidenceRequest is just one party's opinion
and signature, but EvidenceResponse proves that both parties independently
computed the same hash over all the data fields as proscribed by TLS
Evidence.  So you EvidenceRequest is superseded (it's pretty much worthless
to you) if you get a corresponding EvidenceResponse back.  

I think there's two aspects of whether this serves the application, or if it
would be better for the apps to do the signatures at the app layer.  First,
is either client or server is sticking its neck out during this protocol?
Second, how does the app need to configure and interact with the TLS layer
to get this done? 

I don't think either client or server is exposing itself to undue risk when
they use TLS Evidence.  TLS Client sends its app data, and when the buffer
it shares with TLS is empty, TLS automatically sends the EvidenceRequest-1.
This is basically a hash over the handshake, a hash over the app data sent
(yours) and received (none), a best-effort timestamp, etc., all digitally
signed by client.  My opinion is that the more specific client can be, the
less likely this digital signature can be abused later (threats of replay,
misappropriating the signature for some other purpose, etc.).  

TLS Server replies with EvidenceResponse-1, even before its application has
looked at the application data.  Server simply says, yes, I saw the same
thing within the same session (and the timestamp looks like a best effort).

Next, the server app handles the data it just received from the TLS layer as
input, then it may have some output data.  The server app puts its output
data into a buffer and gives that to the TLS layer.  Now the TLS server
sends that app data and automatically chases it with EvidenceRequest-2.
Inside EvidenceRequest-2, there's a hash of the app_data sent and received,
etc., plus the TLS server's signature over the whole EvidenceRequest-2. 

Finally, TLS client replies with EvidenceResponse-2, proving that client saw
what server sent.

Threats I've considered include: client or server "hangs up" at an opportune
moment in the exchange, one sends garbage, one sends something unexpected in
the app data.  I think all of these threats pose little risk to the parties
because of two facts.

1) before either party gets their EvidenceResponse, they can walk away and
claim "it didn't happen."
2) once one or more EvidenceResponses exist, these become an "I know you
know" checkpoint that both parties can roll back to.  

I hope what I've said so far clarifies the -00 and -01 drafts, and also
presents opportunity for discussion and improvement.  Since this email is
already long, let me use anther email for "How does the app need to
configure and interact with the TLS layer to get this done?"

Thanks,

-mark

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Jan 2007 23:55:18 +0100 (MET)

> say, "Sorry, we don't have records of this transaction..."

Sorry, but this is complete bullshit.

Browsers traditionally use up to 4 independent connections to retrieve
parts of what composes a Web page as seen by the user, and that results
in several parallel independent TLS-protected communcation channels.

Similar things happens in the middleware of other applications.

The majority of online-shops uses a crazy amount of http gimicks to
beef up their web-pages, including CSS and javascript, and you don't
seem to have looked at the raw source code of any of that stuff lately,
or you would know that this stuff is close to incomprehensible at
the network level.  Implementing some visualization software to
make sense from the captures&signed fraction of a raw datastream
will require magnitudes more code&time than implementing digital
signatures in a clean an understandable way at the application level
and the signed data can be made comprehensible for mere mortals
in raw form or compatible and verifyable with standardized software
(i.e. PKCS#7 / CMS).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 03 Jan 2007 14:57:14 -0800

"Mark Brown" <[email-masked]> writes:
> write call by the app) an EvidenceRequest also be created and sent.

Yes, but how does the *app* know that?

> The TLS

But there's a race condition here. The server doesn't know that
an EvidenceRequest-1 message is coming, so how does it know
to wait for it before executing whatever transaction the client
requested? Remember that TLS is a stream protocol, so the only
boundaries are at the higher layer.

If the server wants to follow the (reasonable) policy of not
performing any actions until after he's received signed instructions
from the client, then he has to block waiting for the client to
generate a signature. At minimum this requires interaction with the app
because (again) the TLS stack doesn't know. Moreover, without
some external agreement about how often these are generated,
you can get a deadlock. Now, the server could certainly ask for
a signature by sending his own Evidence-Request, but now you're
requiring app interaction.

> claim "it didn't happen."

But transaction rollbacks are expensive and complicated. It's much
better to simply not perform the transaction if the counterparty
hasn't authenticated. Moreover, in this system you *need* to
treat a failed evidence handshake (e.g., due to network failures)
as an attack and execute a transaction rollback. With ordinary
signed messages this isn't true since a network failure just
causes the counterparty not to get their receipt.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Jan 2007 14:25:54 +0100 (MET)

> say, "Sorry, we don't have records of this transaction..."

There is a real-world example of how to make correct use of digital
signatures as a legal proof.  Unfortunately the entire description
is in German, so not everyone will understand what this is about:

http://faq.1und1.de/access/neu/vertrags_und_rechnungsfragen_/3.html

This is about a German Internet Service Provider that offers to
send Email-based (instead of paper-based) invoices to business
customers and they offer a discount for using that service
(because printing and Snail mailing generates more cost that
 the purely digital approach).

Now the issue is, that in order for a business to get VAT refund
from the IRS, a business either needs to turn in a paper-based
invoice or alternatively a digital invoice with a qualified digital
signature that conforms to the German digital signature law.

So the approach taken by that Internet Service Provider is to
send the invoice as a digitally signed PDF using a qualified
digital signature, and they tell you on their Website (URL above)
how to actually verify that qualified digital signature.

"Evidence" at the raw network level for such a purpose is
such a horribly stupid idea.  I don't understand why we are
wasting any time talking about it.

-Martin

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 4 Jan 2007 08:41:28 -0600

Martin,

I think you're concerned about the HTTP GET side of my illustration, whereas
TLS Evidence here would be concerned about the POST.  I'm Ok to assume HTTP

> in several parallel independent TLS-protected communcation channels.

I also agree with you that what is "seen by the user" may be the assembly of
multi connections' GETs within the browser (etc.).  But TLS Evidence doesn't
worry about that; what is "seen by the user" is simply out of scope.   TLS
Evidence only creates a factual record of what sent and received if and only
if both parties digitally sign the same hash values (hashes over the sent
and received data).

The POST is the target for TLS Evidence in this illustration.  And instead
of generating a lot of useless evidence like "user fetched another JPEG"
(app designer's choice here; I'm just making a suggestion), it would be more
efficient to only capture TLS Evidence over something like the last step of
a "checkout" sequence.  Specifically, app designers should use/require TLS
Evidence for precisely those outputs/pages of the app where the app server
generates and returns to the client the "ticket" in response to the client's
input.  In HTTP usage, that's when the buyer (controlling the stack from
user agent down, including TLS) creates a new HTTPS/TLS/TCP/IP session,
specifies the use of TLS Evidence in the ClientHello, and then uses HTTP to
send all of the current page's cookies, visible field data, hidden field
data, etc. to the web server as POSTDATA, and then receives the web server's
response.  Typically that HTTP session would be immediately torn down at
this point.

The TLS Evidence generated in this illustration would show what the client
sent in POSTDATA and how the web server responded to the POST, i.e., the
HTTP application data that the app server gave back in response to the
POSTDATA.  Within this illustration's parameters, that reply app data will
either contain the "ticket" or some sort of an error message.  That's due to
the app designer's choice of when to require use of TLS Evidence.  

The point of TLS Evidence's use within this illustration is that anyone,
even a third party, can easily show that a particular web server gave some
app data to a particular client (to the extent the PKCs can show
authenticity), and that app data is not a forgery (unless the digital
signature crypto was cracked).  The goal here is not perfection, but to
still be helpful.

--mark

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Jan 2007 16:29:55 +0100 (MET)

> signature crypto was cracked).  The goal here is not perfection, but to

The point is, that this is entirely pointless.

TLS is typically used on a hop-by-hop basis, and the only connection
where it would make any sense is the one between the last hop on the
client side and the initial entry point to the server side.

In pretty much every serious deployment the front-door of a business
system runs on a host in the DMZ, and the only "valuable" thing
that this possesses is a keypair suitable for online authentication
of the server.  A business/organization would be quite stupid to
deploy keys with digital signature capabilities in any legally
binding sense on such a host.

Furthermore:
The last two Online-shops where I ordered computer parts explicitly
indicated that neither the successful completion of the "checkout",
and not even the "autometic confirmation email" sent as a result of
the checkout would be legally binding in any way for them to ship
the requested product for the displayed amount and conditions.

Only an explicit confirmation Email generated in their backend
system (usually sent within a business day) will confirm the
contract. (I don't know whether those involve human action(s).

TLS-based Evidence would be entirely useless in these scenarios,
because they already have had issues when the intermediate/frontend
systems failed (or were hacked), and the businesses don't want to
be held responsible for that.  A very common error is a typo in
the price of the web shop, and it did happen to companies like Dell.

It would be a pretty stupid idea to include the easiest and well
known point of failure (and point of attack) into the creation
of legally binding digital signatures.

TLS/SSL has been about online authentication, and it should firmly
stick to that archtecture.

-Martin

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 4 Jan 2007 11:06:44 -0600

Martin,

Personally, I can see how it could be to the seller's advantage to not print
receipts that customers could use -- that way, they can avoid being held
accountable.  

> contract. (I don't know whether those involve human action(s).

However, some buyers might want a solid receipt when making purchases.  Not
a receipt like the email you mention, since it really is not a sure thing
that the email will ever get to you or contain accurate information.  If
used, TLS Evidence could do a better job at receipts than this email system
you mention.

> binding sense on such a host.
... 
> of legally binding digital signatures.

"Legally binding" is out of scope, but the issue about DMZ is a good
security question.  

Using a DMZ or another kind of strong separation (for example partitions in
a MILS separation kernel) is the reason that TLS Evidence allows the PKC
used for TLS session authentication to be different from the PKC used for
signing the Evidence- structures.  However, separating out the signing
component (the TLS Evidence handler) from the TLS layer is probably overkill
for commercial applications.

Why?  Because no one can generate TLS Evidence by compromising only the
server's private keys.  TLS EvidenceResponse structures are only valid after
both TLS client and TLS server have signed them.  So for your scenario to
generate valid TLS Evidence you need the attacker to have compromised the
TLS server's authentication key and evidence key (they may be one and the
same though) and to have possession of the client's authentication key and
evidence key (they may be one and the same).  This is not very feasible
unless the attacker is the client.  

So let's say the attacker compromises the TLS server and both keys and
copies these down to his lab.  In the lab, the attacker generates a TLS
session with mutual authentication and TLS Evidence in play, dummies up a
request for a ticket that looks realistic, and dummies up a response that
also looks realistic.  Now we have a forged ticket signed by the real
server's PKC and a dummy client PKC.

The attacker knows that just about anyone could check the TLS Evidence
later.  So the attacker needs to make some hard choices.  Should the
attacker get the dummy client PKC signed by a CA?  Should the dummy client
PKC be signed by a CA that the TLS server trusts -- perhaps a CA that
charges money for its PKCs, or perhaps a CA operated by the TLS server's
organization?  Perhaps the app server shows the last 4 digits of a credit
card number used to pay for the ticket on all real receipts -- should the
attacker use a real credit card number in the app data sent in the lab?  Now
that credit card info is part of the TLS Evidence record.  Or perhaps the
app server requires the buyer to send in his/her name to be printed on the
ticket receipt -- should the attacker use a real name?  Etc.

The attacker would have to be pretty bold to use a PKC with his real name
and/or embed a real credit card number into the app data signed by TLS
Evidence.  If a credit card number was used, a suspicious third party could
check to see if the charge actually went through.  In a dispute, a third
party might ask for secondary identification -- show me the credit card,
show me your driver's license -- if forgery was suspected (the attacker did
grab both private keys from the TLS server by force...).  

On the other hand, you could buy a server certified at EAL6+ to do the TLS
and TLS Evidence for you, and that would make the foregoing discussion moot
by today's standards.  Key compromise of an EAL6+ box is supposed to be
pretty hard to do.

In any case, TLS Evidence makes no guarantees about the law / legality, or
that it prevents crime, etc.  What it does is to use cryptography to make
forgery more difficult.  This could be useful to applications.

--mark

---

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 4 Jan 2007 11:02:47 -0700

> unless the attacker is the client.

Isn't the entire point of an attack to harm the attacked?  Motives
differ for attacks.  The motives for attacks help describe/define what
attack is going to be carried out, and how.

As an example, let's look at the "disgruntled employee" concept.
Sysadmin, disgruntled, has possession of the traffic and
signature-evidence keys, as he's responsible for making sure they get
into the correct place and are used in the correct manner.

Owner or CFO or whathaveyou overlook this during employment/contract
termination.  (Which is ASTOUNDINGLY easy to do.)

Bingo, you suddenly have an attack against your business's legal existence.

> ticket receipt -- should the attacker use a real name?  Etc.

Should the attacker put an alternate server up, make it look like the
real thing, be authenticable as it... and let others connect to it
without realization that it's fake?

> grab both private keys from the TLS server by force...).

Or, be bold enough to let others do it.  Every one of the transactions
is individually actionable, and that can cripple a business with legal
fees.

> by today's standards.  Key compromise of an EAL6+ box is supposed to be

...except by people who have access regardless.

> forgery more difficult.  This could be useful to applications.

This is not something that can be solved at the network layer.  It's
an application issue, and needs to be dealt with as such.

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Jan 2007 19:12:49 +0100 (MET)

> receipts that customers could use -- that way, they can avoid being held

You get it wrong.  It is about businesses not wanting binding digital
signatures on data that has been produced by the most untrusted
equipment on their premises -- the machines in the DMZ.

It will cost you big bucks to have any such signatures created
on a EAL6+ certified piece of hardware, but that doesn't really
fix the real problem -- that the signatures will get applied
to transactions processed by a fancy web-shop (frontend) running
on LAMP or IIS and with pricing information that a vendor
must consider about as accurate as on printed advertisement.

The possibility to steal signature keys is just one aspect of the
security problems around the TLS Evidence proposal.

The larger problem is about the data that gets signed and the
interpretation of that data.  An attacker doesn't need to
compromise/steal the keys if he can get data of his choice
signed, e.g. by by subverting the vendors web shop application
or by subverting the entire client software (e.g. a trojan using
cross-site scripting of some sort).

> used, TLS Evidence could do a better job at receipts than this email system

PKCS#7 / CMS, signed PDF, XMLsig, whathave you are all readily available.

See https://www.global-esign.com/
for verification of legally binding digital signatures by a
government accredited CA on CMS and signed PDFs (as for the
Invoices of the German Internet Service Provider I mentioned).

SSL/TLS client certificates are still rare these days, and using
them for (legally binding) digital signatures would be a pretty
dumb idea security-wise.

One conceivable approach would be to use for secure client-side digital
signatures would be an EAL6+ certified USB-gadget with its own TFT-display,
keypad and crypto modules/key storage that can display (pure text-based)
contractual data and allow the user to apply individual digital signatures
only on small, known and trusted pieces of information as displayed on
the screen of the gadget.  That should be doable in the OLPC price range,
and be fairly secure even for home users running MSIE on Microsoft Windows on
a regular PC.

TLS Evidence is a flawed approach, because what is signed there is
a client software from software vendor A, usually completely outside
of control of an end-user B, talking to an (application) server software
for vendor X supplied by software vendor Y, and usually neither
user B nor vendor X are aware what information is really exchanged
(and signed) at the network level and how much of their (conscious)
actions has what kind of impact on what gets sent and signed.
It would hardly help them to know, since it largely depends on
what software vendors A and Y ship and whether their software
or machine has been trojaned/XSSd/hacked.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Jan 2007 19:57:46 +0100 (MET)

> requiring app interaction.

In many existing deployments its even magnitudes more complicated,
and it becomes exteremly obvious that TLS Evidence doesn't fit
at all into the TLS architecture.

Think about reverse proxies, "SSL accelerators", load balancers,
which are the entry point to application server farms today and
terminate the SSL/TLS connection and forward optional SSL/TLS client
certificates as header fields to the backend application engines
through various kinds of communication, and sometimes doing
request aggregation on the way.

If the application on the backend system would like to get
"Evidence" of a transaction using TLS evidence, it will have
to jump many hoops to (a) get signalling to the SSL/TLS terminating
host/component in the opposite direction of the regular communication
and also how to get that data re-transferred once it is collected.

Considering that it took Microsoft about >10 years after it was
standardized in the spec to actually support SSL/TLS client certificates
in WinHTTP (I don't know whether the hotfix is generally available yet),
I have little hope of an Evidence concept requiring client certificates
to go anywhere fast.

If you do consider "Evidence" for customers of Web Shops / Online Services
useful, then a proposal that can not do without client certs is a pretty
dumb approach.  The use of client certs is still extremely limited,
otherwise the shortcomings in Microsoft's WinHTTP would have been
noticed and fixed long before shipment.

As has been said before, secure receipts can be easily implemented
with the existing technology, with only a small application plugin
at the backend side and no changes to the middleware and no changes
to the client software.  Actually, several solutions are in
active use for over a year, some even with truely legally binding
digital signatures!

-Martin

---

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

Mark Brown wrote:
> worry about that; what is "seen by the user" is simply out of scope.

OUCH. OUCH. OUCH.

>
> TLS Evidence only creates a factual record of what sent and received
> if and only if both parties digitally sign the same hash values
> (hashes over the sent and received data).
> 
> a "checkout" sequence.

This is a totally flawed and insane approach!

But on the other hand, it makes an interesting business model:
As a Vendor, I can create (textual pages) with an order containing
the real price that I want to get signed (1,499,999.-) and I use
gifs to overlay this price in the form displayed to the user with
the background colour, so that the user sees (99,999.-).

Now in your model, the TLS Evidence is produce over the full amount,
while the information that the user saw, and what he intended to sign,
was a MUCH smaller amount.

Unfortunately, even if the user did make a screen-cap -- the screen
cap is unsigned, the gifs overlaying the three leading characters
of the full price are not part of the TLS Evidence, but the full
amount is part of the TLS Evidence.

Now if the TLS Evidence proposal leads to so many seriously flawed
"application solutions" from people discussing with the security geeks
on [email-masked], how much worse will be the outcome of applications
using TLS Evidence designed by the masses of security-unconscious
application writers out there?

-Martin

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 4 Jan 2007 14:21:11 -0600

Martin,

> An attacker doesn't need to
> signed...

Here's how to get useful data of your choice signed using TLS Evidence:
spoof the app server to the server-side TLS layer.  Attacker could lurk
around in the DMZ and intercept calls to the app server, impersonate the app
server, and send data of your choice back to the TLS layer that's doing TLS
Evidence.  A simple deterrent: use IPsec between the DMZ-located TLS box and
the app server on the internal network.  Stronger approaches could be used.

Except for out of band (out of TLS session) subversion attacks or straight
impersonation (as above), it's not realistic to believe an attacker can
obtain useful, doubly-signed TLS Evidence for data of his choice.  TLS
Evidence is hard to forge and similarly hard to create for data of your
choice.

If the attacker can succeed in an out-of-band subversion effort, then it's
probably easier for an attacker just to bypass TLS Evidence and go straight
at the web app or system of record on the internal network.  In these cases
there's no TLS Evidence at all -- and you may have bigger problems on your
hands.

Let's say the attacker doesn't compromise the TLS server's keys, but wants
to subvert the web app in-band.  So the attacker attacks the app server
while using TLS Evidence.  If so, the TLS Evidence will show what the
attacker sent (the message that subverted the web app) and what the attacker
received (a ticket).  So if the server retains the TLS Evidence then they
can show who subverted the app and how they did it -- with the attacker's
own signature.  That would be a dumb move on the attacker's part, i.e.,
"Here's evidence of how I subverted your server and extracted a ticket --
now give me my reward."  Does your attacker prefer civil or criminal legal
problems?  

Let's say the attacker also destroys the server's TLS Evidence -- well, does
the attacker retain his own copy?  Does the attacker show his TLS Evidence
later when the server app's organization has no record of the ticket?  If
the attacker destroys all copies of the TLS Evidence, then it can't be used
in any attack, defense, etc.

If the attacker just subverts the client, then the server app won't think
that the attacker/client has paid for the ticket and won't issue the ticket.
Where's the attack?  Does the attacker pull out his own credit card and pay
for the ticket, via the subverted client?  Then the evidence will show it.
The subverted client will sign it, and the server will verify that the
signature is correct -- all before the ticket gets created or sent.

Are there better attacks to get data of the attacker's choice both TLS
Evidence-signed and useful to the attacker?

> Invoices of the German Internet Service Provider I mentioned).

I am sure that TLS Evidence uses not rely on the German national CA law.
TLS Evidence does not require a state-run Certificate Authority while the
German approach you mention does.  Because TLS is an International standard,
it doesn't make sense to embed dependencies on German laws (or Utah laws,
etc.) into TLS.

Let's skip the legal discussion in this forum.

--mark

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 5 Jan 2007 17:34:12 +0000

I don't think this discussion is fair to the proposal, but in a way it is what I expected to see when bringing the concept of "evidence" to a TLS group.

If we leave the concept of evidence out of scope and leave it to the lawyers to worry about, is there any technical merits?

There is one that I think we should consider. If a client or a server want to ask its opponent to sign a portion of data, is there any alternative solutions that would work cross platforms.

PKCS#7/CMS or XML digsig is not an answer as it only provides signature format, it does not deal with the request and response logic.
Going higher up closer to the application requires standardization of solutions based on vendor specific interpretation languages such as Java or .NET.

The balance is a delicate problem. But I'm sure that if there is a solution that is technically sound from a protocol perspective, then there will be a way to implemented in a sufficiently secure way for many usages.

As to the security discussion earlier, a very common way to eliminate the insecure DMZ is to publish the web server from a secure front end firewall holding and/or controlling the TLS keys. Unless you can hack that firewall you won't get to the keys or the server app side of the information flow. In any case, just because there is a way to implement a solution badly, does not mean that there is no good way to do it.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: den 4 januari 2007 11:21
> To: Mark Brown
> Cc: [email-masked]
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00
>
> Mark Brown wrote:
> >

---

From: "Kyle Hamilton" <[email-masked]>
Date: Fri, 5 Jan 2007 11:52:00 -0700

> There is one that I think we should consider. If a client or a server want to ask its opponent to sign a portion of data, is there any alternative solutions that would work cross platforms.

Sure, if you want to define a protocol for it and not "embrace and
extend" the way that Microsoft is so fond of doing.

> PKCS#7/CMS or XML digsig is not an answer as it only provides signature format, it does not deal with the request and response logic.

...and this is a problem how?  Dealing with this in the network layer
(since TLS is supposed to look like the network layer to its clients)
is COMPLETELY not the correct way to do it -- perhaps a standardized
and hardened HTTP-like protocol, but even that is outside of the realm
of the TLS working group.  "I want this signed" is an
application-transport mechanism, not a network mechanism.  (No matter
that MS implemented "signed CIFS" and "signed RPC", those standards
aren't available cross-platform.)

> Going higher up closer to the application requires standardization of solutions based on vendor specific interpretation languages such as Java or .NET.

No, it requires standardization of solutions based on the protocol
communication.  Implementation of the protocol can be done in Java or
C# (.NET isn't a language, it's a runtime) or C++ or whatever is
appropriate for the implementation.  The Internet is
computer-language-agnostic -- it's recognized as "existing" simply
because implementation cannot be done without it, but if it was
reliant on C then you wouldn't be able to use Visual Basic,
Javascript, Jscript, VBscript, Java, C#, C++, or anything other than C
to write your Internet applications.

> The balance is a delicate problem. But I'm sure that if there is a solution that is technically sound from a protocol perspective, then there will be a way to implemented in a sufficiently secure w…

IF (there is a solution AND that solution is technically sound AND
that solution fits into the TLS layer) THEN (it may be implemented).
I cannot see it occurring, though.

> As to the security discussion earlier, a very common way to eliminate the insecure DMZ is to publish the web server from a secure front end firewall holding and/or controlling the TLS keys. Unless…

"a secure front end firewall holding and/or controlling the TLS keys"...

...you've just defined "DMZ".

Let's look at this from the viewpoint of "how can you prove that the
firewall is secure, and has no available attacks against it other than
DoS?"  Or, better yet, let's look at this from the viewpoint of "how
can I prove that my firewall is more secure than IIS?"

> Windows Security, Standards

...and as an aside, it's this type of tunnel vision and complete
idiocy which has earned Microsoft, quite rightly, the derision of
security professionals.  NONE of the proposed attacks have been
addressed, and these example attacks have all been "off the cuff"
examples.  It is axiomatic that we're not thinking of all possible
attacks, we're just bringing up the barest scratches of things that
make this proposal completely impossible.

Your suggestion of "secure firewall that controls the keys" is
laughable at best and dangerous at worst -- the entire point of a
firewall is to have a layer that provides no other function than to
protect what is behind it.  And even then, what is behind the firewall
can be attacked and subverted.  It merely limits the attack vectors; a
firewall does not make attacks impossible.

-Kyle H

(yes, I know this is a relatively incendiary missive.  I realize that
IIS's security, and the security of the underlying operating system,
have increased exponentially since Windows NT 4.  I realize that
Microsoft has made great strides toward reducing attack vectors.  But
I also realize that if attack vectors aren't nipped in the bud, they
WILL be implemented, and they WILL cause problems for millions of
users, with monetary outlay in the trillions of dollars before they're
fixed.  It is this which drives me to come down so hard on someone who
holds an office which cannot afford to make these kind of mistakes.)

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Jan 2007 19:57:02 +0100 (MET)

Stefan Santesson wrote:
> 
> I don't think this discussion is fair to the proposal,
> but in a way it is what I expected to see when bringing
> the concept of "evidence" to a TLS group.
> 
> If we leave the concept of evidence out of scope and leave
> it to the lawyers to worry about, is there any technical merits?
> 
> There is one that I think we should consider.
> If a client or a server want to ask its opponent
> to sign a portion of data, is there any alternative
> solutions that would work cross platforms.

Of course there are, and have been in active and successful use for
more than a year.

They're at least as portable as the TLS implementation itself.

>
> PKCS#7/CMS or XML digsig is not an answer as it only provides
> signature format, it does not deal with the request and response logic.

You're kidding.  You wouldn't know how to implement a function in
an application UI that requests a signed Document (PDF,CMS,XMLsig)
from the backend?  In the HTML-world of the Internet this thing
is called Hyperlink/URL.

When Kerberos5-PKINIT was polluted ("enriched") with CMS and OCSP stuff
you didn't seem to have a problem, and there is a proposal to ram
Kerberos/GSS-API into TLS, so it is a total mystery to me why
you suddenly try to make a problem out of CMS.

The big advantage with this approach is that you don't need any additional
APIs in order to retrieve TLS evidence from deep down, no new APIs to
perform verification of the signature, it works perfectly fine with
the installed base of middleware and client-software and best of
all, you don't need thousands of case-specific custom software to
make sense and visualize the raw network data of a TLS Evidence capture.

>
> Going higher up closer to the application requires standardization of
> solutions based on vendor specific interpretation languages such as
> Java or .NET.

If that was anywhere as difficult as you think, then we wouldn't
have PDFs or SWFs.

Since right now, and for some considerable time to come, frontend/client-
signing will still be rare and it is a total non-issue for the
backend/server-signing.

> 
> The balance is a delicate problem. But I'm sure that if there is a
> solution that is technically sound from a protocol perspective,
> then there will be a way to implemented in a sufficiently secure
> way for many usages.

TLS Evidence doesn't fit into the TLS architecture AT ALL,
and there is an irresponsibly huge hazard that apps will use
it all the wrong fashion and end users will be hopelessly
confused about whether a TLS popup is about online
authentication or a digital signature, so that a large
number of applications will get it totally wrong.

It is about a good idea as using pure liquide nitroglycerine.

Responsible security engineers should stay away from this
as far as they can.  Our standards should not only be secure,
but also fairly safe to use.

> 
> As to the security discussion earlier, a very common way to
> eliminate the insecure DMZ is to publish the web server from
> a secure front end firewall holding and/or controlling the TLS keys.
> Unless you can hack that firewall you won't get to the keys or
> the server app side of the information flow. In any case, just
> because there is a way to implement a solution badly, does not
> mean that there is no good way to do it.

Get real.

The only reason that we have DMZs is that "businesses" insist
on running feature-bloated, bug-ridden applications on the
public internet which will have serious vulnerabilities found
and published on a weekly, if not daily basis for decades to come.

It really doesn't matter which application vendor you pick, all
of them are affected, just that some of them are more attractive
targets than others, have more vulernabilities published on a
regular basis and therefore pose a higher risk for their operators
of successful hacks/break-ins.

DMZs are used to host the machines and "frontends" of web-shops,
as a first line of defense, and they are supposed to filter
and pre-process requests&data before submitting it for processing
to a backend system on the internal network which hosts the
vital company data.  By closely monitoring the traffic within
the DMZ and between the app/proxy in the DMZ and the backend
system, you have significantly higher chances to notice and
stop attackers from reaching your vital backend system.

This approach works remarkably well, and it is being done
that way for more than a decade now.

I find it quite distracting that everytime that I show obvious
vulnerabilities an a proposed application scenario making use
of TLS Evidence that someone says:  Oh, that is obvious fraud--
we don't worry about that, we can give it to the police and sue...

Sorry, but that is the stupid reaction from a markedroid, definitely
not from a security-experienced engineer.  A good design doesn't
have such vulnerabilities.  Substituting security engineering and
 good design with evidence collecting for law enforcement agency
and passing on the scapegoat to them is the most stupid approach
to security that I've ever heard in a working group of the IETF
security area.

-Martin

---

From: "Mark Brown" <[email-masked]>
Date: Fri, 5 Jan 2007 13:40:51 -0600

Kyle,

You bring up at least two good points: 

1) Aren't all keys/secrets known and potentially leaked by the sysadmin who
makes them? 
2) If the attacker compromises the keys, he can further the attack by
setting up a fraudulent web site, with all the trimmings.

Was I too quick to say, approximately, that TLS Evidence can deal with the
(catastrophic!) event of both keys being compromised on the server (the TLS
authentication key and the TLS Evidence signing key, considered as separate
even if they could be the same)?  I'm not convinced yet.

1) One good method for handling keys is to use a FIPS 140 hardware crypto
module.  Not just for algorithm acceleration, but specifically to generate
and store keys, especially keypairs.  The design for good key secrecy using
a FIPS 140 device is to generate the keypair on the device and then sign the
PKC request using the FIPS box.  Then all subsequent signatures should be
performed by the FIPS box.  The goal is to never have a human know the
secret key.  This is compatible and recommendable for both TLS
implementations and with the EAL6 separation kernel protection profile.

So, no, the sysadmin doesn't always know nor have the ability to compromise
the keys.  Just follow best practices, i.e., use FIPS 140 hardware crypto
well.

2) If both private keys are stored in the TLS implementation, and the
attacker compromises both (here we pretty much assume that FIPS 140 hardware
is not in use...), how effectively can he set up a rival web shop and
leverage these keys to commit fraud?

First, he's got DNS to deal with.  After all, the PKC bound to the stolen
key is bound to a DNS name.  So browsers that attend the fraudulent site
have to deal with the name mismatch between the cert and the URL.  Let's say
the browser's user blows off the warning and proceeds.  Let's say the user
sends in his/her credit card number etc. to the fraudulent site to make a
payment.  Let's say that the user actually got to the fraudulent site in the
first place (phishing implied?  Hack the links on the website?).

Next, the TLS Evidence (assuming the minimum, say that it's turned on only
for the POST of the final page) will show the URL and domain name used.
That's in the application data.  It will also show the certs used by the TLS
server, that's in the TLS handshake & TLS Evidence data.  TLS Evidence will
show the mismatch here.  

Hijacking DNS is an option for the attacker.  However, it's kinda slow, and
it definitely rings the front doorbell at the organization that lost its
keys and identity.  Most organizations start contacting the ISP that is
hosting the attacker at this point...FBI is another place to go...next it's
a public announcement (unless you're in CA, in which case you'd announce
immediately).

Finally, the attacker has to cash the check, so to speak.  Perhaps they just
happen to have an account with a payment processor -- but they know the
browser is holding evidence to their fraud.  Perhaps they just want the
credit card number & data.  Maybe they plan to sell the info on the black
market, or plan to make fraudulent card-not-present purchases.

Even when granted all these assumptions for bad things to happen in the
attacker's favor, it's a catastrophe yes, but it doesn't seem like the TLS
Evidence either causes it or exacerbates it.

In the end, the big worry is that the browser's user gave out his credit
card number to an attacker.  I think less-immediate actions on the user's
part like making promises to the attacker don't pose much risk.  The
attacker can't hold the victim to the promises, not in court.  The TLS
Evidence actually proves the fraud, so it's not an accomplice.  I think the
attacker would be better off to turn off TLS Evidence and not even use this
stolen key -- it can only hurt him.  

I still think that in comparison to a stolen TLS authentication key, a
stolen TLS Evidence key is relatively harmless.  In this kind of failure
analysis (catastrophic key compromise), failing safe is about the best you
can hope for.

And I still think that keeping private keys exclusively on FIPS 140
hardware, or an EAL6 box, is a "best practices" way to avoid a lot of this.

--mark
> From: Kyle Hamilton [mailto:[email-masked]]
> Sent: Thursday, January 04, 2007 12:03 PM
> To: Mark Brown
> Cc: [email-masked]; [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Jan 2007 22:10:12 +0100 (MET)

Stefan Santesson wrote:
> 
> I don't think this discussion is fair to the proposal, but in a way it is
> what I expected to see when bringing the concept of "evidence"
> to a TLS group.
> 
> If we leave the concept of evidence out of scope and leave it
> to the lawyers to worry about, is there any technical merits?

I do remember a funny statement, some along the lines:
IBM's Microchannel is actually a 48-bit bus, which is why it is so
expensive.  16 of those 48-bits are entirely reserved for lawyers,
only 32-bits are available for the user.

I have a serious problem seeing a technology promoted in the IETF
security area whoose only purpose is to provide business opportunities
to lawyers.

What the public actually expects from us security experts is that
we design protocols that are reliably safe and secure so that
the number of occasions where users of our technology need to involve
lawyers and courts go WAY DOWN.  If we do not raise the unemployment
rate among lawyers, then we're probably not doing our job in an
adequate fashion.

If one needs cleartext network traces of what goes in TLS and
what comes out TLS, that can easily be done today (in fact,
an application architecture which can not do that today is
seriously broken-- it is impossible to provide REAL support for
larger mission-critical application software without capabilities
to trace at various protocol levels and API/component level),
and the crap with the digital signatures is entirely unnecessary
for technical analysis.

If there are no real benefits in technical and security terms
in a proposal, then you're just wasting a lot of peoples time
in this forum.

-Martin

---

From: "Mark Brown" <[email-masked]>
Date: Fri, 5 Jan 2007 16:57:29 -0600

Eric,

I meant to say the rule is this: whatever app data you send, you MUST chase
it with EvidenceRequest.  So with this rule, server MUST expect
EvidenceRequest-1 to be paired with ApplicationData-1.  This rule is in
effect for the entire TLS session including any resumes.

> Yes, but how does the *app* know that?

App doesn't need to know.  App can ignore all Evidence- messages so long as
some component somewhere is storing them.  If app needs to store them, app
still doesn't need to be aware of the protocol rules.  As far as the app is
concerned, there's either app data (and Evidence- if it wants to fetch it)
or there isn't.  IF the TLS Evidence rules required that the TLS session be
shut down, then app will discover that the session is terminated on next
read or write attempt.

The new api here is to allow apps to getLastEvidence().  If they call this
in the middle of the session, or after the session closes or abends, the
semantics are the same: null, or the last Evidence- structure sent/received.
IF the app never calls getLastEvidence, that's Ok too as far as the TLS
layer is concerned -- maybe a wiretap on the TLS session is the preferred
method of persisting the TLS Evidence.

> boundaries are at the higher layer.

See above, the server has knowledge that: throughout this entire TLS Session
EvidenceRequests MUST follow ApplicationData "immediately".  If client gets
cold feet about the transaction it would be more polite to send an alert to
close the session.  But under these circumstances the client is not likely
to be DOS'ing the server -- server has authenticated client.

> requiring app interaction.

I think there's ways to address this challenge.  My solution is ok not
great.  Have the TLS server hold on to the last app data TLS record until
another app data or an EvidenceRequest arrives.  Don't notify, or have TLS
keep it locked away from the app, etc., depending on the style of
integration with the server app.  Now if the EvidenceRequest never arrives
presume it's because the line got cut.  Notify the server app of the socket
failure without delivering the last app data record.  Now the server app
faces the same problem that he faces whether he uses TLS, TLS Evidence or
just a socket, so the server app already needs to be able to deal with that
problem.

On the other hand, if EvidenceRequest arrives and there's a crypto failure
in it, TLS server should presume it's an attack.  There's no valid reason
for an error I can think of.  This is not a shrug and forget about it
situation.  Blacklist or revoke the client PKC, roll back the app
transaction with a severe error, fire up a pager, etc.

I think what I'm saying is that in a mutually authenticated,
evidence-generating situation it is correct to be strict on failures and
lenient on no-shows.  Both parties are very interested in this transaction,
and they will understand if, for the sake of security, there's some
inefficiencies incurred under rainy-day circumstances.

I also think that DOS attacks are less likely under mutual authentication
circumstances; if they occur, then you know who perpetrated them (at least
which private key(s) did).

> causes the counterparty not to get their receipt.

Yes, it really would be a pain to do transaction rollbacks.  But the premise
I want to start with is that the cost of a tx rollback has already been
determined at design time to be less than the cost of getting the tx or its
evidence wrong.  I don't want to try to pretend that tacking on TLS Evidence
won't cost you.  It will.  But in some cases the cost of adding this kind of
security (forgery resistance) is outweighed by the benefits.  It's just
another security trade-off.  

What we're talking about is failure and attack cases.  I want TLS Evidence
to fail secure whether the line is cut or an attack is underway.  But I
think since the mutual authentication has completed already it's overkill to
require TLS Evidence to fail secure AND fail efficiently (i.e. avoid DOS and
rollbacks).  Because server knows who is on the other end, server gives a
little more latitude, takes a little more risk of lost time.

--mark

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 05 Jan 2007 17:25:58 -0800

> effect for the entire TLS session including any resumes.

1. I don't understand what you mean by "whatever app data you send".
   Do you mean after any application write to TLS? Any record?
   Recall that TLS is a stream protocol. In the former case,
   how does the receiver enforce this rule? In the latter
   case, you're signing every record.
2. It seems to me that you've just required that every single TLS
   record (or at least short runs of records) be signed (plus
   a second signature by the receiver). Have
   you considered the performance and bandwidth issues associated
   here?

> If app needs to store them, app

I don't understand what this means.

> just a socket, so the server app already needs to be able to deal with that

I think "not great" is quite an understatement here. You've just
required that every TLS record write requires *two* signatures,
one from the sender and one from the receiver. This includes
record read/writes which the application doesn't even care
about having evidence for. Your typical brokerage transaction
requires 10s if not hundreds of separate HTTP fetches, each
of which requires one or more record in each direction. Doing
25 digital signatures for every transaction is an enormous
load on the server.

By contrast, message-oriented solutions are inherently more
efficient since you can sign at the message rather than the
record level and moreover you can sign selectively. Yes,
I appreciate you can use alerts, etc. to sign selective
portions of the stream, but now you're getting into the
case of application interaction again.

> evidence wrong.

Sure, but those aren't the only two design choices. In particular,
message-oriented signature schemes don't have this problem. 

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Sat, 6 Jan 2007 03:07:33 +0100 (MET)

Mark Brown wrote:
> some component somewhere is storing them.
>                   ... maybe a wiretap on the TLS session is the preferred

It's time to shut down the discussion in this forum for procedural violations
of the IETF Danvers Doctrine.  The IETF will NOT put wire-tapping
hooks into its protocols.

-Martin

> inefficiencies incurred under rainy-day circumstances.

First you say that lots of applications don't actually care about
(TLS) evidence, its mainly for a wire-tapping third-party, then you
suddenly say that those applications do want communication failures
when there is a problem with the TLS Evidence (which the most
apps don't care about), and then you go even further and claim that
those majority of dont-know-or-care-about-tls-evidence will
happily pay for the significant extra overhead in processing time
incured by a service they never asked for in the first place.

This is ridiculous.

---

From: "Mark Brown" <[email-masked]>
Date: Fri, 5 Jan 2007 20:32:36 -0600

Eric,

> 25 digital signatures for every transaction is an enormous

Turn on TLS Evidence only for one POST, skip the GETs.  There's typically
one important POST per transaction, the one before the
print-this-page-for-your-records response.  That's the page the user
typically prints for evidence of the transaction, despite its failings.

It doesn't make sense to create TLS Evidence for every fetch.  What would be
the point of being able to show for posterity that some browser downloaded
20 gifs, a css file and two javascript files?  None.

Regarding performance estimates, whether you use a FIPS 140 accelerator or
not, the cost of two digital signatures and the extra TLS Evidence messages
is less than the 20+ round trips made to load the page, even if the client
is using multiple connections.  

--mark

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 05 Jan 2007 18:46:33 -0800

> typically prints for evidence of the transaction, despite its failings.

Yes, but *now* you're in the business of having the application
require tight control of when signatures are created and when
they're available, which brings us back to the situation I
was complaining about in my initial review, where this isn't
just automatic, it requires esxtensively modifying the
app, plus the race condition/lockstep issues I raised in my
original review.

> 20 gifs, a css file and two javascript files?  None.

I totally agree with that. That's the virtue of a message signing
scheme like S/MIME.

> is using multiple connections.  

It depends what you're measuring, latency or CPU time. The dominant
CPU cost of SSL/TLS is the RSA key exchange (which is commensurate cost
with signing, of course)[0]. Providing evidence (independent signatures)
for a single request/response pair entails that the server do two 
additional signatures (one in response to the Evidence-Request for
the client request and one in its Evidence-Request for the response).
This substantially increases the server load quite a bit beyond the
symmetric crypto cost. And of course there's no guarantee that
a request or response goes in a single TLS record, which may or
may not be the case.

-Ekr

[0] C. Coarfa, P. Druschel, and D. Wallach. Performance Analysis of
TLS Web Servers. In Proceedings of NDSS '02, 2002. 0

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 8 Jan 2007 11:19:31 -0500

The juxtaposition of these two statements, coming from
the same source on the same day, is interesting.

What is the difference between a "network trace"
and a "wiretap"?  An application architecture that
stores trace data does not require modification (hooking)
of the protocol.  And a modification to the protocol
to transmit digitally signed data changes neither
the confidentiality properties of the protocol nor
the existence of application architectures that
store trace data.

Note that:
"the crap with the digital signatures is entirely
unnecessary for technical analysis."
is entirely correct.  But Danvers is a non-sequitur.

Ignoring lawyers, non-repudiation, and protocol
analysis, the question remains: is there any benefit
to providing data origin authentication at the TLS
layer?  In other words, assume the existence of an
evaluated high assurance "TLS Appliance" fronting an
application that is much more complex and dynamic
and difficult to characterize from a security
perspective.  Is there any benefit to having the
TLS box sign data instead of having the application
sign data itself?  I'm not convinced there is,
but regardless, it would be better to focus the
discussion on the relying party's ability to
validate signatures for its own benefit rather
than discuss taking those signatures to court.

Dave

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 9:08 PM

Mark Brown wrote:
> App doesn't need to know.  App can ignore all Evidence- messages
> so long as some component somewhere is storing them.

It's time to shut down the discussion in this forum for
procedural violations of the IETF Danvers Doctrine.
The IETF will NOT put wire-tapping hooks into its protocols.

---

From: Russ Housley <[email-masked]>
Date: Mon, 08 Jan 2007 11:43:56 -0500

Thanks Dave.  I appreciate your effort to get the group to focus on 
the question that is really being asked.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 Jan 2007 09:32:44 -0800

"Kemp, David P." <[email-masked]> writes:
> layer?

I don't think "data origin authentication" is the right term
here, since TLS *does* provide data origin authentication. The
client knows who he's talking to. What it doesn't provide is
third party proof of data origin authentication and more importantly
of message contents.

-Ekr

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 8 Jan 2007 12:58:42 -0500

Actually, I don't want to revive the NR-wars, but
the DoD certificate policy uses the term "technical
non-repudiation" to refer to "persistent data
origin authentication" that can be validated
outside the context of a session (a shared secret
context), yet attempts to distance itself from what
is visible at the HMI, the intent of the signer, the
legal liability incurred, data retention periods,
and all the rest of the stuff that goes with NR.
If the Handbook of Applied Cryptography had defined
TNR or PDOA, I would have used it, but alas it does
not.  What you said is (almost) what I meant --
integrity of message contents is a prerequisite
for, and is thus implied by, data origin authentication

Dave

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Monday, January 08, 2007 12:33 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Mon, 08 Jan 2007 13:48:27 -0500

Right, it is persistent, which is not normally a requirement of 
authentication schemes.  However, the point is to focus on the 
properties of the proposed mechanism and see if there is a community 
that would make use of them.

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 9 Jan 2007 17:18:46 +0000

Martin,

I'm trying to engage in a constructive dialogue. I don't know everything and I doubt that you do. So can we have this discussion with a little less flame?

I think you misunderstand my problem statements. Both user authentication and signing of transactions in interactive web services such as on-line banking has historically been problematic and forced users to use either external devices or download client plug-ins. I haven't followed this lately but last time I checked this was still an issue.

I'm simply curious whether this solution has a place or not. The solution itself does not have a serious security flaw. But the way it is used can, if used improperly.

I think we can leave the DMZ out of this. There are different architectures with different problems.

Stefan Santesson
Senior Program Manager

> Sent: den 5 januari 2007 10:57
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
>
>
> Stefan Santesson wrote:
> >

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Jan 2007 20:15:24 +0100 (MET)

Dear tls fanciers,

I want to apologize for my offensive language in this discussion,
it was quite inappropriate.  I'm sorry.

My problem is, I am REALLY scared by this TLS evidence proposal, because of

(a) I consider it a very bad idea to create protocols in a way that
    digital signatures over something when the signer and the
    receipients of the signed data are not fully aware and consenting
    about every meaningful bit in the signed data and also fully
    aware and consenting about each signature operation

(b) its obvious, real and enormous potential of abuse of the proposed
    "application doesn't know, TLS stack collects evidence for third party"
    approach.

(c) I consider it an extremely bad idea to subvert the current
    TLS architecture and abuse a key pair that has been used
    in a proof-of-presense for online authentication for
    digitally signing of raw communication data.

(d) because it archtectually doesn't fit AT ALL into basically all of
    the existing (serious and security-conscious) SSL/TLS deployments
    that *I* know

(e) because of the many and serious security vulerabilities that will
    arise when this technologies becomes available in the installed
    base of SSL/TLS deployments

The architecture is a security disaster for many threat models that
I can think of, and if the response to this is "Oh, I don't care
about your threat models, I have my very own limited threat model
and very esoteric deployment where your concerns don't matter,
and should they do I'm confident that some lawyer can take over
and deal with the damage and probably sue, then this really
scares the shit out of me.

In the IETF, we normally try to come up with good engineering
solutions.  And if there are clear architectural problems
in not so uncommon SSL/TLS deployments integrating this
proposal, and also clear security vulerabilities for common
deployments, then an effective denial (oh, that's not the
usage scenario I'm looking for), is unlikely to get us
anywhere near a generally useful protocol extension
that integrates smoothly with existing deployments,
is safe to use and very difficult to abuse.

Stefan Santesson wrote:
> 
> I think you misunderstand my problem statements. Both user
> authentication and signing of transactions in interactive
> web services such as on-line banking has historically been
> problematic and forced users to use either external devices
> or download client plug-ins. I haven't followed this lately
> but last time I checked this was still an issue.

I do NOT consider this an "ISSUE", it is the only reasonable approach,
is less confusing to the user in that there is a huge difference
between online-authentication and digital signatures and
are much harder to abuse in that digital signatures are going
to be pushed out to users in a covert fashion.

Why does Microsoft want a tigther integration between TLS
and Kerberos authentication?  Because this is what customers
desperately want in order to do single Sign-On.  Just that
the TLS Evidence is mutually exclusive with a lot of things,
including cert-less single sign-on with Kerberos.

One generic approach to creation of digital signatures
(or two, one for the frontend and one for the backend),
that will work independent of the online authentication
scheme that is being used will be so much better for all
of us, and in particular for the average end user.

> 
> I'm simply curious whether this solution has a place or not.

TLS Evidence is the most evil protocol extension (proposal) I am aware of.

>
> The solution itself does not have a serious security flaw.

On my scorecard it has several security flaws.

>
> But the way it is used can, if used improperly.

That's an interesting way to put it.
If I get around to it, I'll put it up for the next BigBrother award.

> architectures with different problems.

Really bad idea.  DMZ has significant security benefits and
is being used and necessary in many SSL/TLS deployments.
It already was a good idea 10 years ago, when you didn't
have weekly 0-day vulnerability reports.

Responsible sysadmins of large companies do not only use a DMZ
to seperate the company network from the internet, they also
have one or more internal networks seperated with a DMZ
from the company internal network.  And even without a
"full blown" DMZ, the main characteristic of a single entry point
through an SSL Accellerator or Reverse Proxy with Load-balancer
is the norm for large-scale application deployment using
web-based presentation frontends.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 9 Jan 2007 19:52:50 +0000

Martin,

Thank you for your efforts to explain your position.

Let me first clarify that I'm not arguing for this solution. I have my own doubts. I'm just looking at it with an open mind.

A few comments;

What this proposal do technically is to offer a way to sign a portion of the data flow using TLS keys. That is all it does it does without a security flaw (thus evidence in my mind is a bad word in this spec).
It does not provide any evidence of user consent. If any attempt was done to do so at the TLS layer. I would object loudly.

Providing evidence of user consent is a separate and complex issue where this might be a building block, but not the complete solution. The same is true for many other "solid" security protocols providing data integrity and data origin authentication. CMS as a standard does not guarantee user consent, but it can be a useful component in a larger solution doing so.

Clarifying my DMZ remark:
DMZ is often an important component of a system architecture. Looking at individual applications, DMZ may be a good or a bad choice. The challenge with using a DMZ is sometimes that you may have to open many holes through the back end firewall to allow the front end application in the DMZ to talk to back end resources. So in some cases an alternative is to simply put a proxy in the back end firewall with application level inspection, thus reducing the number of open ports and encrypted channels through the firewall. Modern network security design simply offers many valid choices.

Stefan Santesson
Senior Program Manager

> Sent: den 9 januari 2007 11:15
> To: Stefan Santesson

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Tue, 9 Jan 2007 15:34:34 -0500

> to be pushed out to users in a covert fashion.

I agree with the above statement from Martin. Majority of the banks found
ways to manage the risk. If the issue was raised 10 or more years ago it may
have been different. BTW, when I used wells fargo (wellsfargo.com) in 2003 I
was able to transfer money between accounts with a simple user name /
password authentication. But I did hear about other solutions employed by
non-US banks - but they look at them as a satisfactory solutions.
-Omirjan

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Jan 2007 23:10:43 +0100 (MET)

Omirjan Batyrbaev wrote:
> 
>                                         ... Majority of the banks found

I don't think that Online Banking (customer<->bank) is an area 
that is in desperate need of (TLS) Evidence.   In many if not most
scenarios that I know, the customer has to deal with / pay for
the majority of fraud, making it an "externality" for the bank,
which is why e.g. there are lots of el'cheapo ATM cards
in use (at least here in Germany), i.e. simple magnetic strip cards
that can be copied, and only its use protected by a 4-digit Number/PIN.

Online Banking (at least here in Germany) often involves an
OTP-style authentication (TAN) to authorize each individual
transaction.  Personally, I'm fine with that (although I will NOT do
Online Banking in an Internet Cafe or from arbitrary people's PCs).

As you mentioned, there are consumer protection acts that shield
customers from some of the bad things around online shopping
(at least in Germany, consumer protection curiously does not cover
 many aspects online and offline banking), and so a signing scheme
like TLS Evidence scheme might not help businesses, and due to
the data protection standards in the EU, such a TLS approach
may even be illegal in a lot of scenarios or impose a lot of
additional duties or non-obvious responsibilities on businesses.

Businesses must provide accurate information about stored/archived
data that can be linked to a subject.  The permission to store that
data can be revoked by the subject at any time.  If revoked, the
business is required to completely delete all records.
Not complying with the deletion request is a "federal offense".
Tough luck if TLS Evidence was blindly streamed to write-once
media...

Those requirements don't apply to wire-taps of federal agencies,
of course.  And when/where they apply (after a secret wire-tap
that resulted in no legal action), they "sometimes forget" to tell
the subject and delete the records...

In one of his Emails, Mark wrote "Your typical brokerage transaction",
maybe he was thinking of inter-business, or more specifically
inter-banking, broker<->bank, bank<->bank, broker<->broker
transactions in the financial area.

I consider it somewhat strange to design an "evidence" scheme
that will be difficult to process/interpret automatically or
programmatically because of a lack of standardization of
how to perform the verification and how to make sense of
the gobbledigoo that travels at the lowest level of the
communication.

By using standardized contents it will be much easier to process
the data programmatically, and you could use even 3 signers:
both peers and a timestamping authority.

TLS Evidence requires interactive online communication, an
application-level signing approach can easily work without
transport, accross arbitrary hops/links, with queueing or
batch-processing, via Email, and on and on, i.e. entirely
independent of the nature and persistence of the communication (link).

If one would design the "transaction evidence" from the communication
link with clear&explicit application-defined semantics, then it would
be possible to programmatically check the archived "evidence" against
the app transaction logs on the backend on a regular basis in order
to detect differences (du to bugs or system manipulation in the
backend) early on.  With a raw dump of the communication data this
is going to be quite difficult and context-sensitive to changes
of the application (data stream), and less likely to be done.

-Martin

---

From: <[email-masked]>
Date: Tue, 9 Jan 2007 15:41:42 -0800

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.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 9 Jan 2007 22:42:15 -0500

On Tue, 9 Jan 2007 23:10:43 +0100 (MET)

> that can be copied, and only its use protected by a 4-digit

That's very much dependent on local laws.  In the US, it's generally
the bank that pays, partially in response to competitive pressures.
And there are still plenty of ATM cards, with just a mag stripe and PIN.
(See p. 203 of Ross Anderson's "Security Engineering", which you can
download from http://www.cl.cam.ac.uk/~rja14/book.html -- that page is
in chapter 9.)

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 10 Jan 2007 16:43:54 +1300

Martin Rex <[email-masked]> writes:

>I want to apologize for my offensive language in this discussion, it was
>quite inappropriate.

I've been sitting back watching the debate go on and on for awhile (which is
pretty unusual for me :-), and this proposal seems both extremely
controversial and beset with large numbers of problems.  In this case why not
give it either 'Experimental' status (in order to gain more experience with
the can of worms that it opens up), or make it a private RFC rather than a TLS
WG item?  That would seem to resolve the problem, because I'm not sure that
continuing debate will do more than point out even more problems with it.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Jan 2007 15:50:57 +0100 (MET)

> within 5 years, via best practices policy, to be enforced by 

I thought about the EU data protection act a little further,
and I'm convinced that in case that the signature identifies
an individual subject, then persisting the TLS Evidence data
is probably almost always going to be illeagal within the entire EU.

See
http://europa.eu.int/ISPO/legal/en/dataprot/protection.html
and
http://www.e-dialog.com/pdf/2003_12_EU_%20Data_%20Protection_%20Act%20POV.pdf

Although it is possible to ask each individual subject for permission
of storing the data, there are so many formal requirements that
a blind capture of the communication stream at the network level
will make it difficult to impossible to even obtain a formally
correct confirmation of user consent before persisting the
data.  A list of issues:

    - the subject's consent must be obtained before persisting the data

    - the subject's consent must be absolutely voluntary, asserting any
      kind of pressure on the subject is a criminal offense

    - the consent agreement must contain a DETAILED list of the
      information that is to be persisted, a description of exactly
      what is going to be done with it, how long it is going to be
      kept, whether and exactly which third party will have access
      to the data and for what specific purpose.

    - the subject may revoke the consent to store/persist the data
      at any time with no reason given,
      with the effect that all recordings of the data must be DELETED
      all third parties that were authorized to receive this data
      must be notified of the revocation of the consent agreement
      and also DELETE all records of the data.

    - everyone who stores/persists the data must provide detailed
      information on what data/records is/are kept if the subject
      asks for it.

With the signature on the raw data, it is impossible to delete
unnecessary data without invalidating the signature/evidence.

The EU data protection act also has a requirement that persistance of
data that can be linked to an individual subject MUST be minimized.

TLS-Evidence covering a HTTP GET can easily violate this rule by
containing a "User-Agent:" header identifying a users OS make&release
and Browser Make&version, and potentially worse, an off-site
HTTP-Referer when deep-linking was used to get here.  For the
business transaction, a trace&signature of the transaction (request)
at the application level will not contain User-Agent: and Http-Referer:
so TLS Evidence is clearly inappropriate technology.

Producing a formally correct consent agreement to properly identify
such details are really challenging, but they're impossible without
interpreting/decoding the entire contents of the recorded (raw) data.

Obtaining the consent agreement with a detailed listing of what
data is going to be persisted will be impossible without significant
changes to the (communication architecture) of an application.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Jan 2007 16:02:22 +0100 (MET)

> fragments (or complete records) to the assured application 

I'm sorry, but I completely fail to understand why it is
necessary to sign and persist the entire raw network
communication for that purpose.  From what you describe,
the only thing that is being programatically done is
the verification of a signature, potentially with a different
cert than what was used to authenticated the original TLS
connection.  I really don't see why it one cannot use
another approach to perform a secure "channel binding"
with mutual signature verification that does not have
any of the serious security implications of the TLS
proposal.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 10 Jan 2007 10:21:21 -0500

Like cookies destroyed grandma's trust in the SSL brand?
Yet how many web sites still use cookies, and how many
browsers allow users an easy way to both disable cookies
entirely or selectively, and delete stored cookies
entirely or selectively?   If cookies are such
a trust buster, why are they still used?
A: Because they provide a useful capability.

Browser support for TLS extensions would be just as much
under the user's control as cookies and ciphersuites.
This extension doesn't even exist for grandma unless
she goes to the trouble of obtaining a client cert -
is your grandma that tech-savvy?  And even if she can
request and install a client cert, there is no stealth
involved in that process :-).

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.

Dave

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Jan 2007 18:52:40 +0000

After paying careful attention to this debate, I would like to summarize my view on this proposal and give my recommendation to the WG.

My conclusion is that if the legal perspective of this proposal is removed, then it has potential and I would therefore vote YES to accept this draft as a TLS WG item.

The proposal can provide a relatively simple mechanism to authenticate events, such as agreements, conducted over a TLS session and there is no working, off the shelf, alternative solution available today that works cross platforms.

Example scenario:
The server side wants to present a some data to the client that the user has to accept. Such as agreeing to a purchase order.

If this is to be a signed agreement, we have building blocks like http get, CMS, XML DigSig and WS*, but they don't provide a complete solution for the whole chain of events from formatting the request from the server to invoke a signed acceptance, presenting the data in a way that is processed and uniformly displayed by the client, UI invocation for user consent, signing and returning the signed data.

This proposal provides an interesting "low budget" alternative by adding authentication to approvals that otherwise work just the way most businesses do today (based on plain http) but where the conversation making up this "acceptance" could be authenticated by a signature. This would add to the current level of security of a procedure that is already in use in many businesses. Adding this feature would have minimal impact on current application software and business systems. By doing this on the TLS layer many aspects of the "acceptance" could automatically be recorded such as client software version and html code provided for the data presentation. Things that adds to the audit value but would take enormous standards effort to get captured and documented in an application layer signature.

The TLS group should not speculate in the legal consequences of adding this authentication mechanism, but should make sure that the protocol is well defined and technically sound. Special attention should be given to development of a good security considerations section.

In the end of this process we will either have a good and solid protocol extension to TLS or have reached a point where we realize that this is a bad idea. But I strongly believe that this document, if developed, should be developed under TLD WG review and change control.

Stefan Santesson
Senior Program Manager

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Jan 2007 21:32:15 +0100 (MET)

Stefan Santesson wrote:
> 
> The proposal can provide a relatively simple mechanism to
> authenticate events, such as agreements, conducted over a TLS session
> and there is no working, off the shelf, alternative solution available
> today that works cross platforms.
> 
> Example scenario:
> The server side wants to present a some data to the client that the
> user has to accept. Such as agreeing to a purchase order.

OK, I'll try to make it short:

There is absolutely NONE, ZERO, NIL chance that this can be used
in customer<->business relationsships in the European Union, because
it is incompatible with the EU data protection directive in many ways.

-Martin

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Wed, 10 Jan 2007 15:54:42 -0500

see inserted:
----- Original Message ----- 
From: "Martin Rex" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 10, 2007 3:32 PM
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

> it is incompatible with the EU data protection directive in many ways.

And in US they mostly look at digital signature as a way to strongly
authenticate the user and not as a replacement for a written signature. At
least in US and at least one big b2b exchange said that they have a simple
non-repudiation practice: they make customers (buyers and sellers) to sign
the agreement that stipulates that whatever is the record of a transaction
in the exchange database that holds as the non-repudable record. (the name
witheld due to the NDA). So they have no need for even application level
non-repudiation. So as Stefan pointed out the b2b simply uses http today. In
my meetings with b2b customers they say that they need performance not
digital signatures. Majority of US financial institutions do not even
symmetrically encrypt the data on their intranet for want of better
performance (and they still meet the audit requirements circa 2003) so even
the use for data retention is questionable. b2b exchange customers even want
to replace internet with private lines in order to get rid of the latency
associated also with inernet security requirements. As ekr pointed out too
there is a serious performance penalty that comes with evidence. b2b
customers that I have met if they could vote will vote for performance and
against performance degrading evidence.
--Omirjan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Jan 2007 21:29:33 +0000

Martin,

I would expect that the reality around this is more dynamic and complex than your statement.
But it is an interesting aspect that should not be neglected.
I will do my own checks.

Stefan Santesson
Senior Program Manager

> Sent: den 10 januari 2007 12:32
> To: Stefan Santesson
> Cc: [email-masked]

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 10 Jan 2007 17:06:55 -0500

On Wed, 10 Jan 2007 21:32:15 +0100 (MET)

> it is incompatible with the EU data protection directive in many ways.
The Danvers doctrine, RFC 1984, and RFC 2804 cut both ways -- the
IETF's protocols are supposed to be based on technical merit, not
political-layer decisions.  It's quite inconsistent to oppose this
because it conflicts with one government-layer policy while not
opposing, say, unescrowed strong crypto because that conflicted with a
different government-layer policy.  (Please read my publication list
before accusing me of being a stooge for the NSA...)  There are two
questions: does the proposal have technical merit, and is there enough
"market" demand that it's worth the IETF's time.  (I think your
specific claim could be argued both ways, but in the spirit of what I
just said I won't address that issue.)

I would have liked a longer -- a much longer -- discussion in the
draft of how this facility might be used.  For example, I don't see it
as particularly useful for https unless and until there are html-level
tags that specify when evidence creation should be used.  Perhaps the
values being uploaded could be surrounded by <evidence>...</evidence>
tags?  Many people on this list have mentioned the issue of the poor
coupling between TLS and application-level semantics; I would like to
see suggestions of how to do it.  Without that, it's hard to assess
either the correctness or the need for this protocol.

---

From: <[email-masked]>
Date: Wed, 10 Jan 2007 14:36:10 -0800

Martin,

I don't why the claim on the EU Directive is true, as TLS 
Evidence contains a mandatory "opt-in" mechanism. And, I 
assert, neither of the authors is arguing their case very 
well in the document or their explanations given this is a 
transnational audience.

> it is incompatible with the EU data protection directive 

Despite pro forma optin mechanism compliance, its normal in 
US practice for US companies to subvert the Euro-intent on 
such opt in regimes using safe harbor and other procedural 
tricks : in the US, you will find that as a consumer one 
cannot connect to one's commodity service provider if you 
FAIL TO AGREE TO OPT IN to the data retention policy.

US practice on "privacy-regime subversion" goes further: the 
politics of Federal and State governments often manipulate 
public policy (usually and LEGITIMATELY by funding mandates) 
so that the insurers inevitably set the audit/practices 
standards so all providers REQUIRE the retention policy, 
thus subverting the consumer-protective optin policy intent, 
set by the EU Directive. but its America! They get to do 
what they want, too, for their own consumer standards!

This is just like today: phone a US health account insurer 
to discuss a claim, and it will tell you they are recording 
the call "for quality purposes". You can opt out, and thus 
the provider will simply drop the call, interdicting "phone" 
support... Your optin choice! Of course, it's a semantic lie 
(the "quality" part; its their to collect evidence of your 
claim fraud...); but this is reality for consumers. If YOU 
don't drop the call your side, post notification, you have 
accepted their policy by failing to opt out. The legal 
presumptions have been set to suit this bias, in the US 
sphere. And, we just say a manual legal-obligation passing 
protocol in effect. Could TLS Evidence do the same, for the 
web-equivalent via https? That is the real question the 
authors are posing.

note, I'm not saying to IETF: don't do TLS-Evidence-type 
obligation passing protocols: I cant, having proposed them 
myself in similar forums, and can see great value in 
instrumenting privacy policy (and other 
"battle-of-the-terms" negotiations.

But, on "wiretapping", we ALL ON THE SAME SIDE, we have to 
move beyond good/evil level debate over 
wiretapping/data-retention etc. As US govt policy has clear 
given ground - by acceding to decent confidentiality 
channels in standards - we have to reciprocate and thus move 
the privacy debate on... beyond "sticks and stones" grade 
name calling debates of the last 20 years.

TLS Evidence is broken in terms of SSL architecture; but it 
can be fixed. The only question is, do we want to, and is it 
the right timing? For example, should IETF simply wait 2-3 
years until the US national id card debate is more settled, 
first?

---

From: Martin Rex <[email-masked]>
Date: Wed, 10 Jan 2007 23:46:48 +0100 (MET)

Steven M. Bellovin wrote:
> different government-layer policy.

The EU data protection directive is not like any other "policy".

It is there to protect every citizen from inadequate technology
that poses a risk to privacy by gathering and storing unecessary
personal data without a subjects explicit consent.

By requiring high ethical standards, it is a useful quality
control of the real merits of a technology as far as privacy
and protection of personal data is concerned.  It improves privacy
in many ways and deters many kinds of wire-tapping.

I know that not many countries allow their citizens to enjoy
such freedom, but that should not preclude from understanding
the obvious merits/benefits if you look at it.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 00:34:56 +0100 (MET)

I know that there is are no (effective) legal safeguards in the US
for personal data.  This is why I am worried about the TLS Evidence
approach.

Just because US citizens are entirely unused to enjoying privacy
and protection of their private data, doesn't mean that all the
rest of the world should not be entitled to such freedom either
by ignoring this security aspect when designing technology.

> FAIL TO AGREE TO OPT IN to the data retention policy.

That's not quite accurate.  Several courts in europe have
already ruled that the safe harbor trick is ineffective and
therefore illegal.  Currently, only governments are still playing
some tricks, for businesses this approach may easily
become a very costly expedition.

Many europeans chicken out and do not insist on their privacy,
and incredibly many sign "away" the privacy they're entitled
to all to easily.  But, as indicated, everybody may revoke
their agreement at any time, no reason required.

This is why there are several safeguards, like the requirement
to provide a detailed list of the information that is going
to be collected&persisted plus an exact description of the
purpose which the consent agreement will authorize.
For every additional information and every additional purpose
a new explicit agreement/permission must be obtained.

The German Telecom lost also the final appeal
when the subscriber of an internet flatrate sued them for keeping
a record of his DHCP lease (or equivalent) after he disconnects.

> support... Your optin choice!

Here, you could easily get a cease-and-desist order with a daily fine
for ever further day of non-compliance for such business practices.

The courts here take the "voluntary consent aggreement" requirement
in the data protection directive very seriously.

-Martin

---

From: <[email-masked]>
Date: Wed, 10 Jan 2007 15:47:41 -0800

Come on David; we can do better than this, as (secure) 
networking engineers.

Cookies are not used for session stickyness/persistence in 
https, or for failover prep, in HA internet data centers 
doing 1000-2000 simultaneous handshakes for https sessions. 
In layer 2 switched and layer 3 routed data centers (of 
which I've built 2, with teamed nics, redundant gateway 
convergence, deterministic convergence, etc ), it's the 
SSLv3 session id that is the "cookie" for controlling that 
path of the fragment through the switches. This is why it 
the handshake design changed, between SSLv2 and SSLv3 - to 
allow for early loadbalancers to control the path take by 
the fragment once it gets out of the layer 3 space into the 
forwarding path set by the layer 2 STP(s).

In military varieties of this, the sessionid sticky state 
controls which 803.11q vlan paths trunks that fragment can 
go over, so the convergence characteristics are known during 
protocol or device failure condition. This allows fixed 
timing -  enforced by the topology of the data center, not 
by certain hacks like someone stuffed naively put into TLS 
1.2.

----- Original Message -----
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 10, 2007 7:21 AM
Subject: RE: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 09, 2007 6:42 PM
To: Stefan Santesson; [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 01:21:18 +0100 (MET)

Steven M. Bellovin wrote:
> political-layer decisions.

I fully agree with you.

I'm sorry for giving a poor explanation of the technical merits
of a design that is conforming with the requirements of the
data protection directive.

My impression is that there is a significantly different perception
of that value/merit.

Someone who was born blind has difficulties to imagine what it means
to be able to see and therefore doesn't miss it.

An adult who looses eyelight due to an accident will miss it badly.

I'm in favour of strong crypto, strong privacy and strong protection
of personal data.

>
> (Please read my publication list before accusing me of being a stooge
>  for the NSA...)

Don't worry, Steve.  I know some of your publications and have
seen and heard you on several meetings/conferences during 1995-2000. 

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 13:07:10 +0100 (MET)

Stefan Santesson wrote:
> 
> If we leave the concept of evidence out of scope and leave it to the
> lawyers to worry about, is there any technical merits?

Well, this amounts to

  Capture&sign it all the bits and let the lawyers sort it out.

and bears some similarity to the concept

  Shoot 'em all and let God sort 'em out.

Think about what this means for a contract between two
parties:  Instead of using a blank sheet of paper to write down
your contract, you take an arbitrary printed multi-page book from
the shelf, write the clauses of your contract on the remaining white
spots and pages of that book and require the signature on the entire
book and feed the result to the lawyers.

[email-masked] wrote:
>
> 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).

One of the guidelines of security engineering (according to Google
it seems to originate from Mark Twain) goes like this:

   Put all your eggs in one basket, and WATCH THAT BASKET!

The TLS Evidence proposal applied to the above means that you
put up additional baskets and distributed eggs on every access.

Since the proposal is quite secretive about the specific requirements
and usage scenarios leading to this proposal, it is difficult to assess
whether adequate enigneering went into the proposed solution to meet
the requirements and minimize risk and security impacts/collateral damage.

-Martin

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 12 Jan 2007 01:27:43 +1300

>  Capture&sign it all the bits and let the lawyers sort it out.

More importantly, what does it give us over "log the transaction in accordance
with established business practice and legal precedent"?  This whole
discussion seems to be following the path of the nonRepudiation bit boondoggle
in which a bunch of techies came up with a cool idea that, once lawyers looked
at it, was found to be totally meaningless.  If you're trying to define a
mechanism that has legal standing then you can't leave the lawyers out of it
or you'll just end up with another nonRepudiation bit.

Peter.

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Thu, 11 Jan 2007 09:39:04 -0500

see inserted:
----- Original Message ----- 
From: <[email-masked]>
To: "Kemp, David P." <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 10, 2007 6:47 PM
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

> path of the fragment through the switches. 

But what happens when the application session spans multiple session ids?
-Omirjan

This is why it

---

From: <[email-masked]>
Date: Thu, 11 Jan 2007 06:57:23 -0800

> impacts/collateral damage.

The document was very much like the document on a PRF 
pattern, done in collaboration with Eric, which didn’t even 
pretend to be a complete disclosure! That one said to me: 
shut up and rubber stamp, аппаратчик! But, there was a 
commonality of writing style style with TLS Evidence; but 
only one that is in common with the better levels of 
American security engineering.

And, both reeked of excellence. American writing style for 
technical English, minimalism of words, extreme binding of 
word use to concepts, and no explanation (except through the 
style itself). Good engineers don’t explain, they specify.

The first group and last groups of paragraphs of the 
document are the most revealing, once you infer the 
underlying security/legal/business doctrines that belie the 
design reasoning. And Mark revealed the background art he is 
applying, to be fair to him: a cross of ABA-ISC digital 
evidence project goals and mandatory integrity levels for 
some NCTS project routers doing risk compartmentalization 
(old Biba stuff, presumably).

For the former, the motivation seems to be addressing the 
practices required for the revised rules for Federal 
evidence (lalala lawyer/CPA land security "controls", 
"audit", "operational risk management"... doctrine) and for 
the latter, the motivation is applying multi-level message 
routing (where he kept referring to EAL6 "functional" 
assurances and multi-level A-routers whose critical SEFs for 
this TLS_evidence-enhanced https are implemented using the 
TCB doctrine). (N.B. it reminds of the $50M that 
DeloitesTouche spent on trying to work up a similar VAN 
business concept for their assurance practice, about 1996 
trying to get in on the .com boom, inserting :assured: X.400 
MTS relays into the flow of business email)

So, lets look in more detail. The first group provides 3 
assurance building blocks: 1) collect admissible evidence 
pertaining to a battle-of-the-terms negotiation, 2) apply 
the accord to control access to communication capabilities, 
and 3) audit stored/"wiretapped" records of the handshake 
agrement sand the APDUs within the recording regime of the 
alert blocks. #3 includes mandatory storage of all the 
"private" sessionids and ciphersuites, security labels..., 
Swedish QUALIFIED CERTS with Pseudonyms... and any and all 
custom record_types used in a second and later full/resumed 
handshake. Its clearly a BigBreak, from the privacy goal of 
the (currently) Proposed Standard, that has been unchanged 
since the SSLv3 I-D submissions.

The last group makes it clear that material that was 
expected to be private, being "confidential" on the wire 
(because of the bulk ciphering between the T-bridges, or 
between the MTS/https relays at layer 7) MUST NOW get 
cleartext stored, SECURELY. it gives the example of just 
storing the entire SSL (ciphered) stream, presumably with 
(escrowed) copies of all the asymmetric key used to unwrap 
it all again, later, during court testing.

For Stefan's point, finally, I could see the "TLS Evidence" 
signature mechanism being an "event signing" mechanism (like 
is done in vista today on my TPM'ed machine, for all the TPA 
integrity  benefits due to "technical evidence" management). 
But, does THAT (a) REQUIRE (secure) storage of the SSL 
stream and the handshakes and (b) hashes of the handshake 
messages in the signature block?

---

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

There is nothing in this draft that conflicts with EU data sharing
and retention policies.  If those policies require that data be
destroyed immediately after use, then implementations of the draft
can be designed to do so.

-----Original Message-----
>  I'm in favour of strong crypto, strong privacy and strong protection

As am I.  I'm also in favor of strong architectural design, since
strong crypto provides no protection from weak implementation.  When
your personal information is stored by a merchant (with your consent),
you'd want the strongest possible measures (as described in my
previous message) taken to prevent it from being stolen by
technically sophisticated attackers, right?

---

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

> But what happens when the application session spans multiple session ids?

You loose (or the application looses).

The secretive security guys are as narrow-minded about
complex application design as some of us are narrow-minded
about the need for multi-level security.

Someone who thinks at EAL6+ security levels is not used
to multi-millions LinesOfCode applications with annual
code growth rates around 10% that have a requirement
to perform a single "transaction" accross several entirely
independent communication channels using independent protocol
abstractions crossing different middleware application components,
and being protected and (re-)authenticated by different
authentication technologies.

People like me try to provide some assurance that
all those seperate communication streams ending
up in the the same Application backend server are
protected and securely authenticated and in fact
belong to the same application session on the frontend
so that they can all have access to the same shared
session state in the backend.

Personally, I don't like such complex application design,
but it's not that anyone in the apps area would listen to me
and cut back on their ambitions.

But looking at the other TLS extension in TLS v1.2, it
seems the amount of different authentication technologies
is going straight up rather than settling down on a single
common scheme.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Jan 2007 18:33:08 +0000

Martin,

Could you elaborate in what ways this would be incompatible with the EU data protection directive?
I went over this with one of the leading Lawyers in Sweden on electronic signature implementations within the EU directives and we could not identify any significant problems.

He could see no problem with recording data during a session and save it as an audit record. Signed or not.
If there would be an issue (due to collection of personal data from the certificate etc), it could be solved by an agreement between the customer and the merchant or alternatively between the certificate holder and the CA.

Stefan Santesson
Senior Program Manager

---

From: <[email-masked]>
Date: Thu, 11 Jan 2007 11:33:01 -0800

I've lost track of the URL, but somewhere on an 
MSN/Microsoft site it once had a click-signature mechanism. 
"Click the Agree button" to be legally bound to something, 
over the SSL channel. That is not particularly remarkable, 
of course. However, there was specific and remarkable legal 
blurb justifying this as an "electronic signature". I recall 
reading it, wide-eyed.

One can gauge the trustworthiness of that "https signature" 
based on classical evaluation analysis (a) was the https 
implementation/ciphersuite/CA good enough (b) was the HTML 
rendered in Microsoft's IE product c) Is the browser and OS 
assured to ensure nothing else on the PC could interfere 
with the rendering of the server's-page ...and its dynamic 
button and event generation/communication. Absent an NCSC 
evaluation report thereto, the only party that can argue one 
way or the other is of course the vendor - which just 
happened to be Microsoft of course.

So, I think this was an edge case, that only an MSN site can 
make this claim for a click signature, because it has 
complete control over the trusted technology being applied 
(being an arm of Microsoft, the product maker of IE, https, 
MSN Servers, etc). However, to be an electronic signature, 
there has to be a recordation act. Presumably, the MSN audit 
logs have the details of the ciphersuite used, the browser 
headers, and perhaps even the SSL session pdus for replay.

----- Original Message -----
From: "Omirjan Batyrbaev" <[email-masked]>
To: <[email-masked]>; "Stefan Santesson" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 10, 2007 12:54 PM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

At
> non-repudiation. So as Stefan pointed out the b2b simply 
> uses http today.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 11 Jan 2007 15:10:31 -0500

On Thu, 11 Jan 2007 11:33:01 -0800
<[email-masked]> wrote:

> I've lost track of the URL, but somewhere on an MSN/Microsoft site it
> once had a click-signature mechanism. "Click the Agree button" to be
> legally bound to something, over the SSL channel. That is not
> particularly remarkable, of course. However, there was specific and
> remarkable legal blurb justifying this as an "electronic signature".
> I recall reading it, wide-eyed.
> 
> One can gauge the trustworthiness of that "https signature" based on
> classical evaluation analysis (a) was the https
> implementation/ciphersuite/CA good enough (b) was the HTML rendered
> in Microsoft's IE product c) Is the browser and OS assured to ensure
> nothing else on the PC could interfere with the rendering of the
> server's-page ...and its dynamic button and event
> generation/communication. Absent an NCSC evaluation report thereto,
> the only party that can argue one way or the other is of course the
> vendor - which just happened to be Microsoft of course.
> 
> So, I think this was an edge case, that only an MSN site can make
> this claim for a click signature, because it has complete control
> over the trusted technology being applied (being an arm of Microsoft,
> the product maker of IE, https, MSN Servers, etc). However, to be an
> electronic signature, there has to be a recordation act. Presumably,
> the MSN audit logs have the details of the ciphersuite used, the
> browser headers, and perhaps even the SSL session pdus for replay.
> 

You've swallowed the "digital" signature Kool-Aid.

What you saw was quite in conformance with the (U.S.) Electronic
Signatures Act of 2000.  See, for example:

	http://www.ftc.gov/os/2001/06/esign7.htm
	http://www.techlawjournal.com/internet/20000703.htm

Briefly, the legal notion of a signature has little relationship to
what computer people call a digital signature.  The (U.S.) courts have
held that computer-printed signatures on pieces of paper are legally
binding.

Sure, such paper -- or such mouse clicks -- can be forged, and there
isn't the technical attribute of non-repudiation.  If it comes to a
court fight, you can make that argument.  You can also make the
argument that a digital signature was forged because your key was
stolen or your machine was hacked.

In any event, your analysis and conclusions are wrong.

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Jan 2007 21:43:02 +0100 (MET)

> the EU data protection directive?

I already gave two examples.  I need to point out that the EU directive
is a framework with some wiggle room for national governments in making
laws that are being used in court.  I'm familiar only with the German
incarnation of the data protection directive.

I actually used the wrong URL last time (the telecommunications subset)
the data protection act appears to be this one:

http://europa.eu.int/ISPO/legal/en/dataprot/directiv/directiv.html

>
> I went over this with one of the leading Lawyers in Sweden on
> electronic signature implementations within the EU directives
> and we could not identify any significant problems.

I'll try to give you some guidance, but IANAL.  I draw my conclusions
from (German) court decisions, mainly those that were decided by
appeals or supreme court.

See definitions for "personal data" (Art 2a), "processing" (Art 2b), etc.

The problems arise from the fact that by signing the raw communication
data, the business is almost always going to "capture" information
that is unnecessary for the intended (business) purpose (see Art 6 a,b,c)
and quite possibly information which the business doesn't know ahead of time,
however a business is required to obtain a **VOLUNTARY** explicit and
individual consent agreement listing the exact information that is to be
processed, exact purpose of processing

While some specific data might be vital for a business purpose or
transaction, a blanket capture at the network level is very likely
to result in capturing of unnecessary data.  Removing the unnecessary
data after the capture might likely be difficult, because it will
invalidate the digital signatures on the rest (and once they're
invalid, it turns out it was a real waste to create them in the first
place).

The data protection directive requires the business to take efforts
to not collect unecessary data (Art. 2 a,b,c) in the first place,
and to delete every piece of information when it is no longer
necessary.  A broken protocol design that makes vital information
inseperable from unnecessary or no longer necessary information
(because of a digital signature that would be no longer verifiable)
is no valid excuse for not deleting it.

E.g. there is no necessity to persist a User-Agent: or HTTP-Refer:
from a HTTP GET request, so if that information is not deleted
when the online session ends, it is a violation of the data
protection directive.

As I mentioned before, the German supreme court made a final decision
about 2 months ago that it is(was) illegal to keep a record of the
equivalent of a DHCP-Lease for an internet DSL-flatrate customer
(IP+customer+start-time+end-time) after the customer hangs up.
(and the only reason why (only) phone companies will be able to keep
 this record in the future is a recently enacted legislation,
 but that is about very specific information and network/phone
 operators and providers only).

I expect there will be a lot of gobbledigoo in an TLS Evidence
capture which MUST be deleted when the session ends.  

Even if the business is able to obtain the purely volutary,
and formally correct consent agreement from his customer
for keeping all gorily detailed unnecessary information,
not providing a capability to delete the unnecessary data
upon request would amount to a violation of the data
protection act. 

Want to put a TLS Evidence persising business out of business?
Sign up, purchase, check your http-watch what crap they captured
which they aren't entitled to.  It wouldn't be suprising if
they actually failed to obtain a valid consent agreement.
But even if they do ...  wait 2 weeks, request a detailed
status report of what data they (admit to) store (Art 12),
revoke consent for all unnecessary data, go to court and
they'll likely have to massively purge "TLS evidence"
and/or junk their software or go out of business.

Btw. if a business fails to list a piece of information that it
intends to process or an intended purpose in the consent agreement,
then the content agreement will be invalid in its entirety!

> 
> He could see no problem with recording data during a session and
> save it as an audit record. Signed or not.
>
> If there would be an issue (due to collection of personal data
> from the certificate etc), it could be solved by an agreement
> between the customer and the merchant or alternatively between
> the certificate holder and the CA.

No, that will be generally insufficient.

Other than what is common abusive practice in the US, the courts
here in Germany are _dead_serious_ about (a) businesses avoiding
to collect unecessary data, (b) consent agreements being accurate
about the exact information and purpose, (c) every piece of
information being deleted when it is no longer necessary
(and not when it seems fit) and (d) the consent agreement being
purely voluntary (no pressure of any kind) and revokable at any time.

Consumer protection associations will be able to get cease-and-desist
orders against companies persisting TLS Evidence that includes unnecessary
data or data for which no valid consent agreement is obtained or where
they do not or can not delete unnecessary data.

-Martin

---

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

>> MSN/Microsoft site it

> In any event, your analysis and conclusions are wrong.

I thought I was commenting on the fact that (a) it claimed 
the click to be an electronic signature (versus a clickthru 
_agreement_) (b) it's a click over SSL (c) whats intesting 
is that the recordation requirement of ESIGN can only be 
being satisfied using an SSL audit trail (which is germane 
to the TLS Evidence work item proposal analysis)

Im perfectly well aware that a digital signature is but one 
kind of electronic signature under ESIGN laws. I was wide 
eyed about the claim that it satisfied the legal definition 
of electronic signature (in the public law). Normally, folks 
allude to other legal bases, common practice about agreement 
formulation ,etc. This was SPECIFIC to be claiming to 
satisfy the rules under ESIGN. You don't see this, very 
often.

---

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

[email-masked] wrote:
> shut up and rubber stamp.

10 Years ago the IETF was quite resistant to rubber stamping requests
(SSLv3, S/Mime), but I have the impression that the folks with the
hidden agendas have since significantly improved on their tactics
and achieved to blend in with traditional IETF in serveral areas.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Jan 2007 22:54:05 +0000

Martin,

Thank you for your elaborate answer and references.
It would not surprise me though if Germany in this area is more radical than other EU countries, but that does not make your argument invalid.

Stefan Santesson
Senior Program Manager

> Sent: den 11 januari 2007 12:43
> To: Stefan Santesson
> Cc: [email-masked]

---

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

Stefan:

http://europa.eu/rapid/pressReleasesAction.do?reference=IP/03/151&format=HTML&aged=0&language=EN&guiLanguage=en

----- Original Message -----
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 11, 2007 2:54 PM
Subject: RE: [TLS] Please discuss: 

Martin,

Thank you for your elaborate answer and references.
It would not surprise me though if Germany in this area is 
more radical than other EU countries, but that does not make 
your argument invalid.

Stefan Santesson
Senior Program Manager

---

From: Mike <[email-masked]>
Date: Thu, 11 Jan 2007 16:32:00 -0800

I've been trying to follow this discussion, since I may
have to implement this feature someday, yet I don't have
a clue what it would be used for.  Can someone please
lay out a scenario where "evidence" collection at the
TLS layer is the appropriate solution to a real problem?

Thanks,

Mike

---

From: "Mark Brown" <[email-masked]>
Date: Fri, 12 Jan 2007 12:37:34 -0600

Martin, Eric,

Below is an illustration of how to use TLS Evidence for a brokerage
transaction.  I hope with this illustration I can address both of your
concerns about what data needs to be signed and retained, and using what
amount of automation.  In this example I am not using the start1, start2,
etc. alerts, since I suggested this earlier as a possible simplification of
the current draft. 

> app, plus the race condition/lockstep issues I raised in my

So, Eric is concerned about situations where the creation of the signature
"isn't just automatic, it requires esxtensively modifying the app..." and
Martin is concerned about the situations where embedded within an
(automatically-created?) signature there exists "personal data" that is
captured without consent or is not necessary to the business purpose of the
transaction (and needs to be expunged later).  Can an application-data-blind
protocol extension like TLS Evidence address both concerns?  (Here I want
"blind" to mean that TLS Evidence doesn't peek into the application_data.)

Let me retrace Eric's line of thought first, using his broker illustration:

1) 100's of fetches to accomplish a trade:  In HTTP the TCP/IP session gets
torn down after every fetch.  So what is going on in Eric's scenario are
"hundreds" of TLS resumes, after an initial full TLS handshake.  

2) I'm proposing to do a full handshake using the TLS Evidence extension
only for the last POST, not the 100's of fetches prior to the POST.  That
is, not doing a TLS resume for the last POST but discarding the existing TLS
session and forming a new one.  Note that the HTTP app data is what actually
creates the user's sense of a session that persists over the hundreds of
fetches (and a few other POSTs).  That app data doesn't care if you resume
every time, do a full handshake every time, or any combination.

3) So I propose a minimum of two full-handshake TLS sessions, one that uses
TLS Evidence and one that doesn't.  In the brokerage scenarion, the TLS
session that does not employ TLS Evidence will be used for much more data
than the TLS Evidence session.  TLS Evidence will only be captured for a
typical brokerage transaction containing the client's POSTDATA and the
server's HTTP Response. (This HTTP Response will only contain
browser-readable HTML and cookies and not contain GIFs, JPEGs, CSS,
Javascript, ActiveX, etc., although it could contain references to any of
these.  All such references will need to be fetched by the client's user
agent, likely using TLS resumes on a TLS session that was used for the 100s
or previous fetches.)  

I believe this is normal user agent operation today, provided the normal TLS
session connects to a different domain name than the TLS Evidence session.
So in this illustration, I'll use a different DN for the "evidence" TLS
server than for the "secure" TLS server.  Using a different DN for a TLS
Evidence TLS instance than the DN used by the "normal" TLS instance is not
the only way to accomplish the required distinction between plain TLS and
TLS Evidence sessions, but I think it is the most backwards compatible
approach.  

Here's a proposed illustration for a simple use of TLS Evidence, for the
case of "Your typical brokerage transaction". 

A) Client may start at http://www.broker.com, without TLS.
B) Client logs into https://secure.broker.com, using some URL path (PKC 1 is
for secure.broker.com) and fires up a normal TLS session to host
"secure.broker.com".  In this illustration, authentication at this host is
done using user name and password at the application level, not at TLS
level.
C) Client interacts -- 100s of fetches, etc. -- using the normal TLS session
D) Web App designer has already changed the URL on the FORM SUBMIT action of
the one important POST so that it targets https://evidence.broker.com
instead of the "secure" server.  This obviously forces a full handshake
regardless of the TLS Evidence extension -- the old TLS session won't work
here because of the DN change.  Server must use PKC 2 for
evidence.broker.com.
E) client MUST have already been configured at TLS level in this way:
(Target) evidence.broker.com:443 = (PKC) clientEvidence3

This TLS client configuration line identifies one DNS name and port number
for which the client will always ClientHello using TLS Evidence.  Further,
for sessions with this DNS host the specified client PKC will be used for
signing the TLS Evidence.

To one of Martin's concerns, the TLS client is free to add or remove
Target=PKC TLS Evidence configuration lines at any time, or simply let his
PKC expire, or review servers for which he has configured Evidence, etc.
Client configuration could also record (in a third column) a URL at which
the client could request destruction of TLS Evidence.  Stronger
implementations could use a full URL/URI as the (Target).  I propose only DN
here because the current client API suggested by the OpenSSL s_client
command line interface is just a hostname, or hostname plus port.  This
configuration is on par with the configuration of trusted CA's, the
specification of the client's private key file and password, etc. in the
OpenSSL s_client.  So at this level of the existing API, the configurations
given to s_client are "trusted".  So the level of consent in the proposed
configuration is equivalent to the level of consent for which CA's to trust.

F) After connection, a TLS session using TLS Evidence exists.  Over the
course of time, between this client and the server with domain name
evidence.broker.com, you might see:

ClientHello1 (full handshake, TLS Evidence)
C: <a1.1> + Rq1.1 |                        | Rs1.2 
S:                | Rs1.1 + <a1.2> + Rq1.2 |

WHERE:
C = client
S = server
	The following are numbered by ClientHello then app_data sequence:
<a#.#> = application data
Rq#.#  = EvidenceRequest 
Rs#.#  = EvidenceResponse

So, this evidence session created Rs1.1 and Rs1.2 as evidence, and Rs1.2 has
the hash of <a1.1> in the app_data_received_hash (because TLS server
initiated this EvidenceRequest) and the hash of <a1.2> in the
app_data_sent_hash, and the hash of "ClientHello1 (full handshake, TLS
Evidence)" with evidence.broker.com in the handshake_protocol_hash.  Rs1.1
is pretty much obsolete now that Rs1.2 exists.

What if the app designers couldn't identify just one HTTP POST to capture
TLS Evidence for?  What if 100s more fetches were performed and the user
initiated a second brokerage transaction?  Then the following uses of the
evidence session might occur:

ClientHello2 (resume, TLS Evidence)
C: <a2.1> + Rq2.1 |                        | Rs2.2
S:                | Rs2.1 + <a2.2> + Rq2.2 |

ClientHello3 (resume, TLS Evidence)
C: <a3.1> + Rq3.1 |                        | Rs3.2
S:                | Rs3.1 + <a3.2> + Rq3.2 |

To one of Eric's concerns, in this illustration there really is no change
required for either the TLS client or the TLS server APIs (i.e. how the
application interacts programmatically with the TLS layer).  In this
illustration the client is configured via command line as described above.
Server may implement TLS Evidence using a command-line, config-file or
compiled-in option.  Whenever client interacts with
https://evidence.broker.com, TLS Evidence will be requested and created, and
if there's any problem the TLS session will get torn down, browser will say
page unavailable, and the back button will be used.  Resumes will still work
on the "normal" TLS session, which will be used independently of the
"evidence" session.

>From the perspective of the application deployment at the web server, they
may choose to host two web sites on the same machine (or not).  They may
develop the "evidence" page, i.e. the web application that accepts the
POSTDATA, using "normal" TLS.  They may choose to copy that web application
(CGI, JSP, ASP, servlet, etc.) from the "normal" TLS site to the "evidence"
TLS site.  They may even choose to allow users to select whether the user
would prefer to send their POSTDATA to the "evidence" or the "normal" site.
This would probably be a good idea in case any of their clients will ever
have difficulty with their PKCs.

To one of Martin's concerns, what data is actually preserved in this
example?  The TLS handshake, the POSTDATA sent by the TLS client, and the
HTTP Response "web page" (before any referenced documents like images, CSS,
scripts, etc. are fetched).  These three cases may only run afoul of laws
governing the retention of personal data in the data preserved in the
following streams:

1) the POSTDATA (i.e. form fields "filled in" by the user within the user
agent using the TLS session) may contain extraneous data fields that are
really not 
2) the HTTP Response data (i.e. the "web page" returned by the server)
3) The TLS Handshake data for this particular TLS Evidence Session

In the first case, the POSTDATA is fully determined by the server side,
which created the HTTP page and HTTP form which is being posted.  Of course,
the only data being posted are HTML HIDDEN fields, any relevant cookies (by
domain name, etc.), the fields within the HTML FORM tag which have been
further tagged as FORM fields and further, have been filled in by the user.
In this illustration, the broker created the blank FORM which the user fills
in.  This is simply a more widely used method of identifying the fields to
be used for evidence than the new tags Martin mentioned earlier as a
preferred solution:

Martin Rex said:
> 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.

>From the customer's standpoint, the HTML FORM approach is nearly WYSIWYG,
except for the cookies and hidden fields.  From a legal standpoint, the form
designer at the brokerage will need to ensure that none of these fields
violate applicable laws when persisted.  

In the second case all of the HTML and cookies returned to the user are 100%
under the brokerage's control, as in the first case.  If the brokerage is in
the habit of returning transaction receipts to their users that are illegal
for some entities to persist then it makes more sense to change the HTML &
cookies returned than to continue to risk breaking the law.  This is a
matter of correctly implementing the business requirements into the
application, and really isn't the concern of the TLS layer.  It is,
arguably, fairly easy for the broker to change the dubiously-legal HTML
application, and it is clearly the broker's responsibility.

In the third case, a normal SSL/TLS handshake already has the capability to
authenticate a PKC, and it already performs HMAC over the application data.
I would be surprised if any nation has passed or will pass laws that made
TLS records illegal to store / audit.  However, even where such laws are in
force, TLS Evidence can still be used simply by truncating any of the
application data records and/or TLS handshake records as described below.

Finally, all three of these audit streams -- app data sent, app data
received and TLS handshake -- are severable.  If the app data sent by the
client needed to be destroyed upon request by the user, then it could be
destroyed without ruining the digital signature set.  Same for the other
streams.  In fact, if an entity only persisted the TLS Evidence
EvidenceResponse structure and none of the streams, it would still hold a
fairly strong method of falsifying any fraudulent claims.  For if a
frivolous opponent chose to claim that a specific set of app data sent, app
data received and TLS handshake took place, the brokerage could simply
challenge that assertion and say, "Prove it: we've retained evidence over
every transaction we've authorized; let's see if your claim matches any
transmissions we've processed for your PKC."  This approach may even reduce
the overall burden of data retention on the brokerage, since the
EvidenceResponse structures are relatively small.

In summary, TLS Evidence can be used to falsify frivolous / fraudulent
claims without storing any application data or handshake streams.  TLS
Evidence can be "turned on" and "turned off" by using a DNS domain name, and
this approach follows not only the traditional SSL/TLS API but also the
Berkeley sockets API, so it is legacy compatible.  TLS Evidence, used as
described, requires the TLS Client to maintain a trusted configuration store
that matches client certificates to the domain names at which those
certificates should be used, and this whitelist follows the same conventions
as the existing trusted CA configuration process.  Martin points out a good
legal motivation for only generating TLS Evidence when you REALLY need it,
and storage considerations also encourage this approach; I strongly agree
that TLS Evidence should be "turned on" only when a core-to-the-business
transaction needs to be recorded.  I expect these three motivations -- which
I summarize as relevant legal constraints, business needs and security goals
-- will work together to help TLS Evidence users make the right decisions.

--mark

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Jan 2007 10:53:42 -0800

"Mark Brown" <[email-masked]> writes:
> torn down after every fetch.

Uh, not in any modern HTTP stack, no. I refer you to RFC 2616 S 8.1.

> for which the client will always ClientHello using TLS Evidence.

It does what??? I need to hard-configure some list of names and ports?
That scales how?

> application interacts programmatically with the TLS layer).

No. The server *still* needs to check that he's actually getting
evidence. I.e., that the client is coming in through the right
virtual server (unless you're proposing that I rearchitect
all my server apps to split every kind of transaction into
two different servers), and there's still the relative inefficiency
of your signature mechanism, which is conservatively a factor of 2-4
slower than app-level signatures.

So, you've had to modify both client and server, you quite
possibly had to substantially rearchitect the server, and the
client has to have some semi-manual configuration settings to
determine when it offers evidence. None of this seems
particularly convenient. 

To uplevel a moment, I'm not arguing that you can't make some proposal
along the lines you indicate sort of work. What I am arguing is that
it isn't substantially simpler than the application-level signature
alternatives, that it offers inferior semantics, and that it doesn't
fit well with the TLS architecture. None of this discussion has
changed my views on that point.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 12 Jan 2007 19:24:27 +0000

I think we can clearly separate the issue of information sharing from an ID authentication technology from this draft dealing with capturing and signing information shared between two parties.

The relevant issue your raise is if the capturing of data from lower communication layers and storing them as part of a signed audit record can be problematic from a user integrity perspective. I think you have made strong arguments that it can.

I'm still trying to figure out exactly how big of a problem this is but this might very well be the reason why this proposal is a bad idea.

Stefan Santesson
Senior Program Manager

> Sent: den 11 januari 2007 16:10

---

From: "Mark Brown" <[email-masked]>
Date: Fri, 12 Jan 2007 13:56:50 -0600

Eric,

> Uh, not in any modern HTTP stack, no. I refer you to RFC 2616 S 8.1.

You're right.  

> It does what??? I need to hard-configure some list of names and ports?

You're right again.  I could drop the port number; then it scales about as
well as using client certs.  I think the "scales well?" comparison here
should be made against client cert use cases.  

> virtual server 

This seems like a misunderstanding.  I'm proposing two web servers over two
TLS instances using two PKCs in this illustration.  On the web server using
the "evidence" TLS instance you don't need to check for EvidenceResponse any
more than the web server on a normal TLS instance double checks that
encryption was performed.  TLS Evidence is on or it's not.

Is your concern the semantics?  In the brokerage scenario, the second
EvidenceResponse either is or it isn't.  What does the brokerage care if the
TLS client never countersigns the issued receipt?  The TLS layer's TLS
Evidence implementation will ensure that no further application data is
allowed back up to the app server in this case.  If the TLS client drops off
and hangs up, there's no problem.  If the TLS client skips its
countersignature and yet still wants to turn around and send more app data
then the TLS Evidence implementation will block this.

> there's still the relative inefficiency

Yes, you're right.  Twice-signed is slower than single-signed, especially
when you figure in network latency as proposed.  Using order-of-magnitude
computations, twice-signed is probably about as costly as a TLS handshake.
Both estimates really hinge on network latency which is a bit of a wildcard.

> determine when it offers evidence. None of this seems

I expect that most TLS Extensions will require some modification to the TLS
instance, modifying both client and server.  My goal is to eliminate impact
on the TLS-app API except for opt-ins to TLS Evidence, and then, to minimize
impact.  I've made progress, thanks to input on this list.  I think we're
currently at "no impact" unless opt-in occurs.  Where opt-in occurs, I
believe that the server impact occurs only at TLS server installation /
configure time.  Client has to configure per-cert as its opt-in action,
assuming a TLS Evidence instance already exists.  I think that overall this
is shaping up to be pretty close to current TLS practice, but I'm interested
in your opinion.

> changed my views on that point.

I think that if we can work out the sorts of concerns you raise here, we
will save applications from having to make these exact mistakes (and worse)
over and over again.  Your suggestions and others are valuable and based on
a lot of experience that most of the rest of us don't have.  Let's move this
entire discussion forward for everyone by making the compromises that stick
and documenting them in a spec.

--mark

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Jan 2007 21:25:57 +0100 (MET)

Mark,

Mark Brown wrote:
> transaction.

I appreciate your efforts, but I'm running out of time with this
debate.  I'm behind on my development schedule and need to go back
do the work I'm being paid for.

There will always be means to use a inappropriate technology
for an inadequate solution, I can see it every day when deployed technology
is frobbed^Wretrofitted for a purpose for which it wasn't designed.
However, it is a pretty bad idea to start off with a technology
that fits common scenarios in home/office/businesses so poorly
as TLS Evidence and has such a huge abusive potential.

I know that there is a huge economic motivation for government agencies
to be able to purchase equiment on the free market that suits their
needs rather than having to develop it on their own.  This is one of
the reasons how/why TPM sneaked into modern business computers for
the mass market.

There is some truth in what Peter says, the proposal is so well designed,
and many of the things people recognize as problems are there on a
purpose and integral part of the proposal, so the most severe problems
are beyond repair.  IMHO, if TLS Evidence is rubberstamped, it means that
the IETF has been subverted sucessfully.

If this technology enters the maintstream, then the agencies will
start harvesting the results.  They've been pretty firm in how
much they like and intend to expand surveillance, and they are
regularly breaking the laws in order to collect information
to which they're not entitled.

The most effective security measure is not protecting data with
strong crypto and high assurance, it is not creating -- or where
it needs to be created and processed -- not persisting it.

As far as risk management is concerned, TLS Evidence is probably
the largest can of worms I've ever seen.  Since I've started thinking
about this technology, I discover at least one major new problem every day
(acutally every night when I try to get asleep), and I have the feeling
that I've only seen the tip of the iceberg so far.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Jan 2007 12:38:36 -0800

"Mark Brown" <[email-masked]> writes:
> well as using client certs.

Preconfiguring all the servers you're willing to sign with scales
as well as installing a single client cert?

> encryption was performed.  TLS Evidence is on or it's not.

But they're not two TLS servers now, they're one. So, you're proposing
a massive rearchitecture of people's servers--and think about this
scales next time you want to add such a feature! Easier to just add
message signing, which doesn't require any such rearchitecture.

> computations, twice-signed is probably about as costly as a TLS handshake.

You're assuming that each transaction is only covered by one set
of signatures. But there's no such requirement in TLS. You can
send every byte as a separate SSL record--and it's quite common
for an HTTPS response to span multiple records. 

> is shaping up to be pretty close to current TLS practice, but I'm interested

I don't agree with this assessment, for reasons I think I've indicated
as nauseum.

> over and over again. 

But to a first order, these mistakes are a result of your attempt 
to put signatures at a layer with inappropriate semantics. There
are a lot fewer mistakes to be made if the signatures are done at
the right layer. And I'm not at all convinced that any amount of
hacking on this general architecture will produce an acceptable
result.

> Your suggestions and others are valuable and based on

You're assuming the exact point I'm contesting, which is that this
should be done at all.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Sat, 13 Jan 2007 00:42:51 +0100 (MET)

> Below is an illustration of how to use TLS Evidence for a brokerage

Since you keep refering to brokerage transactions, audit trail, Microsoft
is participating the discussion, and TLS Evidence is being designed
to be able to work "transparently" (=concealed), I'm wondering
whether this is primarily targetted for the financial sector
and stock exchanges.  That's already a fairly regulated area,
and an area where massive legal and illegal wire-tapping is
ongoing (e.g. SWIFT).

The agencies might be looking for a means to capture the evidence
even for a larger amount of deployed software, so a transparent
(or actually concealed) plug-in to the TLS stack might be
attractive to them.  Performance is likely an issue there as well,
so the approach of hosting the transaction "forms" (actually the
reveiving URLs for the HTTP Post on a dedicated Web-Server might
be the easiest way to cut down the audit trail considerably,
improve the performance and reduce the necessary changes in
the backend significantly...

It appears that for the audit trail on the backend a windows box
with a tls-terminating loadbalancer or reverse-proxy is envisioned,
and the frontends are probably all windows PCs these days.

-Martin