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

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 12:48:32 -0800

SPEAKING AS CHAIR:
Mark Brown and Russ Housley have requested that the TLS WG
adopt draft-housley-evidence-extns-01 as a WG item. This
work was presented at San Diego to a generally positive
response but it needs to be discussed on the list. Please
use this thread to start that discussion.

-Ekr

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 12:53:28 -0800

> use this thread to start that discussion.

SPEAKING AS MYSELF
I'm quite negative on this proposal. Review attached.

Note: the following review was based on the -00 version of the
document but a quick skim suggests that the -01 has the same
weaknesses.

BACKGROUND
TLS provides for public key authentication of both client and server
but this only provides for proof of the existence of the handshake
(and this only in limited circumstances). It doesn't provide for
any proof of the contents of the data messages. This draft
extends TLS to provide signatures over the data.

ARCHITECTURAL COMMENTS
I'm not particularly enamored of this general approach. The 
signatures in question are fundamentally an application-level
construct: they're requested by the applications and
ultimately consumed by them. The only real reason to do
this at the TLS layer is the sense that it's easier to deploy.
I'm not actually convinced that that's so, since this approach
still requires modifying the applications to request security
the signature/evidence services.

In addition, putting this functionality at the TLS layer embodies
some not-so-attractive tradeoffs, in particular, that the
binding of application-layer messages to the actual evidence
provided isn't particularly tight, since the signatures cover extents
of the traffic rather than messages. This introduces a number of
race conditions which are only partially solved by the
interlocking alerts used here. Among these are:

 - The sender of the start1 alert has only minimal 
   information/control over when the peer will start signing traffic.
 - It's quite likely that one side will have to process messages
   without knowing whether the peer will actually sign his 
   section of the traffic. This is obviously a problem if you
   are producing side effects. You can mitigate this problem
   only by doing two evidence collections in lockstep.
 - Applications need a bunch of new logic to detect the evidence
   request but hold their response to application-layer boundaries.
   This cannot be implemented at the TLS layer.
 - If you want to condition your application-layer responses 
   to whether the peer provided a signature you need some way
   to provide application-layer "please resend with signature".
   This is a common case but can only be dealt with very
   clumsily here.
   
This seems like a fairly large architectural change to TLS to
make it do something it was never designed to do and which
can be done better in the application.

DETAILED COMMENTS
S 1.
It looks like the evidence creation has to involve signatures by
both parties. Why not have it be one-way.

S 1.2.
   Generating evidence is not compatible with Diffie-Hellman Ephemeral
   (DHE) key exchanges.  DHE does not permit the same keying material to
   be generated for validation of the evidence after the TLS session is
   over.  Persistent evidence requires the use of a digital signature so
   that it can be validated well after the TLS session is over.

Why not just store the traffic keys?

Figure 1 would be better with some markers about the traffic
segments that are signed.

S 2.
I'm uncomfortable with the idea if "evidence suites" and later
of new certificates and certificate negotiation. This seems
like you're layering an entirely new protocol over TLS.

S 3.
This consumes 4 new alerts. The space isn't that big.
Since you're already defining a new protocol type, these
messages might as well be part of that protocol.

S A.
Defining cipher suites with key lengths attached to them
isn't hte TLS way.

-Ekr

---

From: Ari Medvinsky <[email-masked]>
Date: Tue, 19 Dec 2006 12:58:58 -0800

Eric,

It would be great if you could add a link to this draft from
http://www.ietf.org/html.charters/tls-charter.html (the draft section).
Thanks,
-Ari

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Tuesday, December 19, 2006 12:49 PM
To: [email-masked]
Subject: [TLS] Please discuss: draft-housley-evidence-extns-00

SPEAKING AS CHAIR:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2006 13:01:12 -0800

> http://www.ietf.org/html.charters/tls-charter.html (the draft section).

It's not yet a WG item. If it becomes one, I'll arrange for a link.

-Ekr

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 20 Dec 2006 00:00:47 -0600

Eric,

Thank you for your insight into technical weaknesses of the draft.  I tried
to address these inline, below.  More broadly though, Why introduce evidence
to TLS?  Why ask for a WG charter extension for evidence?  I need to give an
argument (below) to answer these Why questions.  Please bear with me.

First, applications defer to TLS for good reason.  The essay "Programming
Satan's Computer" (Anderson & Needham, 1995) makes it clear that devising
and implementing cryptographic protocols is difficult.  TLS is so simple to
use and ubiquitous that any user/anywhere can get a good secure socket when
connecting to a TLS server.  TLS hides from the user years of protocol
design, analysis and cryptanalysis, all of which is hard.  It is a brand
that users trust because TLS simply delivers good security for sockets while
following an "It better just drop in and work" layered model.  (SSL was a
good name.)  The "users" of TLS are not just people who use web browsers.
TLS users are also the numerous application-level programs and programmers
that depend on TLS to do the heavy lifting, implementing a cryptographic
protocol in a Known Good way.  

Constructing digital evidence so that it deters frivolous repudiation in a
legal setting is similarly difficult.  In legal settings users need evidence
-- not hearsay nor impossible "burdens of proof."  Moreover, what really
benefits users is evidence that any user/anywhere can read and interpret
(even lawyers).  Numerous past attempts have failed, and digital evidence is
still a hotly contested topic of debate among expert lawyers.  Sure, every
bit of data is evidence at the start of a legal contest, but when
challenged, data often becomes worthless to the case -- or gets thrown out.
While on the one hand lawyers are now crying for standard, open (did I
mention nonproprietary?) ways to create digital evidence, on the other hand
many relevant standards remain unread, unimplemented and unused (e.g. PKIX,
but many other standards specify digital signature methods too).  You said
well at USENIX 2003 much of what I'm repeating here.  

Why should we consider digital evidence a hard problem, a crypto protocol
problem, a TLS problem?  One crucial issue was raised by Steven Kent last
year: the problem of the recording the signer's intent.   Just to be clear,
"signer's intent" problems include not only the challenge of recording
something intangible, or the possibility that garbage data was signed, but
also claims that the system that created the digital signature was subverted
- or used with an intention to defraud.  I'm a newcomer to this party, but I
don't think any previous standard solves this problem (I don't count the NR
bit as solving the problem).  Let us know...

After pointing out this unsolved problem for constructors of digital
evidence, Kent then affirmed the convention of delegating this seemingly
intractable problem to the application layer.  "Signing things for
non-repudiation is usually an application-layer issue..."
(http://www3.ietf.org/proceedings/05nov/tls.html )  Which is a pretty
sensible approach, I think.  But to be perfectly honest, isn't "application
layer" here a code word for "let them figure it out, we're not going to
waste any more time on this problem"?

But now TLS Evidence can solve the "signer's intent" problems, and it
requires two parties, implying a network protocol connecting two parties.
Or, I should say more conservatively, if TLS Evidence solves the signer's
intent problems then I'd like to ask TLS WG to expand its charter to address
evidence.  Or better yet, would you all consider TLS Evidence to see if it
solves the "signer's intent" problems?  

The solution to signer's intent lies in two parties using TLS Evidence
together with TLS Authorizations (see -01, 4.2. EvidenceRequest Message,
field handshake_protocol_hash, pp 12-13).  If the handshake contains TLS
Authorizations that gain one party "access" then the record of that
handshake proves that the session was authorized-for something specific.
Whatever that something specific is, that's the stated intent for this
session.  Both parties agree to it -- one said "Authorize me to do this" and
the other said, "Ok, I agree."  If they don't agree, the session's over
before the handshake FINISHED pair.  Pick any example you want: authorized
to do online banking for my account; authorized to vote; authorized to read
email; authorized to post to a blog; etc.  There is more to say about
this...  But the main point is this: Authorization always seems to clarify
intent, that is, the intent of both parties.  I think it's baked into the
definition of authorization somehow.  (I'm happy to discuss this more.)

To sum up, I agree that evidence is not currently part of the WG charter,
it's new, and deserves questioning like this.  I have proposed in TLS
Evidence the solution to a hard problem and, as I see it, the solution
necessarily lives in a cryptographic protocol.  I think it fits well with
TLS successes as both easy to use and as hiding the challenges of
standardizing a cryptographic protocol well.  But it's no doubt a change in
the WG charter.  Now it's up to the WG to answer our request that the
charter be expanded.

On to your comments.  Pertaining to signer's intent, you raised this

> both parties. Why not have it be one-way.

My reasons for two signatures (countersignature) include:

1. Take as an example a military case where a Common Criteria EAL6 TLS
server and a non-evaluated TLS client exchange TLS Evidence.  If only the
client signs it, how much assurance do we have that the evidence is correct?
None under the Common Criteria.  But if the client asserts it and the EAL6
server countersigns it (using EvidenceResponse under TLS Evidence) now we
have "high assurance" for the evidence, which both client and server can
retain.  In this scenario, the low-assurance party obtains high-assurance
evidence just because it participated with a high-assurance server.  I call
this "assurance bootstrapping," and it can be a valuable service to the
client.  I think this argument still carries the same weight even if the
server is Known Good under some other current or future evaluation system
(open source, peer review, etc.).  

2. What if in the scenario above the transmission is the acceptance of a
relatively small contract that, in its fine print, grants a huge amount of
intellectual property rights to the military?  And later the contractor
wants to repudiate the signature, claiming that the transaction was a
forgery?  (This illustration is completely fictional.)  If only the
high-assurance server signed the evidence then the contractor can say that
someone else initiated that transaction, and the burden of proof rests on
the military.  But if the contractor chose his own key pair, and registered
his own PKC, and used that registered PKC to sign EvidenceRequest under TLS
Evidence it's harder to repudiate frivolously.  Especially if the
contractor's PKC uses crypto stronger than the military can crack.

3. At a high level, two different parties signing the same thing forges an
agreement -- both intrinsically and historically speaking.  TLS Evidence
proposes a standard for how to agree before evidence is born.  This
includes:  the handshake must have worked (and all that this implies).  The
evidence suite must have been used with mathematical precision, so the
encrypted and hashed outputs are correct.  The timestamp must be acceptable
to both parties.  And so on.  Successful TLS handshakes, especially when
coupled with other TLS extensions such as TLS Authorizations as I've
mentioned, can be used to forge really specific agreements using TLS
Evidence.  If we don't require two parties to sign, everything having to do
with agreement over evidence drops out of the picture.  This emphasis on
agreement is not foreign to TLS, and I hope others agree that the use of
agreement in the core TLS handshake(s) over the years has been a strong
security practice.  I think agreement between client and server is a strong
card to play for evidence as well.

> Why not just store the traffic keys?

No smoking gun stands out to me as I try to explain why
session-key-encrypted application data proves the identity of both parties.
Following your book I can see how to derive the session key if I have all
the right inputs, but working backwards from session key to identities seems
harder.  I take this to mean you'd need to hire a crypto expert (or TLS
expert) to explain it in court.  This is all well and good in today's legal
environment where that's the norm when you deal with data, but I'd like to
propose a standard that makes cryptographic protocols EASY for the user.
For evidence, "It better just drop in and work" in the courtroom, for that
user too.  For evidence, the user may be some small business that needs to
encourage a huge organization to honor a deal they "inked" using TLS.  If a
small business owner can do a simple cryptographic verify operation on TLS
Evidence structures using free tools and his own retained records, and if
what he sees using freeware on a commodity computer will stand up to fierce
scrutiny in court, then I think we've created evidence worthy of the TLS
brand.  In fact, that easy-to-use evidence may enable that small business
owner to prevail in an out-of-court settlement, which benefits everyone. 

With current and proposed TLS handshake extensions, the variety of
authentication and key derivation methods, and the indirect linkage between
a session key and the client & server identities, I guess it would be hard
to write a universal TLS evidence viewer that produced a smoking gun.
Especially if that viewer software must operate with high assurance, say for
example, if the evidence is for a vote in an election recount situation.
I'm not complaining, and I'm not opposed to others doing this.  I just think
that even if the traffic keys "work" at a crypto level they are complex
enough to not be useful to a wide range of evidence users (and specifically
lawyers and juries without hiring an expert).

> ultimately consumed by them. 

I think of evidence like old tax returns.  You are supposed to keep them for
some number of years, so you file them in the garage/basement.  The last
time you read any of them was when you last signed them, except in special
cases where having the old tax return proved really valuable.  In my view,
TLS layer checks the TLS Evidence as required by the Internet Draft, refuses
the bad evidence, and writes the good evidence to a box in the garage (using
some configuration flag at the TLS layer).

Let me clarify expected operation.  TLS Evidence requires participants to
store evidence, and it requires configuration -- selecting targets -- before
it starts creating evidence, but it does not require application
interaction.  The usage model I anticipate for TLS Evidence is default
do-nothing.  Until client (and server) both configure to client authenticate
and to demand evidence when accessing specific domains/URIs, then nothing
happens.  TLS Evidence isn't something one party can demand with no warning,
or from a stranger.  Once the TLS layer is configured to demand evidence in
some cases, now the app layer wants to see no traffic (for those cases)
unless the traffic passes the TLS Evidence tests.

It is an unwarranted prejudice to hold that digital signatures must be
application-level constructs.  (Just solve the signer's intent problem
though...)  I believe and fully expect that the application layer doesn't
want to have to check or otherwise process evidence - it wants TLS to do
that since it's a Difficult Crypto Problem.  If TLS can create evidence,
then apps will shed the responsibility.  It simply costs the app too much to
invent its own crypto implementations and then adequately test them.  TLS
has quietly bubbled up to preferred status on many occasions; I can think of
some Web Services standards that go into detail to explain how to do crypto
and then tack on, "and TLS does this too and that's a good approach."  

> The only real reason to do

I disagree.  The reason an app wants TLS to solve a Difficult Crypto Problem
is the raison d'etre of TLS.  TLS makes the crypto problems easy (for the
app), is a Known Good Way, and can handle the responsibilities of key
management & crypto.  More than anything TLS is tested and approved.  Apps
can't duplicate this without great cost.

>    This is a common case but can only be dealt with very

Some of these scenarios seem incongruous with mutual authentication and some
form of TLS Authorization (as recommended in TLS Evidence).  Please give
more information about the scenarios you are thinking of here.

> both parties. Why not have it be one-way.

See above.

> Why not just store the traffic keys?

See above.

> segments that are signed.

Ok.  

> like you're layering an entirely new protocol over TLS.

Using the same two certs for both authentication and signing is simple and
preferable in most cases.  Ditto for cipher suite & evidence suite.
However, sometimes you might prefer a null ciphersuite but want evidence
(transfer of an already-encrypted file).  In a military case, you may need
to call the function that checks EvidenceRequest via RPC, in which case
using different PKCs is nice to avoid private key sharing.  There are some
weird cases where this flexibility is nice to have.

> messages might as well be part of that protocol.

Let's flesh this out a bit more.  Whatever is best.  

> Defining cipher suites with key lengths attached to them

In this case, using poor crypto actually hurts your partner if you're the
one whose going to repudiate with evil intent.  That's reversed from the
normal TLS model, and why TLS Evidence is stringent where TLS historically
has been able to be loose.  Parties need to protect themselves by demanding
what they consider to be strong asymmetric crypto.

> -Ekr

Best regards,

--mark

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 20 Dec 2006 15:00:32 +0000

I remain divided on this work.

On one hand I recognize that implementing signing of exchanged content is a very hard issue for many providers of internet services. Taking internet banks or public governmental services as an example, it is virtually impossible to find an on the shelf generic solution that is compatible with all platforms the user may have. Providing signing capacity on the TLS level may therefore be a very interesting alternative to create signed records of transactions.

In the end this is a matter of what is most effective. The problems rightfully belongs on the application level and only the applications can determine intent and put signing in such a context that it becomes "evidence". On the other hand, all attempts to solve this in any generic way on the application level involves code that is not easily standardized.

I have one strong opinion. Abandon the term "evidence" in this draft and it would be much better. This draft is about adding signing capacity to TLS for selective data. I would strongly suggest moving to a terminology that reflects the technical feature provided rather than the eventual legal consequence.

Then we can avoid the legal discussion of NR that has already started, which I don't think belong here. Whether this turns out to be used as evidence is completely up to the applications using this technology and should be totally out of scope for this document.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Mark Brown [mailto:[email-masked]]
> Sent: den 20 december 2006 07:01
> To: 'EKR'; [email-masked]
> Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00
>
> Eric,
>

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Dec 2006 19:46:39 +0100 (MET)

> non-repudiation is usually an application-layer issue..."

Correct.

Choose between CMS & S/MIME, signed XML and maybe GSSAPI-IDUP
if you're looking for standards how to put digital signatures
on actual content, rather than TLS, who has a option to use
a digital signature as a proof for possession of a private
key as a method for online authentication.

> requires two parties, implying a network protocol connecting two parties.

TLS Evidence can NOT solve the signer's intent problems, it is in the
worst possible position to do so, right above the bits-on-the-wire.

Most protocol stacks have several protocol layers in between, carrying
data that is produced by software rather rather than users and users
never get to know what amounts of protocol framing and auxiliary data
the different layers of the software stack are going to put in there.
They don't even know whether, when they are shown a popup window
with "OK" and "Cancel", what will be sent over the communication
channel -- is it "OK", or "0" or "0xff3456ab" or "button 0x200".
The signer's intent is extremely sensitive to the context,
and TLS has nothing to do whatsoever with the UIs -- which are
going to have a significant impact on the users intent.
And user shouldn't have to know or care about that.

If users are expected to digitally sign actual meaningful content
rather than producing evidence for possession/knowledge of a (private) key,
then they better know every single bit that gets signed.

IMHO TLS MUST NOT have access to keying material that vouches for
anything else than "private key present".  The purpose of TLS is online
authentication, and the users private key is used to process
arbitrary data as seen fit by the underlying authentication protocol.

I'm firmly opposed to the TLS Evidence proposal.

> forgery?

If you need a contract sign, just do it.  There have been perfectly
working schemes to do contracts for centuries.  Many do not require
computers or the internet, and everyone knows how to handle them.
You certainly do not need TLS contortions in order to do contracts.

Think about what you propose: you're seriously suggesting that
click-through-licenses are a good idea.  I'm violently opposed to
this.  Fortunately German jurisdiction has been considering
click-through licenses nul and void, and I certainly do not
want that to change.

Think about the much more dangerous use of this.  Currently there
are public forums operated by big companies (Microsoft,Google,etc.)
and at least some of them have "terms of use" (subject to change
without prior notice) which is supposed to transfer your IP to
them for everything that you write/post/upload.   

Click-through licenses are evil, and I don't want to see an
IETF working group pushing click-through licensing scheme.

>
> If only the high-assurance server signed the evidence then the
> contractor can say that someone else initiated that transaction,
> and the burden of proof rests on the military.

As I mentioned, we don't have to reinvent the wheel -- the world
has been successfully doing contracts before the internet, and
with concepts every adult is accustomed to.

I don't know how you think applications are being built today,
but the application area that I know keeps adding protocol
layers between the wire-level and the presentation layer
(what the user really gets to see) like crazy.
TLS is just above the network layer, hidden under several
abstractions and resource-managed by the middleware.

When the middleware feels like it (or when there's some
network hickup) the network connection may be dropped and
the TLS connection interrupted.  Depending on the
protocol layers in the middleware and the requirements
of the application, the communication channel will
be automatically reconnected and the TLS secure channel
automatically re-established, transparent and unnoticed
by the "application" in many scenarios.

-Martin

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 20 Dec 2006 16:30:26 -0600

Martin,

I see some misunderstandings:

1) Application data is fully opaque to TLS Evidence.  This is a fundamental
principle we both agree on.

a) Application data is so opaque to TLS Evidence that it could just as well
be encrypted when hashed by TLS Evidence, and the resulting digital
signatures would serve users as I've proposed.  Although the digital
signatures would work fine, most users would want to know what the cleartext
app data was too, so draft -01 currently hashes cleartext app data.

a) TLS Evidence doesn't know or care if the application data contains a
button clicked event, be it recorded as "OK", or "0" or "0xff3456ab" or
"button 0x200".  It never looks inside at app data, it just hashes & signs.

c) Making sense of the app data, handshake messages and digital signatures
is a forensic task, not something TLS Evidence implementations worry about.
This forensic work will be done some time after the transaction occurred,
not inside the crypto protocol as the transaction occurs.  I hope to make
forensics easier simply by laying out a clear record of what bits actually
got sent by whom.  TLS Evidence has no idea "what it all means" but
designers can configure TLS Evidence systems so that the record is
reasonably clear (they likely won't get it perfect, and that's a limit that
TLS Evidence accepts).  

The kind of design work I propose for users of TLS Evidence is analogous to
writing intelligent debugging trace outputs -- the intelligence here is to
make the record clear so if the software unexpectedly goes belly up, you can
put together a good guess as to what happened.  I believe that people will
benefit from having the option/ability to "turn trace on" for their
important transactions.  Both parties MUST agree first, as the ID makes
clear at a number of points.  But that's what I think TLS Evidence should
do, a lot like setting up Ethereal for a TLS session and creating two
digital signatures over the tracefile.  Sure, I hold the opinion that people
can employ TLS Authorizations so the tracefile is more useful -- might even
help show intent.  But TLS Evidence doesn't propose any magic/legal tricks.

2) TLS Evidence is incompatible with the "Click-through" aspect of
click-wrap licenses, but it's not incompatible with existing laws.  TLS
Evidence requires client authentication, which doesn't just mean some PKC
but a PKC that the server knows (i.e. can authenticate).  You have to
install the right PKC first.  You can't just use any PKC you have on hand
and expect to get in to some server that's demanding client authentication.
Even if it did, and your TLS client accidentally authenticated to the
server(?!?), you will still need to configure "turn trace on" and choose
acceptable crypto before evidence happens.  TLS Evidence gives you two
out-of-band ways to confirm "Are you sure?  Are you really sure?"  This is
the opposite of a casual in-band click wrap.

I hope that puts us on the same page.

--mark

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Dec 2006 15:23:59 -0800

"Mark Brown" <[email-masked]> writes:
> good name.) 

Yes, but the reason why this works is that the security properties
that TLS provides are clear and simple (and even at that are 
proving too complicated in many cases). You're proposing to 
make them much more complicated.

> bit as solving the problem).  Let us know...

I don't understand why you think that somehow putting this at the
TLS layer makes the situation any better. It merely moves the construction
of the signature further away from the user.

> waste any more time on this problem"?

No. It's an architectural principle based on the end-to-end argument.

> solves the "signer's intent" problems?  

I have. In my opinion it does not.

> before the handshake FINISHED pair. 

I think you're confusing technical proof of the user's computer
being involved with the issue of intent, which is about the *user*
being involved. Your draft provides the former, but not the latter.
Indeed, as I indicated earlier, it makes the latter *harder* to provide
because it's the application that interacts directly with the user.

> contractor's PKC uses crypto stronger than the military can crack.

I'm not saying that you *can't* have two signatures. I'm saying that
it's a mistake to *only* allow there to be two signatures. There
are lots of settings where evidence is one-way only. Consider,
for instance, a purchase receipt from a store.

> harder.

Huh? You've got signatures over the plaintext with a certificate
to go with then. You take the traffic keys and decrypt the traffic.
There's nothing even remotely difficult here. The line you're drawing
doesn't seem remotely convincing to me.

> happens.

But that's exactly application interaction. Either you generate
evidence for the entire transaction or you need the application
layer to trigger the evidence recording--and to refuse to proceed
unless it's agreed to. And then what happens when the counterparty
cheats and doesn't deliver their signature? There is an enormous
amount of application interaction here, and it all requires
signalling between the app and the TLS stack.

>  TLS Evidence isn't something one party can demand with no warning,

I don't even understand what API you are imagining here. The TLS
stack is going to throw out data from when the application requests
to start gathering evidence until it's suddenly marked as the
start of the evidence block?

> application-level constructs. 

Something I never said. TLS makes extensive use of digital signatures.
Rather, digital signatures over *application data* should be done
at the application layer.

> is the raison d'etre of TLS.

No. The raison d'etre of TLS is to solve a *particular* problem. Not
this one.

>  TLS makes the crypto problems easy (for the

This sounds like exactly what I said "easier to deploy."

> more information about the scenarios you are thinking of here.

I think I did.

Let's just take the second point. I'm a bank and the customer
requests a financial transaction. I don't want to change anything
in my database until the customer has sent me a signed request.
However, because of the way you've constructed the protocol,
I don't get the customer's signature until after I've changed
the database entry and then sent my response. If the customer
then decides not to send me their signature, I need to throw
an application-layer error and then roll back the entire 
transaction. That's not at all convenient.

> what they consider to be strong asymmetric crypto.

I don't see how this is qualitatively different from the ordinary TLS case
where I'm sending my credit card to a server and I have to decide whether
the certificate it's offering represents a strong enough key. We don't
bind key lengths to cipher suites there (with the exception of export)
and we shouldn't do it here either.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 21 Dec 2006 08:29:50 +0000

I think this discussion is even more "evidence" that the subject of "evidence" is totally misplaced in TLS protocol design.
There are simply too many factors that are dependent on the layers above TLS.

Keeping the legal angle of this document will take it nowhere but down the drain of the NR mess.
Not saying that someone can't make use of this, or any other security protocol, to produce evidence. But how that is achieved is completely out of scope of the technical protocol.

We don't have to repeat this mistake over and over again.

Stefan Santesson
Senior Program Manager

> Sent: den 21 december 2006 00:24
> To: Mark Brown
> Cc: [email-masked]
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00
>

---

From: "Mark Brown" <[email-masked]>
Date: Thu, 21 Dec 2006 09:47:29 -0600

I think my personal opinions about what might be helpful to the legal
process are distracting the discussion on this forum.  I'd like to take my
opinions and statements about the legal aspect of evidence off the table.  

Sorry to open that can of worms...

--mark

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Thursday, December 21, 2006 2:30 AM
> To: EKR; Mark Brown
> Cc: [email-masked]
> I think this discussion is even more "evidence" that the subject of
> "evidence" is totally misplaced in TLS protocol design.
> Not saying that someone can't make use of this, or any other security
> protocol, to produce evidence. But how that is achieved is completely out
> of scope of the technical protocol.
>