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
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
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
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
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
.
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 suggest that RSA
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 and the
transmissi
nd 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 <ace-boun...@ietf.org> on behalf of Michael StJohns
<
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
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 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
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
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
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 control
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 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
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.
17 matches
Mail list logo
