[13810] in cryptography@c2.net mail archive
Re: replay & integrity
daemon@ATHENA.MIT.EDU (C. Wegrzyn)
Thu Jul 10 13:56:44 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 10 Jul 2003 08:17:10 -0400
From: "C. Wegrzyn" <wegrzyn@garbagedump.com>
To: Zooko <zooko@zooko.com>
Cc: iang@systemics.com, EKR <ekr@rtfm.com>,
tom st denis <tomstdenis@yahoo.com>, cryptography@metzdowd.com
In-Reply-To: <E19aJXk-0007bw-00@localhost>
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: "<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@metzdowd.com
>
>
>
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
