On 9/26/2016 12:31 PM, [email protected] wrote:
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.
With respect - no. The issue is with respect to the discussion of
whether or not to adopt this as a WG item. To "address" the issue,
there has to be an offer of proof that someone actually knows how to
address it - BEFORE the item is adopted. I may have missed that offer
of proof, but I don't think so.
You're suggesting that the way of addressing this is to ignore the
issues, adopt it the work item, and at some far distant future point
make sure there is a security considerations section that says something
that might or might not be meaningful. "I will gladly pay you Tuesday
for a hamburger today" - J Wellington Wimpy.
An interesting approach, but probably not in keeping with correct process.
The chairs haven't put out a decision and your concerns have been heard. They
are working to assess consensus.
The counter point to my concerns being heard is them being "addressed"
as part of assessing consensus. It says so right there in RFC 7282.
Later, Mike
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
