Hi Hannes -
Basically, the argument I'm hearing again is that we have to have common
protocols that work with the least capable devices in the same way that
they work with more capable devices. Which then is taken to mean that
we have to limit the security of said protocols to what's availab
On 5/14/2019 7:29 PM, Hannes Tschofenig wrote:
Hi Paul,
My understanding from reading the draft text was that the "cost" was actually talking about
"energy cost" rather than "monetary cost".
The monetary cost may also be interesting.
It is difficult to judge the extra cost of a RNG in an MCU b
As I mentioned at the microphone I'm opposed to pursuing symmetric key
multicast solutions. WRT to the current set of proposal documents, I
see no substantive improvement on the rejected proposals from the DICE
(https://mailarchive.ietf.org/arch/search/?email_list=dtls-iot) working
group. The
On 7/21/2016 5:29 AM, Ludwig Seitz wrote:
On 2016-07-21 11:04, Michael Richardson wrote:
Why will ACE succeed when DICE failed?
Does ACE now have some knowledge or mechanism that DICE couldn't have
created
because it was out of scope?
ACE is (also) about authorization, which DICE wasn't. A
On 7/21/2016 5:26 AM, Carsten Bormann wrote:
Michael Richardson wrote:
Why will ACE succeed when DICE failed?
Because DICE tried to hack something into TLS. That had no support.
Actually, that's not the complete story. It was one of the things that
finally killed this off (e.g. DICE was su
On 7/21/2016 5:04 AM, Hannes Tschofenig wrote:
Some other folks, including myself, believe that we would not just
use the group key to determine the authorization decision but would
instead rely on the authorization mechanism to prevent larger harm.
This means that a compromised luminare would in
On 7/23/2016 11:10 AM, Pascal Urien wrote:
Hi All
J3A081M is a javacard device from NXP
The micocontroller should be the P5CD081V1A, which comprises a crypto
processor
There's a number of these from a number of vendors. I'd actually look
at the A7xxx series of chips as they're designed to
On 7/25/2016 8:21 AM, Somaraju Abhinav wrote:
Hi Mike,
The group key is also the authorization key in the model proposed.
Any entity that holds that key can forge a message that can cause the
action authorized by the issuance of that key. In your example,
assuming that the door lock and th
On 7/25/2016 12:59 PM, Somaraju Abhinav wrote:
Let's try one more time here.
[AS] Good. Much clearer now.
1) If a group of devices share a key, and
2) If some of that group of devices are controllers, and
3) The majorit
il.com
<mailto:rstruik@gmail.com>]
*Sent:* Tuesday, July 26, 2016 3:00 AM
*To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav;
Michael StJohns; ace@ietf.org <mailto:ace@ietf.org>
*Subject:* Re: [Ace] Adoption of Low Latency Group
Co
On 7/26/2016 7:55 PM, Robert Cragie wrote:
Mike,
My concern with this thread is that you seem to have a very
black/white assumption regarding the use of a symmetric group key.
Defining a protocol which allows use of a symmetric group key does not
in itself imply that it will be misused. It's
On 7/27/2016 5:56 PM, Michael Richardson wrote:
Kathleen Moriarty wrote:
>> Mohit Sethi wrote:
>> > designed/developed/specified for their use-case. I could definitely
>> > see some IoT startup building a solution that switches on the lights
>> > in a room as soon as you unl
Hi Markus -
I needed to think about how to reply to this specifically and explain
why its still a bad idea to try and scale things. See below.
On 7/27/2016 8:34 AM, Grunwald, Markus wrote:
Hello,
sorry to break the threading by not replying directly to a post, but
until now I have only be
Hi -
It's been over a month since there's been any further discussion on this
topic. Given the record I would suggest a lack of consensus to proceed
on basis of two items: 1) A roughly even split on the vocal yays and
nays on the subject of symmetric key multicast for control functions and
Hi Elliot et al -
Sorry, I think you're still missing the point:
* Source Authentication (A) cannot be accomplished securely by
Symmetric Key Multicast (^B): (A -> ^B)
* Cyber Physical control functions (C) require source authentication
(A): (C -> A)
* Turning on and off lights (
On 9/16/2016 6:03 AM, Eliot Lear wrote:
Hi Mike,
On 9/15/16 5:36 PM, Michael StJohns wrote:
Hi Elliot et al -
Sorry, I think you're still missing the point:
* Source Authentication (A) cannot be accomplished securely by
Symmetric Key Multicast (^B): (A -> ^B)
* Cyber
On 9/26/2016 8:30 AM, kathleen.moriarty.i...@gmail.com 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
On 9/26/2016 12:10 PM, Eliot Lear wrote:
Hi Mike,
Just one clarification:
On 9/26/16 5:41 PM, Michael StJohns wrote:
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 cont
On 9/26/2016 12:31 PM, kathleen.moriarty.i...@gmail.com wrote:
This time as AD.
Please excuse typos, sent from handheld device
On Sep 26, 2016, at 11:41 AM, Michael StJohns wrote:
On 9/26/2016 8:30 AM, kathleen.moriarty.i...@gmail.com wrote:
Without a hat on, you can add my support to
On 11/12/2016 5:11 PM, Michael Richardson wrote:
I realize that this thread is months old: I haven't seen any newer
conversation, so I'll continue anyway.
I would concur with MSJ's view that having an informational draft might be a
way to let this work go forward, but I suggest instead the right
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 asymmet
" 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
Comments inline. Also see particularly, the comments underlined and in bold.
On 11/24/2016 9:09 AM, Hannes Tschofenig wrote:
Hi Mike
On 11/17/2016 06:50 AM, Michael StJohns wrote:
There is no case (absent hardware mitigation) in which a symmetric group
key solution can be made secure/safe and
me immediately by email, and
delete the original message and any attachments. Unless expressly
stated in this e-mail, nothing in this message or any attachment
should be construed as a digital or electronic signature.
*From:*Ace [mailto:ace-boun...@ietf.org] *On Behalf Of *Michael StJohns
*Se
On 12/22/2016 3:42 AM, Eliot Lear wrote:
Hi,
This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.
On the one hand, we have a draft that there seems to be unanimous
agreement would be useful to the lighti
On 12/23/2016 3:24 AM, Eliot Lear wrote:
On 12/22/16 11:36 PM, Michael StJohns wrote:
On 12/22/2016 3:42 AM, Eliot Lear wrote:
Hi,
This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.
On the one hand
On 1/13/2017 4:44 AM, Kepeng Li wrote:
Hallo all,
According to the doodle poll, let’s have a call on 14th Feb, GMT 15:00
~ 15:59.
We have the same amount of participants about Option 1, 2, and 4.
Considering that Mike has strong position about this draft, so I
accommodate his choice to allo
I haven't had a chance to comment on the document, but I have a few
comments on the below that will depend on getting the requirements correct.
In the introduction of the document you list three requirements and Jim
has taken you to task for them. There are actually four requirements,
one of
Hi -
This is sort of non-obvious, but one or two articles I read suggest that
RSA 1024 performance may be better than the ECDSA equivalent.
The tradeoff here is obviously the size of the signature and the
transmission thereof, but...
While 1024 bits isn't an ideal security strength for RSA,
ngs are not nails
and can never be made to be nails. This lighting multicast, cheap, low
latency, control system is really not looking like a nail.
Mike
Abhinav
--------
*From:* Ace on behalf of Michael StJohns
*Sent:* We
Hope this helps the discussion.
Thanks
Mohit
On 02/08/2017 04:55 AM, Michael StJohns wrote:
Hi -
This is sort of non-obvious, but one or two articles I read suggest
that RSA 1024 performance may be better than the ECDSA equivalent.
The tradeoff here is obviously the size of the signature
imitations.
Panos
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael StJohns
Sent: Tuesday, February 07, 2017 9:55 PM
To: ace@ietf.org
Subject: [Ace] Asymmetric signature performance
Hi -
This is sort of non-obvious, but one or two articles I read sugges
On 3/6/2017 8:55 PM, Jim Schaad wrote:
After thinking about this for a long time, I will reluctantly state a
position.
I do not believe that the WG should adopt this document at least until
such a time as a version has been released which does a substantially
better job of restricting the s
As I'm sitting in the ACE wig session in Prague I'm struck by the number of
extra-charter documents being reviewed or proposed or in progress. Some
(most?) of these are the specific profiles for given protocols for ace
auth, but reading all of the documents as a whole I get a sense of creeping
fea
On 9/26/2017 9:48 AM, Hannes Tschofenig wrote:
Hi all,
at the last few IETF meetings we had plenty of presentations based on
new document submissions. Our security AD, Kathleen, raised concerns
that many of the presented documents had not seen prior mailing list
discussion.
Hence, the approach
On 9/27/2017 1:29 PM, Kathleen Moriarty wrote:
Goran has a good point here.
Actually - I don't think he does. If there is a sufficiently
interested group of people that want to talk certificate enrollment and
there is a chair available and willing then do an interim on that. If
there is a
efforts on
re-chartering and hold off on all new items including the whole
profiling wiki stuff? At the same time pruning the list of Active and
Related IDs for the group to something manageable?
Mike
Sent from my iPhone
On Sep 28, 2017, at 1:21 PM, Michael StJohns wrote:
On 9
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
Working off of https://www.ieee802.org/secmail/msg00396.html
EUI-MAC-OtherNames-2025 { iso(1) identified-organization(3) dod(6)
internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-eui-mac-othername-00
(tbd0)}
DEFINITIONS
BEGIN
IMPORTS
OTHER-NAME FROM PKIX1Implicit-2009 {
39 matches
Mail list logo
