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

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

Eric,

I meant to say the rule is this: whatever app data you send, you MUST chase
it with EvidenceRequest.  So with this rule, server MUST expect
EvidenceRequest-1 to be paired with ApplicationData-1.  This rule is in
effect for the entire TLS session including any resumes.

> > Since I've run this example while dropping alerts, no start1, etc. are
> > required and all application data will generate evidence until the
> session
> > is terminated.  If alerts are dropped, then a fairly "safe" rule for
> > evidence generation is to require that every time client or server dumps
> a
> > stream of application data to TLS records and to the wire (a single TLS
> > write call by the app) an EvidenceRequest also be created and sent.
> 
> Yes, but how does the *app* know that?

App doesn't need to know.  App can ignore all Evidence- messages so long as
some component somewhere is storing them.  If app needs to store them, app
still doesn't need to be aware of the protocol rules.  As far as the app is
concerned, there's either app data (and Evidence- if it wants to fetch it)
or there isn't.  IF the TLS Evidence rules required that the TLS session be
shut down, then app will discover that the session is terminated on next
read or write attempt.

The new api here is to allow apps to getLastEvidence().  If they call this
in the middle of the session, or after the session closes or abends, the
semantics are the same: null, or the last Evidence- structure sent/received.
IF the app never calls getLastEvidence, that's Ok too as far as the TLS
layer is concerned -- maybe a wiretap on the TLS session is the preferred
method of persisting the TLS Evidence.

> 
> 
> > The TLS
> > layer simply lets the app layer set the pace in this no-alerts proposal.
> > Since I'm provisionally dropping alerts here, I think it's best to NOT
> reset
> > the TLS Evidence application_data hashes any time during the session --
> just
> > let them accumulate across all Evidence- messages for the session.  My
> > example of this is shown below:
> >
> >       ApplicationData-1         -------->    [Client's instructions]
> >       EvidenceRequest-1         -------->
> >                                 <--------    EvidenceResponse-1
> >       [Server's response]       <--------    ApplicationData-2
> 
> But there's a race condition here. The server doesn't know that
> an EvidenceRequest-1 message is coming, so how does it know
> to wait for it before executing whatever transaction the client
> requested? Remember that TLS is a stream protocol, so the only
> boundaries are at the higher layer.

See above, the server has knowledge that: throughout this entire TLS Session
EvidenceRequests MUST follow ApplicationData "immediately".  If client gets
cold feet about the transaction it would be more polite to send an alert to
close the session.  But under these circumstances the client is not likely
to be DOS'ing the server -- server has authenticated client.

> If the server wants to follow the (reasonable) policy of not
> performing any actions until after he's received signed instructions
> from the client, then he has to block waiting for the client to
> generate a signature. At minimum this requires interaction with the app
> because (again) the TLS stack doesn't know. Moreover, without
> some external agreement about how often these are generated,
> you can get a deadlock. Now, the server could certainly ask for
> a signature by sending his own Evidence-Request, but now you're
> requiring app interaction.

I think there's ways to address this challenge.  My solution is ok not
great.  Have the TLS server hold on to the last app data TLS record until
another app data or an EvidenceRequest arrives.  Don't notify, or have TLS
keep it locked away from the app, etc., depending on the style of
integration with the server app.  Now if the EvidenceRequest never arrives
presume it's because the line got cut.  Notify the server app of the socket
failure without delivering the last app data record.  Now the server app
faces the same problem that he faces whether he uses TLS, TLS Evidence or
just a socket, so the server app already needs to be able to deal with that
problem.

On the other hand, if EvidenceRequest arrives and there's a crypto failure
in it, TLS server should presume it's an attack.  There's no valid reason
for an error I can think of.  This is not a shrug and forget about it
situation.  Blacklist or revoke the client PKC, roll back the app
transaction with a severe error, fire up a pager, etc.

I think what I'm saying is that in a mutually authenticated,
evidence-generating situation it is correct to be strict on failures and
lenient on no-shows.  Both parties are very interested in this transaction,
and they will understand if, for the sake of security, there's some
inefficiencies incurred under rainy-day circumstances.

I also think that DOS attacks are less likely under mutual authentication
circumstances; if they occur, then you know who perpetrated them (at least
which private key(s) did).

> > Threats I've considered include: client or server "hangs up" at an
> opportune
> > moment in the exchange, one sends garbage, one sends something
> unexpected in
> > the app data.  I think all of these threats pose little risk to the
> parties
> > because of two facts.
> >
> > 1) before either party gets their EvidenceResponse, they can walk away
> and
> > claim "it didn't happen."
> 
> But transaction rollbacks are expensive and complicated. It's much
> better to simply not perform the transaction if the counterparty
> hasn't authenticated. Moreover, in this system you *need* to
> treat a failed evidence handshake (e.g., due to network failures)
> as an attack and execute a transaction rollback. With ordinary
> signed messages this isn't true since a network failure just
> causes the counterparty not to get their receipt.
> 
> -Ekr

Yes, it really would be a pain to do transaction rollbacks.  But the premise
I want to start with is that the cost of a tx rollback has already been
determined at design time to be less than the cost of getting the tx or its
evidence wrong.  I don't want to try to pretend that tacking on TLS Evidence
won't cost you.  It will.  But in some cases the cost of adding this kind of
security (forgery resistance) is outweighed by the benefits.  It's just
another security trade-off.  

What we're talking about is failure and attack cases.  I want TLS Evidence
to fail secure whether the line is cut or an attack is underway.  But I
think since the mutual authentication has completed already it's overkill to
require TLS Evidence to fail secure AND fail efficiently (i.e. avoid DOS and
rollbacks).  Because server knows who is on the other end, server gives a
little more latitude, takes a little more risk of lost time.

--mark


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