replay & integrity

[Zooko]

 Ian Grigg wrote:
>
> So, some protocols don't need replay prevention
> from lower layers because they have sufficient
> checks built in.  This would apply to any protocols
> that have financial significance;  in general, no
> protocol should be without its own unique Ids.

I'll try to make this concrete.  My thesis is different than Ian's -- rather 
than saying that those apps need less than what TLS offers, I say that they 
need more!  (So that each app need no longer implement the added features 
itself.)

[Disclaimer: My understanding of SSL/TLS is incomplete.  Eric Rescorla's book 
is on my amazon wishlist.  Please be polite when correcting my errors, and 
I'll do the same for you.]

Replay prevention in SSL/TLS is related to the concept of "sessions".  A given 
sequence of bytes can't be replayed within a given session, nor replayed in a 
different session, nor can a session itself be replayed in whole or in part.

Sounds good, right?

But suppose at the higher layer you have a message which you wish to send, and 
you wish to ensure that the message is processed by the recipient at most 
once, and you wish to keep trying to send the message even if you suffer a 
network failure.

For example: "<transfer><outaccount_id>100876</o><inaccount_id>975231</i> 
<currency>USD</c><amount>1000.00</a></transfer>".

Assume that the user has delivered the instructions to you, through clicking 
on a GUI, sending you a signed snail mail letter, or whatever, and now it is 
your job to convince the computer at the other end of the TLS connection -- 
your "counterparty" -- to implement this transaction.

Now if you send this message, and you get a response from your counterparty 
saying "<transfer_status>completed</transfer_status>", then you are finished.

But suppose you send this message, and then the TCP connection breaks and the 
TLS session ends?

You don't know if your counterparty got the message, much less if he was able 
to implement the transaction on his end.  If you open a new TLS connection and 
send the message again, you might inadvertently transfer *two* thousand 
dollars instead of one.

Now the state of the art in apps like these, as Ian has pointed out, is to 
implement replay protecton at the app level, for example adding a transaction 
sequence number to the message.

To me, this sounds like an opportunity for another layer, which provides a 
general solution to this problem.  (I would expect Ian's SOX protocol to be 
one such design.)

Of course, not all problems are amenable to a general, reusable solution.
Not even when, as in this case, almost all applications independently 
re-invent a special-purpose solution.

The particular sticking point in this problem seems to be state management -- 
you have to be careful that one side or the other isn't stuck with excessive 
requirements to store information in order to complete the protocol.

As Ian mentioned, apps can have several other possible requirements in 
addition to this one (which I call "retriability").  Consider a situation 
where the message has to be printed out and stuck in a folder for a lawyer to 
review.  If the integrity guarantee is encoded into a long-term, multi-packet 
TLS stream, then this guarantee cannot easily be stuck into the folder.  If 
the integrity guarantee appears as a MAC or digital signature specific to that 
message, then perhaps it is reasonable for it to be printed out in the header 
of the message.

Now to be clear, I'm not saying that TLS ought to provide this kind of 
functionality, nor am I even asserting that a generic layer *could* provide 
functionality sufficient for these sorts of apps, but I am saying that the 
notion of replay-prevention and integrity which is implemented in TLS is 
insufficient for these sorts of apps, and that I'm interested in attempts to 
offer a higher-level abstraction.

Regards,

Zooko

http://zooko.com/
         ^-- under re-construction: some new stuff, some broken links

P.S.  I am aware that TLS encompasses the notion of stored or cached sessions, 
originally conceived for performance reasons.  Perhaps a higher-level 
abstraction could be built by requiring each party to use that facility in a 
specific way...

P.P.S.  A lot of the "app-specific" solutions that get deployed, such as the 
"add a sequence number" one mentioned in the example above, *depend* upon 
TLS's session-specific replay-prevention for security.  Ian suggested that 
this was a good test of the cryptographic robustness of a higher-layer protocol.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com