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

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
question:

> S 1.
> It looks like the evidence creation has to involve signatures by
> 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).

> 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. 

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
> this at the TLS layer is the sense that it's easier to deploy.

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.

> 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.

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.

> 
> 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.

See above.

> 
> 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?

See above.

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

Ok.  

> 
> 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.

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.

> 
> 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.

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

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

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

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