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

[Eric Rescorla <[e-mail]>]

"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