replay & integrity

[C. Wegrzyn]

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 at metzdowd.com
>
>  
>



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