[Cryptography] a question on consensus over algorithmic agility

Stephen Farrell stephen.farrell at cs.tcd.ie
Wed Jun 25 18:53:14 EDT 2014


Hiya,

On 25/06/14 21:49, ianG wrote:
> On 25/06/2014 19:50 pm, Zooko Wilcox-OHearn wrote:
>> I think you should be careful not to conflate cipher-agility with
>> protocol upgrade-ability. A false alternative would be to say that we
>> have to choose one of these two choices:
>>
>> 1. SSL-style cipher-agility
>>
>> 2. MyTransportProtocol circa 2014 will come with AES, and then it will
>> be impossible for any future deployment of MyTransportProtocol to use
>> any other cipher than AES.
>>
>> Note that if (2) were true, that would also imply that it is
>> impossible for any future deployment of MyTransportProtocol to change
>> anything *else* about the MyTransportProtocol protocol, either.
> 
> 
> That'd be FIPS version of the One True Transport Protocol, yes ;-)
> 
> 
>> Instead, I think the omitted third alternative is the best one:
>>
>> 3. MyTransportProtocol circa 2014 will come with AES, and AES alone,
>> and it will have sufficient unambiguous versioning indicators that it
>> will be possible to deploy new versions of MyTransportProtocol in the
>> future that may come with a different cipher.
> 
> 
> Your third alternative is exactly spot on.  My intent is to allow any
> algorithm choice to occur only at the upgrade from vN to vN+1.
> 
> I think it impossible to get away from version upgrading... So it
> becomes the upgrade of last resort.
> 
> Philosophically, however, I think it is necessary to get people to
> accept that algorithm agility is not a MUST within the context of
> MyTransportProtocol(2014), in the absolutist sense that IETF sees it
> right now;  before moving on to the dynamic consideration of version
> upgrading.

Absolutist? Hrmpf. (I didn't type Hrmpf at first;-)

> I'm also thinking that IETF is locked in a mindset, and those that have
> seen the light simply don't go anywhere near the place.  So if we can
> show an external picture that is different, it might get some more light
> into the dusty dark corridors of net power.
> 
> I could be wrong, often am, happy to bat towards a 50% average in this
> game...

I'd also be interested if this discussion landed somewhere else
sensible, but I'd be surprised.

Please do note though that:

- there's the backup algs argument that the protocol has to have
codepoints defined and interop working now for the next one we
may need to deploy in some years e.g. its taking some work to get
the fine detail of how to do 25519 (and ed25519) key representation
in TLS now, and that has to happen well before being needed for a
backup alg; you just cannot do that and get interop in the time it
takes to upgrade a single implementation and assuming all future
alg breaks will be slow burners is not considered good engineering
by many

- there are national algs in the world, and its not easy to say
no to all of those in all cases for all implementers and deployments
(I wish it were)

- sometimes you have platform issues, e.g. lots of layer 2 h/w does
AES CCM, whereas we generally prefer AES GCM in many cases. Both
are reasonable decisions made in different places (IEEE and IETF
for example) so protocols on the boundaries (e.g. CoAP) will need
to support one or both of those in different deployments; the same
thing can happen for timing reasons e.g. if a highly popular dev
environment just doesn't support the perfect ciphersuite but has
one nearly as good and no sign of an update coming

I do however agree that once you start down that road you quickly
end up in 300+ ciphersuite hell, so yes alg agility is a pain, but
maybe an unavoidable one.

I could however see an argument that only 1 bit be allocated for
algorithm/ciphersuite identifiers though that doesn't work so well
for the platform issue, it might be good enough for the other two.

S.


> 
> 
> 
> iang
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
> 


More information about the cryptography mailing list