ioned that he likes draft-tiloca-ace-oscoap-joining-00.txt
but not
draft-somaraju-ace-multicast<https://tools.ietf.org/html/draft-somaraju-ace-multicast>.
This was rather surprising since
draft-somaraju-ace-multicast<https://tools.ietf.org/html/draft-somaraju-ace-multicast>was
w
Hi Hannes,
Thanks for the warm welcome!
See inline my comments...
Stevie
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Thursday, October 19, 2017 8:02 AM
> To: ace@ietf.org
> Subject: [Ace] multicast
>
> Hi all,
>
> During the ACE
Hi Stefan,
I am trying to understand your ideas.
~snip ~
> For multicast, my focus is on using asymmetric encryption for
authentication & integrity, and using symmetric encryption for
confidentiality.
In your view, you are sending a multicast message that will contain a digital
signature and i
Yes, correct.
Stevie
> -Original Message-
> From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
> Sent: Thursday, October 19, 2017 2:52 PM
> To: Beck, Stefan ; ace@ietf.org
> Subject: RE: multicast
>
> Hi Stefan,
>
> I am trying to understand your ideas.
>
> ~snip ~
>
> > For m
Hi,
"Beck, Stefan" writes:
[snip]
> even supporting the "low-latency" requirements we need, also considering the
[snip]
Could you provide some more concrete numbers for your definition of
"low-latency" requirements?
Thanks,
-derek
--
Derek Atkins 617-623-3745
d
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 t
;decrypt the
message) should not exceed ~200 ms.
Stevie
> -Original Message-
> From: Derek Atkins [mailto:de...@ihtfp.com]
> Sent: Thursday, October 19, 2017 3:51 PM
> To: Beck, Stefan
> Cc: Hannes Tschofenig ; 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
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
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
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 ; ace@ietf.org
>
No problem. Take your time.
Ciao
Hannes
-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Beck, Stefan
Sent: 19 October 2017 22:15
To: ace@ietf.org
Subject: Re: [Ace] multicast
As mentioned in yesterday's call: give me/us some more time to work it out
Hi Stevie,
"Beck, Stefan" writes:
> Hi Derek,
>
> The requirement roughly is:
> Assume a few light switches as multicasters and many luminaires as listeners
> - turning lights on / off via multicast
> The end-2-end processing (multicaster to encrypt&sign the message, the
> network to transmit th
Hannes Tschofenig wrote:
> Hi Stefan,
> I am trying to understand your ideas.
> ~snip ~
>> For multicast, my focus is on using asymmetric encryption for
> authentication & integrity, and using symmetric encryption for
> confidentiality.
> In your view, you are send
Why restriction on reading messages? It is not like an external observer is
not going to be able to see the lights go on or off.
I am not sure what you mean by synchronous manner. Does this mean that the
light needs to change state between the command and the response message?
(As opposed to an
Hi Jim,
thank you for the review and I apologise for the delayed response - I was on
sick leave due to a surgery. Please see comments inline from the authors.
Why restriction on reading messages? It is not like an external observer is
not going to be able to see the lights go on or off.
[AS] T
See comments inline
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Somaraju Abhinav
Sent: 02 February 2017 03:48
To: Jim Schaad ;
draft-somaraju-ace-multic...@tools.ietf.org
Cc: 'ace'
Subject: Re: [Ace] draft-somaraju-ace-multicast
Hi Jim,
thank you for the re
Why restriction on reading messages? It is not like an external observer is
not going to be able to see the lights go on or off.
[AS] There are several situations where lights are not visible but (multicast)
network data is accessible. Moreover, sensors (e.g. presence detectors) are
continuous
-ace-multic...@tools.ietf.org
Cc: 'ace'
Subject: RE: [Ace] draft-somaraju-ace-multicast
See comments inline
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Somaraju Abhinav
Sent: 02 February 2017 03:48
To: Jim Schaad ;
draft-somaraju-ace-multic...@tools.ietf.org
Cc: 'ace'
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
See Below
From: Somaraju Abhinav [mailto:abhinav.somar...@tridonic.com]
Sent: Monday, February 6, 2017 12:01 PM
To: Jim Schaad ;
draft-somaraju-ace-multic...@tools.ietf.org
Cc: 'ace'
Subject: Re: [Ace] draft-somaraju-ace-multicast
Jim, All,
please see a propos
Comment inline
From: Somaraju Abhinav [mailto:abhinav.somar...@tridonic.com]
Sent: Monday, February 6, 2017 12:01 PM
To: Jim Schaad ;
draft-somaraju-ace-multic...@tools.ietf.org
Cc: 'ace'
Subject: Re: [Ace] draft-somaraju-ace-multicast
Jim, All,
please see a propos
See inline
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Somaraju Abhinav
Sent: Thursday, February 9, 2017 2:47 AM
To: Jim Schaad ;
draft-somaraju-ace-multic...@tools.ietf.org
Cc: 'ace'
Subject: Re: [Ace] draft-somaraju-ace-multicast
Comment inline
From: Somara
Moreover, because the group key is shared across multiple nodes, it may be
easier for an attacker to determine the group key by attacking any member of
the group (note that this group key is dynamically generated and is usually
stored in volatile memory which offers some additional protection).
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 lighting people. On the other hand, we
have some c
On 22 Dec 2016, at 09:42, Eliot Lear wrote:
>
> I would like to see this draft adopted by the working group, an
> appropriate applicability statement added, and see it shipped.
+1
(Everything has been said already that needs to be said about the issue.)
Grüße, Carsten
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/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, we have a draft that th
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,
We continue to go in circles on this despite efforts to mitigate or warn of
risks and agreement to put forth an asymmetric key solution at the same
time. This continued DoS on this topic is serving no purpose but to delay
vendors or send them elsewhere when they are here in ACE looking for
assista
security
break with these solutions .
Happy holidays to all!
Don Sturek
From: Ace on behalf of Kathleen Moriarty
Date: Saturday, December 24, 2016 at 8:19 AM
To: Michael StJohns
Cc: Eliot Lear , "ace@ietf.org"
Subject: Re: [Ace] where are we with draft-somarju-ace-multicast?
W
er 24, 2016 at 8:19 AM
> To: Michael StJohns
> Cc: Eliot Lear , "ace@ietf.org"
> Subject: Re: [Ace] where are we with draft-somarju-ace-multicast?
>
> We continue to go in circles on this despite efforts to mitigate or warn of
> risks and agreement to put forth an as
Hello all,
This note begins a Call For Adoption for draft-somaraju-ace-multicast-02 [1]
to be adopted as an ACE working group item, and added in the charter. The
call ends on Mar 7, 2017.
Keep in mind that adoption of a document does not mean the document as-is is
ready for publication. It is
uot; mailto:Ace@ietf.org>>
Cc: Kathleen Moriarty
mailto:kathleen.moriarty.i...@gmail.com>>,
Hannes Tschofenig mailto:hannes.tschofe...@gmx.net>>
Subject: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
Hello all,
This note begins a Call For Adoption for draft-somaraj
of Li Kepeng
日期: Thursday, 23 February 2017 at 5:48 PM
至:
抄送: Kathleen Moriarty , Hannes
Tschofenig
主题: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
Hello all,
This note begins a Call For Adoption for draft-somaraju-ace-multicast-02 [1]
to be adopted as an ACE working gr
] Call for adoption for draft-somaraju-ace-multicast-02
I’m in favour of adopting a profile of the ACE framework [1] providing the
functionality outlined in this draft.
It was acknowledged in the latest ACE interim that this draft will be
transformed into an ACE profile, but currently the mapping to
WG then
decides to relax that scope so be it.
Jim
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Kepeng Li
Sent: Thursday, February 23, 2017 1:48 AM
To: Ace@ietf.org
Cc: Kathleen Moriarty ; Hannes Tschofenig
Subject: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
to be solved. If
the WG then decides to relax that scope so be it.
Jim
FROM: Ace [mailto:ace-boun...@ietf.org] ON BEHALF OF Kepeng Li
SENT: Thursday, February 23, 2017 1:48 AM
TO: Ace@ietf.org
CC: Kathleen Moriarty ; Hannes
Tschofenig
SUBJECT: [Ace] Call for adoption for draft-somaraju-ace-mult
+1.
On 3/7/17 9:33 AM, peter van der Stok wrote:
> After reading Jim's statement, my position is a bit different.
> Multicast security is severely needed.
> Not making it a WG document augments the risk that the subject is
> frozen and no progress is made.
> To guarantee progress, adoption seems
nk-layer standards).
Mike
*From:*Ace [mailto:ace-boun...@ietf.org] *On Behalf Of *Kepeng Li
*Sent:* Thursday, February 23, 2017 1:48 AM
*To:* Ace@ietf.org
*Cc:* Kathleen Moriarty ; Hannes
Tschofenig
*Subject:* [Ace] Call for adoption for draft-somaraju-ace-multicast-02
Hello all,
This note be
On 7 Mar 2017, at 02:55, 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
>
Peter,
peter van der Stok writes:
> After reading Jim's statement, my position is a bit different.
> Multicast security is severely needed.
> Not making it a WG document augments the risk that the subject is
> frozen and no progress is made.
> To guarantee progress, adoption seems to me the righ
Hi Derek
we discussed the requirements quite a bit in the group already and the
conclusion of the discussion was that we provide two solutions, one
based on symmetric keys and the other based on asymmetric keys.
The asymmetric key solution provides authentication of the individual
sender where th
chaad ; 'Kepeng Li' inc.com>; consulta...@vanderstok.org; Ace@ietf.org
> Subject: Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
>
> Hi Derek
>
> we discussed the requirements quite a bit in the group already and the
> conclusion of the discussion
adoption for draft-somaraju-ace-multicast-02
>
> After reading Jim's statement, my position is a bit different.
> Multicast security is severely needed.
> Not making it a WG document augments the risk that the subject is frozen
> and no progress is made.
> To guarantee p
Hello Kepeng, all,
I support the adoption of draft-somaraju-ace-multicast-02 as an ACE working
group draft.
There was some discussion whether the scope and requirements are clear enough.
Perhaps adding dedicated "scope" and "requirements" sections early in the draft
could
+1
Stevie Beck
From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Dijk, Esko
Sent: Wednesday, March 08, 2017 11:38 AM
To: ace@ietf.org
Subject: Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02
Hello Kepeng, all,
I support the adoption of draft-somaraju-ace
Dear CoRE and ACE,
Apologies for cross-posting, this concerns the security for CoAP group
communications (which is a CoRE draft) and the current specified method to
retrieve public keys for group communication (which is an ACE draft).
When a node joins a group [0] there is a need for group mem
48 matches
Mail list logo
