As mentioned in yesterday's call: give me/us some more time to work it out more precisely first. We have a meeting on Monday to verify and consolidate the current proposal - I believe I shouldn't speak up before that. (And I don't want to risk a shit-storm in case I get some parts wrong or immature; most of the people on this list are much smarter than me regarding these topics ;-)
Stevie > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com] > Sent: Thursday, October 19, 2017 10:03 PM > To: Beck, Stefan <s.b...@osram.com>; ace@ietf.org > Subject: RE: [Ace] multicast > > So, what are you suggesting? > > -----Original Message----- > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Beck, Stefan > Sent: 19 October 2017 21:59 > To: ace@ietf.org > Subject: Re: [Ace] multicast > > I totally agree with Mike. > BTW, Hannes, this was "part a." of Idea #1 - the only added value I've seen > was > that the device could raise an alarm - so there is awareness of an attack at > least > "after the fact". However, it adds complexity to the constrained device - > and > alternatively, one could just use one separate listener to the multicast > group, > that just does this job. It's multicast, so a single listener is sufficient > to handle > such type of alarms. > > "Part b." would even be more important to me: the multicasters (not the > listeners) are the constrained devices > that are unable to sign their messages in time. (Think of battery-powered > low > cost wall switches). > In that case they would need to pre-compile their multicast message (or set > of > messages- > eg. one or more for turn off / turn on / dim level x events), so they just > fire them > when the event happens. > Again, this adds a lot of complexity, and may even not be feasible at all > (in case > you have timing constraints in the crypto operations) > > Stevie > > > -----Original Message----- > > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns > > Sent: Thursday, October 19, 2017 6:38 PM > > To: ace@ietf.org > > Subject: Re: [Ace] multicast > > > > On 10/19/2017 10:59 AM, Hannes Tschofenig wrote: > > > I suspect the idea is the following: > > > > > > 1) First, you would decrypt the packet and validate the mac > > > (assuming that it is an AEAD cipher) > > > 2) You execute the operation to meet the latency requirements. > > > 3) Then, you can take time to verify the digital signature (outside > > > the latency requirements) > > > > > > Is that the idea? > > > > > > > It can't possibly be. What do you do if the digital signature doesn't > > verify? Reverse the operation? Flicker the lights? Go back to the > > original > > levels? Flash "OOPS" in morse code? > > > > You need to verify the signature in advance of doing an operation > > authenticated and authorized by that signature.... > > > > Mike > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .i > > > etf.org%2Fmailman%2Flistinfo%2Face&data=02%7C01%7C%7Cd6a2b032140a4 > > > 8082e1908d5170fc763%7Cec1ca250c2344d56a76b7dfb9eee0c46%7C0%7C0%7 > > > C636440278895347864&sdata=fpqgRpYFEvJxQUc4l2zlHM%2BUc7VaYLcp217q3 > > 2kHgLQ%3D&reserved=0 > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in > any > medium. Thank you.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
