Zooko, I don't think you actually need to worry about the At-Most-Once
semantics you example below. This sort of stuff has been around for
decades and there are a number of open source programs available. Don't
confuse what TLS does - transport messages securely end-to-end - to what
the end points do with them. We don't need to have another protocol
which includes TLS+At-Most-Once semantics. I'd say that would be a
terrible idea.
Chuck Wegrzyn
Zooko wrote:
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: transferoutaccount_id100876/oinaccount_id975231/i
currencyUSD/camount1000.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_statuscompleted/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.
