Re: [6tisch] differential security for CoAP resources

Kris, Some comments inline. Regards, Mališa Vučinić > On 06 May 2015, at 17:34, Kris Pister wrote: > > Mote M has a number of CoAP resources, including temperature and light sensors > coap://M/S/T and /S/L > as well as 6top resources such as slotframes and cells > /6t/6/sf

Re: [6tisch] differential security for CoAP resources

Thomas, > On 07 May 2015, at 06:45, Thomas Watteyne wrote: > > For the distributed CoAPIE case, > https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 > doesn't focus > on security (it's a -00). IMO, there are two options:

Re: [6tisch] security section in minimal

The text seems to capture the compromise. +1 Mališa > On 10 May 2015, at 21:24, Xavier Vilajosana > wrote: > > Dear all, > > after the last call we would like to close the security section in minimal. > We wrapped up all comments from the previous days and from the meeting and > here is ou

Re: [6tisch] security section in minimal

header in the IEEE standard? Regards, Mališa Vučinić ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] questions about draft-richardson-security-6top

> On 12 May 2015, at 12:52, Michael Richardson wrote: > > A power and compute-saving thing for the JCE to do would be to have the > JN provide the JCE with a session-resumption ticket... and for the JCE > to pass that onto the PCE. This seems like a great idea for nodes that may often loose con

Re: [6tisch] Adding CCA to the terminology draft

Hi Maria Rita, The term Joining Node (JN) or Pledge is missing. I would also remove the reference to PCE in the definition of JCE at this point. In the definition of JA, I would also stress that JA emits EBs, used for JN to synchronize to the network. My 5c. Mališa > On 22 Nov 2016, at 12:57

Re: [6tisch] xxx-bootstrap

Hello Peter, My understanding of the IETF 97 meeting outcome is that Phase 1 solution will be anima-compatible i.e., it will provide zero-touch bootstrapping with manufacturer-installed certificate as the start state and locally relevant credential as the end state. At the moment, I believe tha

Re: [6tisch] xxx-bootstrap

omposed of different > standardized parts and where the future evolution is. > Identifying and describing those parts will be a nice step forward. > > Peter > > > Mališa Vučinić schreef op 2016-11-30 10:22: >> Hello Peter, >> My understanding of the IETF 97 meeti

Re: [6tisch] xxx-bootstrap

s global address for the communication to take place. > What about securing a heterogeneous network of which the 6tisch network > happens to be part? The link-layer keys will not be adequate in that case. I don’t understand the use case, could you provide some more details? > Thanks for answerin

Re: [6tisch] xxx-bootstrap

Hi Peter, See inline. Mališa > On 16 Dec 2016, at 09:17, peter van der Stok wrote: > > Hi Malisa, > > Just one point to understand the temporary secure link between JN and JA. > >>> Consequently, that means during the whole bootstrap process the link >>> between JA and JN is not secured by

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt

All, Following the change to markdown, we submitted a version of the minimal-security draft that has *no* content changes, only slight editorial fixes. This was necessary in order to ensure that future versions have a clean diff. A thanks goes to Michael for his help with this transition. Withi

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt

Hello Pascal, Yes, I noted that yesterday and created a ticket at internet-dra...@ietf.org . I have no idea how the tool picked up my former email address, especially because during submission metadata was in order. Hopefully, they will be able to help. Mališa

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-02.txt

All, We have submitted a new version of the minimal security draft reflecting latest work within the security design team. I would like to request a slot to present this version (remotely) during the Chicago meeting. Regards, Mališa > On 12 Mar 2017, at 21:11, internet-dra...@ietf.org wrote: >

Re: [6tisch] EDHOC and EALS use in 6tisch (minimal) bootstrap

+1 on adopting the EDHOC work in ACE. To add to Michael’s summary, I would also like to stress that in draft-ietf-6tisch-minimal-security the one-hop neighbor of a pledge (joining node) plays the role of an untrusted CoAP proxy in order to facilitate pledge’s communication with the Registrar.

Re: [6tisch] Terminology for minimal security

Hi Mohit, Thanks a bunch for going over the draft and the presentation. The “Key” is literally a text string differentiating between a key being derived or an IV. For more details please see Section 3.2.1 of OSCOAP draft or for instance section 7.3 of TLS 1.3 draft. I agree with you that key d

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

All, We have just submitted a new version of the minimal-security draft in preparation for the plugtest that will be held in Prague. This version (-03) will be referenced by the official test description of the plugtest. The most notable changes are: - pledge-initiated EDHOC handshake with opti

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

rds the > message to the JRC. > > Peter > > Mališa Vučinić schreef op 2017-06-15 11:05: >> All, >> We have just submitted a new version of the minimal-security draft in >> preparation for the plugtest that will be held in Prague. This version >> (-03

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

ss of the JRC. > > That makes clearer what goes on. In a first pass of the text, I wondered how > the routing was done. > > Greetings, > > Peter > > Mališa Vučinić schreef op 2017-06-19 15:12: >> Hi Peter, >> I’m missing context on how would that happen.

Re: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

According to RFC8180, Join Priority/Metric is already calculated as a function of the RPL rank. See Section 6.1. My suggestion was to use that as-is *if* the join is allowed by the binary option in this new IE. > On 21 Jul 2017, at 12:44, Michael Richardson wrote: > >> >> I have also a que

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-04.txt

Dear all, We have just submitted a new version of the minimal-security draft that incorporates the changes discussed since the IETF-99 Prague meeting. Namely, the one-touch solution specified in the document now completely relies on PSKs. The new version tracks the changes in the OSCORE-06 spec

[6tisch] Tagging join traffic

At the interim today, we discussed the need of tagging join traffic at the Join Proxy (JP). The problem is that JP forwards into the network traffic that originates from untrusted pledges, which can cause the exchange of 6P commands at intermediate nodes on the path from JP to 6LBR. A maliciou

Re: [6tisch] Tagging join traffic

-to-end? > Trying to see whether there is anything, in the current spec, which allows a > forwarding node to identify join traffic... > Thanks, > Thomas > > On Mon, Nov 6, 2017 at 5:46 PM, Michael Richardson <mailto:mcr+i...@sandelman.ca>> wrote: > > Mališa Vučinić m

Re: [6tisch] pending with 6tisch-minimal-security

Michael, I am missing the benefit of a 5.03 or Pending response for network congestion case when join completes in a single round trip. Why not return a join response that fits into a single frame rather than a signal to attempt later? If there is an error at JRC, we stay silent anyways. I un

Re: [6tisch] nbr cache recommendation

Hi Rahul, Thanks for the pointer. I skimmed through the draft but couldn’t find how relay (JP) or new joinee (pledge) should handle each other before the authentication procedure completes. You state: > Relay element does not hold any state information on behalf of the new joinee > node except

Re: [6tisch] Tagging join traffic

Pascal, Michael, Since data traffic in the network is treated as DSCP class 000, i.e. best effort, it will necessarily have lower priority over all other classes, including class 100 that we decided to use for join with specific AF43 and AF42 codepoints. This means that both AF43 (join request)

Re: [6tisch] Tagging join traffic

Pascal, Yes, it also makes sense from the point of view of an SF, as join is one-shot traffic and we don’t want to allocate cells in response to that, even though the response in the particular case of minimal-security can be trusted. I am arguing that for this particular behavior to be achieve

Re: [6tisch] Tagging join traffic

Pascal, See inline. Mališa > On 1 Dec 2017, at 14:32, Pascal Thubert (pthubert) wrote: > > Certainly Mališa. The reason for a different TC is to treat them differently. > The join response represents an investment of resources in the network and an > acceptance by the JRC (so it's not an att

Re: [6tisch] Tagging join traffic

> On 1 Dec 2017, at 16:10, Pascal Thubert (pthubert) wrote: > > [Pascal] I'm not sure that the join and the response should have the same > precedence. In a forming network there may be a bunch of both and the > responses should win in case of a collision in a node's buffer. Conversely > I'm

Re: [6tisch] Tagging join traffic

downwards packets could be induced by an attack. With that, I don’t see the need of differentiating between upward and downward. Should it all be tagged with AF43? Mališa > On 1 Dec 2017, at 19:07, Michael Richardson wrote: > > > Mališa Vučinić wrote: >> Since data traffic

Re: [6tisch] Tagging join traffic

So should we stick to AF4x or switch to a lower value? Mališa > On 5 Dec 2017, at 02:05, Michael Richardson wrote: > >> >> - Any particular reason why you chose class 100 i.e. (AF43 and AF42) >> and not any other class from RFC2597? > > I believed at the time that AF1x would have priority ove

[6tisch] Fwd: New Version Notification for draft-chang-6tisch-msf-01.txt

All, We submitted a new version of the Minimal Scheduling Function, resolving the issues raised during the two reviews received since IETF 100. Changelog: - When neighbor is unreachable, sending a CLEAR command was a MUST, now a MAY. - Fixing 6P Timeout calculation. - Clearer text for "Handling

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-05.txt

All, I have just submitted a new version of the minimal-security draft. We will be asking for WGLC on this version in London. Changelog: - Introduced tagging of join traffic. This resolution mitigates the vulnerability where the attacker could inject join requests in the network and intermedi

[6tisch] v1.0.0 Release of the 6TiSCH Simulator

All, We've just released v1.0.0 of the 6TiSCH simulator, a tool to answer what-if questions through quick performance estimation. This is a high-level Python-based simulator implementing: - protocols - IEEE802.15.4e-2012 TSCH ( http://standards.ieee.org/getieee802/download/802.15.4

[6tisch] Updates to minimal-security-06

All, We had a couple of side discussions during IETF 101 on the updates to the minimal security draft. We need to (1) support extensibility to allow future specs to add additional parameters to the join response structure, and it seems that (2) we can cover link-layer rekeying easily through the u

Re: [6tisch] Updates to minimal-security-06

On Thu, Mar 22, 2018 at 5:03 PM peter van der Stok wrote: > > > One doubt I have is how does the JRC send the Observe response to the > > joined node, when the request came over a Join Proxy. Essentially, the > > JRC needs to send the response to the global IPv6 address of the > > joined node, th

Re: [6tisch] Updates to minimal-security-06

On Thu, Mar 22, 2018 at 5:42 PM peter van der Stok wrote: > > No semantic difference that I know. You expressed a worry about > addressing the joining node from JRC. > Not sure any more, but do you use the IP-in-IP proxy? If yes, > maintaining the encapsulation in all following traffic seems nece

Re: [6tisch] Updates to minimal-security-06

On Thu, Mar 22, 2018 at 5:39 PM Michael Richardson wrote: > > Mališa Vučinić wrote: > > in the network. Other than adding the Observe option, together with > the > > new link-layer key we also need to carry the ASN at which this key is > > scheduled

Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

Hi Christan, Thanks for your response and apologies for the slow follow up. See inline. Mališa On Mon, Mar 26, 2018 at 10:42 AM Christian M. Amsüss wrote: > Hello Mališa, > > On Fri, Mar 23, 2018 at 10:12:16AM +0000, Mališa Vučinić wrote: > > I am tempted to say that this does

Re: [6tisch] Updates to minimal-security-06

ACK'ed, i.e. does the JRC know it got received? > Moving the discussion about the rekeying mechanism to the thread: *Rekeying for minimal-security (was: Updates to minimal-security-06).* > > Thomas > > On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson < > mcr+i...@sand

[6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

See inline. On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne wrote: > > *About COSE_Key* > > The issue raised is that, during a rekey of key K2 by the JRC, the JRC > cannot specify an ASN from which the new key is to be used. > The JRC would need to guess how long it may take for it to reach eve

[6tisch] Optimizing Neighbor Discovery during the join process

All, We had a couple of side discussions regarding Neighbor Discovery (ND) in minimal-security draft. The problem is that with the current text in minimal-security and the ND exchange between the pledge and the JP, we double the communication overhead on the shared cell and require the JP to keep

Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

Christian, See inline. Mališa On Thu, Apr 12, 2018 at 3:15 PM Christian M. Amsüss wrote: > > > What would be the advantage of establishing a dynlink over specifying in > > the minimal-security draft that once the pledge joins, it needs to > expose a > > /j resource that the JRC may use to upda

Re: [6tisch] Optimizing Neighbor Discovery during the join process

On Wed, 18 Apr 2018 at 18:19, Michael Richardson wrote: > > Mališa Vučinić wrote: > > We had a couple of side discussions regarding Neighbor Discovery > > (ND) in minimal-security draft. > > > The problem is that with the current text in minimal-security

Re: [6tisch] Optimizing Neighbor Discovery during the join process

On Wed, 18 Apr 2018 at 19:17, Michael Richardson wrote: > > > Yes, I guess you could call it an ephemeral cache entry > > constructed by CoAP at JP when the join response is received, > > before being forwarded to the pledge. As soon as the packet is > > passed to L2, the cache en

Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

(I just realized that I forgot to CC the 6tisch ML for the previous exchanges.) See below. On Thu, Apr 19, 2018 at 10:55 AM Christian M. Amsüss wrote: > Hi Mališa, > > On Thu, Apr 19, 2018 at 08:24:57AM +0000, Mališa Vučinić wrote: > > I agree that sending the path exposed at t

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael, Reviving the discussion on the rekeying mechanism. See below. Mališa >> On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson < >> mcr+i...@sandelman.ca> wrote: >> >>> >>> >>> I'd say that you always do this with any new key if you have no keys. >>> I don't think we need a flag. >>> >>>

Re: [6tisch] Optimizing Neighbor Discovery during the join process

Pascal, If we were to use the unspecified address, would the following be OK: - Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2 source: pledge EUI; L3 destination: JP EUI from the Beacon - Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2 source: JP EUI; L2 dest

Re: [6tisch] Optimizing Neighbor Discovery during the join process

JP needs to do a NS look up. > > > > Also, I do not necessarily agree that the ND phase is that expensive. It > is just a one-hop exchange. > > > > Cheers, > > > > Pascal > > > > *From:* Mališa Vučinić > *Sent:* jeudi 19 avril 2018 15:32 >

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

maps everywhere and extensive overhead. If you have any better idea how to add support for other keying modes of 802.15.4, let me know. Feedback is welcome, I am continuing with the work on the rekeying mechanism that we discussed. Mališa On Tue, Apr 24, 2018 at 11:06 PM Michael Richardson wro

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael, See inline. Mališa On Thu, May 10, 2018 at 8:05 PM Michael Richardson wrote: > > I see that you have an IANA registry for the Join Request and Join Response > key values. These tables need to have names and the IANA instruction needs > to ask them to create the tables, and then to po

Re: [6tisch] On minimal-security

Thanks for this review, Pascal. I went quickly through your comments and I should be able to fix all of this for -06. My goal is to have -06 ready for WGLC. On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Mališa > > > > As you are getting ready to pu

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

On Tue, May 15, 2018 at 8:54 PM Michael Richardson wrote: > > > > I generalized the rekeying text so that it falls under the > processing rules > > of the CBOR Link-Layer Key parameter. The first join of a pledge just > > becomes a special case but there is a distinction between the 6

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

from the key length, I also added the nonce length in the description of the algorithm in the registry. Mališa On Tue, May 15, 2018 at 11:47 PM Tero Kivinen wrote: > Mališa Vučinić writes: > > I also worked out a new key signaling mechanism using a "key usage" > parameter, &

[6tisch] A terminology issue in minimal-security: (6LBR) pledge

All, With the latest developments on minimal-security-06, we have homogenized the join protocol so that it equally applies to regular pledges and the 6LBR device. Essentially, 6LBR just sets some parameters differently in the request, and it receives the keys, network prefix and PAN ID of the netw

Re: [6tisch] On minimal-security

Hi Pascal, See responses inline. Mališa On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Mališa > > > > As you are getting ready to publish a next rev, please find simple > comments on 05 that you may want to act upon in 06. > > > > ·As ment

Re: [6tisch] On minimal-security

Michael, I am not sure I follow. How come is it not the case that this well-known host name is resolved to an IP address? When JP receives a first DIO and learns the DODAG root’s IPv6, it stores the IP address as the resolution of 6tisch.arpa. Same thing when it learns the JRC’s IPv6 through the

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

@Tero, Getting back to this, see inline. On Thu, May 17, 2018 at 12:36 AM Tero Kivinen wrote: > Mališa Vučinić writes: > > Thanks Tero for this feedback! Could you check if this commit takes care > of > > it: > > > > > https://bitbucket.org/6tisch/draft-iet

Re: [6tisch] On minimal-security

@Michael, @Christian I am re-reading RFC7252, Section 5.7.2: Unless a proxy is configured to forward the proxy request to another proxy, > it MUST translate the request as follows: the scheme of the request URI > defines the outgoing protocol and its details (e.g., CoAP is used over UDP > for the

Re: [6tisch] Updates to minimal-security-06

All, I resolved the issues we had open on minimal-security and reworked editorially the document quite heavily. Since the protocol we define is quite generic, I renamed it to "Constrained Join Protocol (CoJP)", suggested pronunciation as "cojeep". Let me know if you dislike the new name, or if you

Re: [6tisch] On minimal-security

On Thu, 24 May 2018 at 20:44, Michael Richardson wrote: > > Mališa Vučinić wrote: > > @Michael, @Christian > > > I am re-reading RFC7252, Section 5.7.2: > > okay, but I'm not claiming that the Join Proxy is a CoAP Proxy by the rules > given in 7252.

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-06.txt

All, As per the discussions last weeks, I submitted the -06 version of the minimal-security draft. This -06 version will be used for the F-Interop 6TiSCH plugtest to be held in Paris on 26-27 of June. Kind regards, Mališa On Fri, May 25, 2018 at 7:23 PM wrote: > > A New Internet-Draft is ava

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

Hi Jim, Thanks a million for going through the document. Regarding the problem you outline where the pledge first joins to JRC1 and then later to JRC2, this would correspond to the change of ownership of the pledge, without going through the trouble of re-provisioning the pledge with a new PSK/se

[6tisch] Fwd: Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages

Forwarding this review to the ML as part of the WGLC. -- Forwarded message - From: William Vignat Date: Tue, Jul 3, 2018 at 3:03 PM Subject: Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages To: draft-ietf-6tisch-minimal-

Re: [6tisch] WGLC on the “Minimal Security Framework for 6TiSCH” document

Hello Göran, Thanks for the review. See my responses inline. Mališa On Wed, Jun 27, 2018 at 3:46 PM Göran Selander wrote: > Dear WG, Pascal, Thomas, > > I have reviewed draft-ietf-6tisch-minimal-security-06 and have the > following feedback: > > > > Section 3 > > > "pledge identifier" > > > T

Re: [6tisch] preliminary 6TISCH@IETF102 agenda

Hi Thomas, Pascal, For the minimal-security slot, if possible, I would need an additional 5-10 minutes. We received lots of good reviews and I would like to get input on some of the issues during the meeting. Let me know if feasible. Mališa On Tue, 3 Jul 2018 at 14:28, Thomas Watteyne wrote:

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

Hi Tero, Thank you for this extensive review! See my responses inline. Mališa On Thu, Jun 28, 2018 at 12:24 AM Tero Kivinen wrote: > In section 3 there is text saying: > >The "network identifier" uniquely identifies the 6TiSCH network in >the namespace managed by a JRC. Typically, thi

Re: [6tisch] comments to the “Minimal Security Framework for 6TiSCH” document

Hi Xavi, Many thanks for sending this review. See my responses inline. Mališa On Fri, Jun 29, 2018 at 5:37 PM Xavi Vilajosana Guillen wrote: > Hi, > > I reviewed the ”Minimal Security Framework for 6TiSCH” document. > > Here some comments that have not been mentioned by others. > > 1) I miss s

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

Hi Tengfei, Thanks for your review! See my responses and proposed resolutions inline. Mališa On Mon, Jul 9, 2018 at 3:44 PM Tengfei Chang wrote: > Hi Malisa, > > I just reviewed the draft and have several comments below. > > *Comment 1: * > *--* > In section 9.3.2 when desc

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

. Each update of the OSCORE Replay Window MUST be written to persistent memory. In the text above, there is a typo: s/Section 6.5.1/Section 7.5.1 Let me know if I am missing something else to add regarding this. Mališa On Tue, Jul 10, 2018 at 3:20 PM Jim Schaad wrote: > > > > &

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

(snip) On Tue, Jul 17, 2018 at 10:13 PM Tero Kivinen wrote: > > I would like at least some text in the security considerations section > warning about the common wrong ways of generating PSK. The IoT vendors > are quite often care more about the time to market than the security, > thus do use un

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

On Wed, Jul 18, 2018 at 2:36 AM Tengfei Chang wrote: > Hi Malisa and Tero, > > Thanks for answering my question! It is clear to me! > > I don't fully understand. Do you mean in which case would a node send >> another Join Request, if it has already completed the join process sometime >> before an

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

On Tue, Jul 17, 2018 at 10:25 PM Tero Kivinen wrote: > If JRC restarts and looses track who is in the network, then it cannot > send updaes, as it does not know who is in the network. I.e., in that > case all nodes need to rejoin. > How do we detect that JRC restarted at 6LBR if JRC is in the Cl

Re: [6tisch] Review of draft-ietf-6tisch-minimal-security-06

Hi Klaus, Your email somehow ended up being classified as Spam by Google's filter and I found it only after explicitly searching for it in the Spam folder. As discussed offline, we are happy in 6tisch to make this functionality useful for the general-purpose CoAP in collaboration with CoRE. Let'

Re: [6tisch] Link_Layer_Key

Tero, Thanks Tero for the proposal. Is the current "key_usage" registry enough to fully configure the security tables for the non-index modes? When a pledge/node receives a Link_Layer_Key corresponding to KeyIdMode 2, how does it know which other node to use it for? i.e. I want to encrypt data to

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

nts to update the > endpoint. > > > > Jim > > > > > > *From:* Mališa Vučinić > *Sent:* Tuesday, July 17, 2018 1:22 PM > > > *To:* Jim Schaad > *Cc:* 6tisch@ietf.org > > *Subject:* Re: Review draft-ietf-6tisch-minimal-security > > > &g

Re: [6tisch] Link_Layer_Key

Thanks for the clarification. I still have a couple of misunderstandings, see inline. Mališa On Thu, Jul 19, 2018 at 12:47 AM Tero Kivinen wrote: > Mališa Vučinić writes: > > Thanks Tero for the proposal. Is the current "key_usage" registry enough > to > > fully c

Re: [6tisch] 6tisch minimal -- when can/should JP throw-away/blacklist pledges?

Michael, See inline. Mališa On Fri, Jul 27, 2018 at 12:04 AM Michael Richardson wrote: > > (Listening to the youtube recording) > > Tero clarified the slide 8, about when the JP could throw away the > neighbour > state, and whether or not the JP could blacklist a pledge. > > The JP is not enti

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

ublic after a while anyway and thus leaking it would not be a huge > problem. Depending on value of the data, the JRC could generate new data > for the message to the pledge. > > > > Jim > > > > > > *From:* Mališa Vučinić > *Sent:* Wednesday, July 18, 201

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

Hi Tero, Just getting back to this after my vacation, see inline. Mališa On Fri, Jul 27, 2018 at 8:25 PM Tero Kivinen wrote: > Mališa Vučinić writes: > > > > The question now is when to remove the entry with secExempt for > > pledge at JP, once it was installed from Stat

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

On Fri, Sep 7, 2018 at 6:30 PM Tero Kivinen wrote: > Mališa Vučinić writes: > > Yes, I think it can be made to work, but I think it is quite a lot of > > work and code just to be able to claim to be "stateless". > > > > I don't quite agree that w

[6tisch] WGLC issues to be addressed for minimal-security-07

Dear all, I converted the extensive email and F2F discussions during the last two months around the minimal-security draft into a list of issues to be resolved. The list with relevant email discussion snippets is at: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?status=wo

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

Dear WGLC reviewers, working group, We submitted a new version of minimal security incorporating the resolution of most of the issues raised during WGLC. There are two remaining issues that still need to be resolved, and I hope to publish these in an additional version after the draft submission c

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

2 use the updated reference to RFC 8174 >2. In section 4 – You might want to make it explicit as one of the >item that the pledge identifier is provisioned. > > > > *From:* Mališa Vučinić > *Sent:* Tuesday, October 23, 2018 7:07 AM > *To:* Göran Selander ; Xavi

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

Hi Göran, Thanks for the feedback and the proposal. I added Appendix B detailing this deployment option: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b93e8fa6152eb2bb10761264bcf8e47f861fd418 Let me know if the current text works for you. Also, regarding the comment t

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-08.txt

Dear all, We have just submitted version -08 of minimal-security resolving, to our knowledge, last remaining issues raised during the WGLC. I will discuss *some* of these resolutions tomorrow during the IETF 103 presentation but for completeness, please go ahead and take a look at the document be

[6tisch] Updates for minimal-security-09

Hi all, As discussed during IETF 103, here is a list of proposed changes for minimal-security-09 that we will use for the second WGLC: - Add "join rate" parameter in the Configuration structure present in Join Responses and Parameter Update requests: As discussed during IETF 103, allowing the JRC

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-09.txt

Dear all, We submitted the -09 version of the minimal-security draft, incorporating the changes discussed during IETF 103 and summarized in the "Updates for minimal-security-09" ML thread: - Adding optional join rate parameter to Join Response. This enables JRC to manage JPs. - Aligning normative

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Hello Pascal, Here are my comments on draft-ietf-6tisch-architecture. I used the latest version of the draft hosted on bitbucket. In general, an editorial pass on the whole document would be useful, there are some typos here and there. The main issue I see is that Section 6.1 is completely outdate

Re: [6tisch] POST WGLC: draft-ietf-6tisch-architecture-18.txt

Hello Pascal, Michael, I just opened a pull request on bitbucket rewriting the join process description. The PR is at: https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/pull-requests/1/update-join-process-description/diff Could you take a look and if you agree, refine further. Mališa

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Hello Pascal, Most of the resolutions to my comments look good. Couple of nits inline. Mališa *[PT>] *I think we need to define an entry for CoJP, similar to 6P. What > about; > >CoJP (Constrained Join Protocol): CoJP is a one-touch join protocol > >defined in the Minimal Se

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Thanks Pascal, looks good! Mališa On Wed, Dec 12, 2018 at 1:51 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Mališa > > > > Please see below ( I pushed the result in the repo, please let me know if > we are OK now ) > > > > *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf

Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

Dear Göran, Many thanks for the review! As we discussed during the WG meeting, I added new text in the draft to stress that the procedure in Appendix B.2 of OSCORE should be used in the case of a failure event occurring at the JRC. The use of this procedure is now RECOMMENDED, and in case it is

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

Hello Christian, Thank you for summarizing the discussion we had and proposing these changes. I have modified the text in order to reflect the email below by: - encoding additional info as a CBOR array allowing multiple parameters to be transported within - removing the previous error code which

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

Hello Christian, The intent was indeed to differentiate between “I cannot do what is requested with parameter X” and “I understand parameter X but not what you are asking me to do with it”. To avoid ambiguity, I now use the terms “unsupported” and “malformed” as code values. Essentially, along

Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

ecified". > > Göran > > On 2019-03-27, 23:16, "Mališa Vučinić" wrote: > >Dear Göran, > > >Many thanks for the review! As we discussed during the WG meeting, I added > new text in the draft to stress that the procedure in Appendix B.2 of OSCO

Re: [6tisch] [Secdispatch] EDHOC Summary

+1 We are happy to contribute to this effort through feedback on the design, implementation for constrained devices and its evaluation in 6TiSCH networks. Mališa > On 30 Mar 2019, at 18:31, Thomas Watteyne wrote: > > The 6TiSCH WG has produced a set of documents [1,2] that specify the use of

[6tisch] Progress zero-touch document

Michael, all, With the EDHOC specification finally seeing progress (see [1]), it seems like a good time to restart the work on zero touch and progress the adopted working group document. Reading the current version of draft-ietf-6tisch-dtsecurity-zerotouch-join-03, it seems that there are many

Re: [6tisch] Progress zero-touch document

Hello Pascal, Are you suggesting that we should start working out the details on using EDHOC but keep an alternative as an appendix in the document? Since we have stalled on this work for some time for reasons outside of the working group control, I think it would make sense to catch up.. Let

Re: [6tisch] Progress zero-touch document

How about we form a focused design team to start working out the details and we can do the editorial work and publish once the EDHOC decision is out? Mališa > On 2 Apr 2019, at 17:04, Michael Richardson wrote: > >> >> What are your thoughts on this? > > If you want to start now, please go ah

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

Should be covered in https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2 Mališa > On 4 Apr 2019, at 16:04, Michael Richardson wrote: > > I was looking for some text from 6tisch-minima

  1   2   >