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

[Stefan Santesson <[e-mail]>]

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

> -----Original Message-----
> From: Mark Brown [mailto:[e-mail]]
> Sent: den 20 december 2006 07:01
> To: 'EKR'; [e-mail]
> Subject: 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls

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