[Cryptography] open questions in secure protocol design?

[alex at alten.org]

Quoting ianG <iang at iang.org>:

> On 26/05/2015 14:44 pm, Stephen Farrell wrote:
>>
>>
>> On 26/05/15 14:35, Ben Laurie wrote:
>>> The way CT works is neither 1TCS nor agility - if you want to change
>>> ciphersuite, you start a new log. So, it seems there are other parts of the
>>> design space...
>>>
>>
>> Well yes and no. Yes, CT handles this differently from e.g. TLS and
>> that's fine. No, in that 1TCS is just a broken concept and hence is
>> not IMO part of any rational design space in the real world. 1TCS is
>> part of the rhetorical landscape but not a real design choice.
>
>
>
> I sense a little over-reaction here.  1TCS is part of the real  
> world, it's been used, and it does the job.
>
>
>

....snipped..

> So we might end up saying that the same designs that need IETF would  
> also prefer agility.  I see correlation there.  Maybe, there's an  
> underlying causality.
>
> But I wouldn't say that the IETF causes agility, no more than I'd  
> say that agility is the cause of the IETF or that the IETF is the  
> owner of all rationality and design space and protocols and  
> everything.  That would be ... an overstretch.
>
> More likely there is an underlying factor that is causal.  Something  
> about the way the IETF is constructed is also something about why  
> the people found at IETF need agility.
>

My experience with the IETF is that the sender (in a network protocol) should
encode in a single manner and that the receiver should be accepting of a wide
variety of encoding styles (that mean the same thing). My take is that
this is because the Internet is composed of heterogeneous software & hardware
and that protocol implementers would read the same specification and implement
it in slightly different ways.

On one project that I designed I applied this to our crypto  
communications that
passed around data keys for enciphered data.  I recommended to each  
our application
implementation teams to encrypt using one key type (say AES CTR for  
team A and 3DES
CBC for team B), but to be accepting of a wide variety of key  
types/modes while
decrypting (say AES, 3DES and Blowfish).  As long as the key lengths (and the
algorithms/modes) met the minimum policy requirement being applied to  
the enciphered
data this worked fine.

- Alex




-- 
Alex Alten
alex at alten.org