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

[Stefan Santesson <[e-mail]>]

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
Windows Security, Standards


> -----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]]
> Sent: den 21 december 2006 00:24
> To: Mark Brown
> Cc: [e-mail]
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00
>
> "Mark Brown" <[e-mail]> writes:
> > 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.)
>
> 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.
>
>
> > 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...
>
> 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.
>
>
> > 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"?
>
> No. It's an architectural principle based on the end-to-end argument.
>
>
> > 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?
>
> I have. In my opinion it does not.
>
>
> > 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.
>
> 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.
>
>
> > 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.
>
> 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.
>
> >> 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.
>
> 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.
>
>
> > 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.
>
> 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,
> > 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.
>
> 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?
>
>
> > It is an unwarranted prejudice to hold that digital signatures must
> be
> > 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.
>
>
> >> 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.
>
> No. The raison d'etre of TLS is to solve a *particular* problem. Not
> this one.
>
>
> >  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 sounds like exactly what I said "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.
> >
> > 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.
>
> 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.
>
> >> 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.
>
> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls

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