On Sat, Nov 3, 2012 at 6:25 PM, ianG <i...@iang.org> wrote:
> On 1/11/12 10:55 AM, Peter Gutmann wrote:
>>
>> Jeffrey Walton <noloa...@gmail.com> writes:
>>
>>> Is anyone aware of of application layer encryption protocols with session
>>> management tuned for use on cellular networks?
>>>
>>> [...]
>>
>>
>> From that description your problem isn't at the encryption-protocol level
>> at
>> all, you need a reliable transport mechanism for cellular networks,
>
> Sounds like. The short answer is: use UDP datagrams [1].
>
> This is a good answer because in doing so you will be forced to construct
> your own reliable transport mechanisms over UDP, as and when you discover
> the various failure cases. (e.g., a lesson of discovery, fun!)
>
> It's not such a good answer if your team is used to ignoring all those
> problems by using TCP and thinking they're done 'n dusted. It's not a good
> answer if you are thinking you can do some quick tweaks to an existing app -
> as in practice it probably relies on TCP in which case the entire design is
> poisoned with the assumptions therein (more below).
My observation after self-reflection: TCP/IP is so ingrained, I was
subconsciously depending upon the "connection oriented, reliableness"
it offered - it was a session management crutch (albeit an "untrusted
session" management crutch).
>> something
>> that's totally independent of what crypto you're using. Then you run your
>> favourite crypto over that.
>
> I'm not convinced of that. This whole concept of 'layering' as a useful
> simplification kind of took a wrong turn around the late 1980s with ISO's 7
> layer model. Although a useful abstraction, it led people into thinking
> that if they built protocols for each layer then they could plug them in
> together and everything would be fine! Science has triumphed again! Let's
> mandate a set of protocols in each layer!
I'm not convinced either. In the past, I used to feel that way, but
I'm reconciling it now.
I recently had the epiphany: the crypto layer must have some
rudimentary session management stuff. Session management is clearly
outside the realm of crypto. Session management is usually handled
higher in the stack.
Rudimentary session management is required for fast recovery in the
cellular environment. Previously, the implied session was the tuple
{Client IP, Client Port, Server IP, Sever Port}. Because of TCP/IP
tricks being played by handset manufacturers, carriers, and OS
provided connection managers, it is no longer reliable. My apologies
if I incorrectly fingered someone here.
I think the on-wire and over-the-air message format needs to be changed to:
{Session ID, IV, Encrypted Data, Auth Tag}
I clearly need an authenticated encryption mode with AAD. I'm
researching the implications of a plain text Session ID.
Heuristically, its no worse then the previous plain text {Client IP,
Client Port, Server IP, Sever Port}.
By having an explicit Session ID, it does not matter what UDP socket
sends the message. I believe it allows for the fast recovery I am
seeking.
Jeff
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
