This time as AD. Please excuse typos, sent from handheld device
> On Sep 26, 2016, at 11:41 AM, Michael StJohns <[email protected]> wrote: > >> On 9/26/2016 8:30 AM, [email protected] wrote: >> Without a hat on, you can add my support to Abhinav's proposal. Perfect is >> ideal, but you often can not make any progress if you accept nothing less. >> The security considerations section will have to be thorough. > > Hi Kathleen et al - > > To attain "rough consensus", RFC 7282 requires that "all issues be addressed" > even if not all issues are accommodated. So far the basic issues of "this is > unsafe as a mechanism for 'securing' a control protocol" or even "how the > heck do we keep this off the broader internet" have not been addressed. This can be addressed in a draft security considerations. The scope can be made applicable to what's needed to constrain its use. The chairs haven't put out a decision and your concerns have been heard. They are working to assess consensus. Best regards, Kathleen > > I once again suggest that the lighting folk go off and write something that > they implement as a group, and bring it back to the IETF as an informational > "here's how we did it" document, rather than adopting this as a WG item. The > ONLY thing that even argues for considering symmetric key multicast (vice > asymmetric key multicast) is the latency claims for lighting. I haven't yet > heard of another use case with the particular combination of cheapness and > latency of lighting which would suggest this particular combination is useful > elsewhere. > > With respect to Abhinav's proposal, we've already got several group key > manager systems - we don't actually use any of them for control systems, and > you might want to inquire as to the reason. [RFC2093,2094] [RFC4046] [RFC4535] > > With respect to Eliot's comment, it doesn't really matter if the key > management protocol is asymmetric if the multicast session keys are symmetric > and used for control. The analysis of this can pretty much ignore the key > management piece and start with 100 controllers and 1000 actuators with > pre-shared keys to consider the threat and mitigation models. Which analysis > - AFAICT - no one has actually done. Basically, if you can't secure this > 100/1000 system and keep it secure with respect to control functions, I > would argue that the rest of it (e.g. key management) is meaningless window > dressing. > > Later, Mike > > ps - do you *really* want to reinvent SCADA and all its security issues? > >> >> Kathleen >> >> Please excuse typos, sent from handheld device >> >>> On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig <[email protected]> >>> wrote: >>> >>> I noticed that Eliot also expressed support for the approach presented by >>> Abhinav, see >>> https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI >>> >>> Ciao >>> Hannes >>> >>>> On 09/26/2016 07:11 PM, Kepeng Li wrote: >>>> Hi all, >>>> >>>> >>>> We went through all email exchanges again in order to see where we are. >>>> Abhinav also proposed a way forward in his email to the list, >>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, >>>> where he proposed to standardize a solution based on public key as well >>>> as symmetric key cryptography. >>>> >>>> >>>> Here is our impression of the views presented by various people. >>>> >>>> >>>> Mike seems to think the only acceptable solution is to use messages >>>> signed using public key crypto and is strongly against working on a >>>> symmetric key group communication protocol. >>>> >>>> >>>> Paul Duffy and Michael Richardson are in favor of defining a public key >>>> crypto solution but it is not clear whether they are against specifying >>>> a symmetric key solution as well. >>>> >>>> >>>> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric >>>> key group communication security protocols (as co-authors of the work). >>>> Oscar Garcia (Philips) is also in favor of the work. >>>> >>>> >>>> In this mail to the list, >>>> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, >>>> Robert Cragie (ARM) expressed a view that public key crypto is the >>>> preferred solution but others based on symmetric crypto are still worthy >>>> of consideration. >>>> >>>> >>>> Markus Grunwald (Osram) also appears to be in favor of the proposed >>>> approach, see >>>> >>>> https://www.ietf.org/mail-archive/web/ace/current/msg01932.html >>>> >>>> >>>> >>>> Akbar Rahman also seems to be in favor of working on a group >>>> communication security protocol, see >>>> >>>> https://www.ietf.org/mail-archive/web/ace/current/msg01873.html >>>> >>>> >>>> >>>> Ned Smith also seems to be in favor of working on a group communication >>>> security protocol, as expressed in his mail to the list: >>>> >>>> https://www.ietf.org/mail-archive/web/ace/current/msg01872.html >>>> >>>> >>>> >>>> The opinion of the following persons in the discussion appear unclear to >>>> me: >>>> >>>> - Mohit Sethi >>>> >>>> - Ludwig Seitz >>>> >>>> - Carsten Bormann >>>> >>>> - Stephen Farrell >>>> >>>> - Jim Schaad (offered clarifications regarding the use of COSE) >>>> >>>> >>>> >>>> Pascal Urien and Rene Struik provided performance data but they didn't >>>> appear to have expressed a strong view about the question regarding >>>> symmetric vs. asymmetric crypto for group communication security. >>>> >>>> Derek Atkins offered performance data for public key crypto but refers >>>> to new techniques (rather than RSA/ECC). >>>> >>>> >>>> >>>> Please correct us if we are wrong in our interpretation of your mail >>>> postings. >>>> >>>> >>>> >>>> Ciao >>>> >>>> Hannes & Kepeng >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ace mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ace >> _______________________________________________ >> Ace mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
