[Cryptography] open questions in secure protocol design?
mitch at niftyegg.com
Fri May 29 21:13:44 EDT 2015
On Fri, May 29, 2015 at 7:23 AM, ianG <iang at iang.org> wrote:
> On 28/05/2015 00:58 am, Ray Dillinger wrote:
>> On 05/26/2015 02:53 AM, Michael Kjörling wrote:
>> Algorithm agility doesn't really help much if you don't have a plan
> Show me a means of pushing upgrades to users, and I will show you a
>> crook with a means of pushing downgrades deliberately mislabeled as
>> upgrades to users, in order to rip them off.
> Yup. On the one hand, 1TCS forces you to have a way of upgrading.
> So that looks like an advantage. But, it's a chimera. It just shifts the
> pieces around the board. You still need a way of pushing a config or
> negotiation upgrade out to the users.
Push protocols are problematic.
Add language like: Announcing, verifying, delivery... they seem to be
necessary sub steps.
Delivering a configuration is not equal to update delivery.
A bad config is just as troubling as a flaw in the package that
triggers a need to update. A good update with a bad config file
is equally difficult.
The nature of the flaw could by its nature make an automatic push
process very risky as an external agent could trigger a push
with a back door by exploiting a defect in need of repair.
In the rat hole, this push stuff is one of the reasons that DOCSIS modems
a big infrastructure risk (IMO). There is enough bandwidth on the far
side of the modem
that hacked and tricked modem updates may prove troubling. Same for the
WiFi devices that also serve up sold bandwidth to neighbors and unknowns
Some agility is needed but it needs gates and controls.
Perhaps IoT devices need a "do not use after date" like canned food.
If the price was low enough that may be a good answer.
T o m M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography