On 11/17/2016 7:00 PM, [email protected] wrote:
Is anyone willing to work on a draft to be ready in advance of the
Chicago meeting so we have a concrete proposal for asymmetric keys?
I'm just catching up on old mail after getting over a cold.
Mostly, this could be as simple as a two to four paragraph draft:
1) Use CORE section 5 for message formats. (e.g. public key signed
messages) using one of several defined specific set of algorithms (e.g.
sha256withecdsa and p256 or something smaller) chosen by the application.
2) The authentication bare public key is a configuration item for the
end devices and placement is beyond the scope of this draft.
3) Tracking of a message ID from (1) to prevent command replay attacks.
4) Minimum numbers of controllers (e.g. public keys and actuation events
or message ids) that an end system has to track.
(2) could be folded into a draft about configuring end devices.
A more complex model would be:
1) Place a root certificate on all end systems via configuration (also
out of scope)
2) Describe the certification path algorithm (e.g. profile RFC5280)
3) Describe how the cert path certificates are carried in CORE section 5
messages.
4) plus 3 & 4 above.
5) plus how to operate in the presence of clock time.
Unlike symmetric key systems, there really doesn't need to be a key
management/agreement/transport protocol per se. It's all about a) what
constitutes a valid message, and b) what do you do with the valid
message once you get it.
An application specific draft would include message formats for things
included in a CORE section 5 message (e.g. the specific values for
turning on and off lightbulbs or setting their hues or intensity), but
that's not really an ACE thing per se.
Mike
Thanks,
Kathleen
Please excuse typos, sent from handheld device
On Nov 17, 2016, at 11:26 PM, Rene Struik <[email protected]
<mailto:[email protected]>> wrote:
Dear colleagues:
Just a reminder re perceived technical hurdles for using signatures:
a) time latency of signing:
One can pre-compute ephemeral signing keys, so as to reduce online
key computation to a few finite field multiplies.
Please see my email to the list of July 26, 2016:
https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0
b): further speed-ups/tricks, etc:
One can try and be smarter by clever implementations.
Please see my email to the list of July 21, 2016:
https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI
This seems to take the time latency argument away. The only other
technical hurdles I can see are
(i) signature size {is 64B too much?};
(ii) cost of public key crypto implementations {quite some small,
nifty designs out there (NaCl etc.}.
As to (i) - one should view signature sizes in perspective: as an
example, key sizes in the key pre-distribution scheme HIMMO (as
promoted by Philips) has key sizes of 6.25 kB and up, according to
Table 3 of the paper that massages parameters to thwart new attacks
on their scheme, see http://eprint.iacr.org/2016/152.
So, security arguments that favor asymmetric solutions aside, there
also do not seem to be too many other objections that would hold in
the world anno 2016 {except for "sunk investment" arguments", but
that is a corporate mindset issue}.
On 11/17/2016 12:50 AM, Michael StJohns wrote:
On 11/16/2016 9:08 AM, Kepeng Li wrote:
Hello all,
We had a long discussion about group communication security topic
since the previous F2F meeting.
Hannes and I have tried to make a summary about the discussion as
follows:
· The solution needs to define both, symmetric and an
asymmetric group key solution.
There is no case (absent hardware mitigation) in which a symmetric
group key solution can be made secure/safe and no one has made an
offer of proof that they can make it secure. I've asked
repeatedly - no one has come forward with more than "oh we can lock
the symmetric key stuff in a corner and make sure it isn't used for
anything important".
Given the recent attacks on the internet by IOT botnets, there is a
further consideration that should be undertaken - whether the
symmetric group key solution applied to 10s of 1000s of IOT devices
is an active threat to the rest of the internet (e.g. enabling DDOS,
cyber physical issues, etc)?
The multiparty (group) symmetric key solution is only wanted for a
single corner of the solution space - low latency, no cost systems.
E.g. lightbulbs. Given there is a worked example of the insecurity
of multiparty symmetric key systems (e.g. the attack on the
symmetric signing key of the HUE lights), I'm unclear why anyone at
all would think that pursuing a known bad solution in the IETF is a
good idea.
· The security consideration section needs to explain under
what circumstances what solution is appropriate.
Security consideration sections generally only address the threat
*to* the system from security choices. In this case, symmetric key
group comms reduces down to the same security analysis you would use
with shared default passwords across 1000s of devices. An IOT
security consideration section in the future probably needs to
address the threat *FROM* the IOT solution to the broader internet.
Mike
If this is not accurate, please let us know.
Kind Regards
Kepeng & Hannes
BTW: it is a pity that I can't attend this meeting due to personal
reasons, and hope you all have a nice meeting in Seoul!
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Ace mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
