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

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

Eric,

Thanks.  Ok, I'm starting to get on the same page as you (I hope).

> Mark, nobody is doubting tha it's attractive to be able to provide
> third party evidence of what happened in a given transaction. That's
> why so much work has been put into digitally signing application
> layer traffic. The question at hand is where in the stack this
> functionality should go.

Again, I think the 00 and 01 drafts are unclear in places.  I'm going to
present a sunny-day scenario and try to consider the applications'
perspectives too.  Hopefully this will flush out where the app could benefit
and if the app-over-TLS Evidence API is clunky.

In this example I will provisionally DROP the four alerts (start1, start2,
end1, end2).  They aren't needed in this example I've suggested it as an
option earlier.

       *  Indicates optional or situation-dependent messages that
          are not always sent.
       +  Indicates messages optional to the TLS handshake that
          MUST be sent when using TLS evidence.

      CLIENT                                 SERVER
      ======================                 =======================
      ClientHello               -------->
                                                        ServerHello
                                                       Certificate+
                                                 ServerKeyExchange*
                                                CertificateRequest+
                                <--------           ServerHelloDone
      Certificate+
      ClientKeyExchange
      CertificateVerify+
      ChangeCipherSpec
      Finished                  -------->
                                                   ChangeCipherSpec
                                <--------                  Finished

At this point, ClientHello included a request for the entire session to use
TLS Evidence, and the ServerHello must have agreed.  Otherwise, this
handshake would have terminated after the Hellos.  Also, mutual
authentication must also have been successful.  All of this must be true
before the Finished messages indicate that a TLS evidence session is born.

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.  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
                                <--------    EvidenceRequest-2
      EvidenceResponse-2        -------->

BTW, whether you run TLS Evidence with or without the four alerts (start1,
etc.) you could have generated EvidenceResponse-1 and EvidenceResponse-2.
To repeat from -00 and -01, the EvidenceRequest is just one party's opinion
and signature, but EvidenceResponse proves that both parties independently
computed the same hash over all the data fields as proscribed by TLS
Evidence.  So you EvidenceRequest is superseded (it's pretty much worthless
to you) if you get a corresponding EvidenceResponse back.  

I think there's two aspects of whether this serves the application, or if it
would be better for the apps to do the signatures at the app layer.  First,
is either client or server is sticking its neck out during this protocol?
Second, how does the app need to configure and interact with the TLS layer
to get this done? 

I don't think either client or server is exposing itself to undue risk when
they use TLS Evidence.  TLS Client sends its app data, and when the buffer
it shares with TLS is empty, TLS automatically sends the EvidenceRequest-1.
This is basically a hash over the handshake, a hash over the app data sent
(yours) and received (none), a best-effort timestamp, etc., all digitally
signed by client.  My opinion is that the more specific client can be, the
less likely this digital signature can be abused later (threats of replay,
misappropriating the signature for some other purpose, etc.).  

TLS Server replies with EvidenceResponse-1, even before its application has
looked at the application data.  Server simply says, yes, I saw the same
thing within the same session (and the timestamp looks like a best effort).

Next, the server app handles the data it just received from the TLS layer as
input, then it may have some output data.  The server app puts its output
data into a buffer and gives that to the TLS layer.  Now the TLS server
sends that app data and automatically chases it with EvidenceRequest-2.
Inside EvidenceRequest-2, there's a hash of the app_data sent and received,
etc., plus the TLS server's signature over the whole EvidenceRequest-2. 

Finally, TLS client replies with EvidenceResponse-2, proving that client saw
what server sent.

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."
2) once one or more EvidenceResponses exist, these become an "I know you
know" checkpoint that both parties can roll back to.  

I hope what I've said so far clarifies the -00 and -01 drafts, and also
presents opportunity for discussion and improvement.  Since this email is
already long, let me use anther email for "How does the app need to
configure and interact with the TLS layer to get this done?"

Thanks,

-mark


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