Minutes interim-2020-core-08: Thu 16:00
minutes-interim-2020-core-08-202009101600-00
Meeting Minutes | Constrained RESTful Environments (core) WG | |
---|---|---|
Date and time | 2020-09-10 14:00 | |
Title | Minutes interim-2020-core-08: Thu 16:00 | |
State | Active | |
Other versions | plain text | |
Last updated | 2020-09-10 |
minutes-interim-2020-core-08-202009101600-00
# CoRE Virtual interim - 2020-09-10 - 14:00 UTC Chairs: * Marco Tiloca, RISE * Jaime Jiménez, Ericsson ## Remote instructions material: https://datatracker.ietf.org/meeting/interim-2020-core-08/session/core webex: https://ietf.webex.com/ietf/j.php?MTID=mb93d5310059df95f1f25734c1b973f5d jabber: core@jabber.ietf.org codimd: https://codimd.ietf.org/notes-ietf-interim-2020-core-08-core Minute takers: Jim, Marco and Jaime (helping) Jabber scribes: Jaime ## Participants 1. Marco Tiloca, RISE 2. Jaime Jiménez, Ericsson 3. Jim Schaad, August Cellars 4. Rikard Höglund, RISE 5. Francesca Palombini, Ericsson 6. Carsten Bormann, TZI 7. Göran Selander, Ericsson 8. Christian Amsüss 9. Peter Yee, AKAYLA 10. Thomas Fossati, arm 11. Michael Richardson, Sandelman Software Works *[MT]: Marco Tiloca *[JJ]: Jaime Jiménez *[JS]: Jim Schaad *[FP]: Francesca Palombini *[CB]: Carsten Bormann *[CA]: Christian Amsüss *[KH]: Klaus Hartke *[RH]: Rikard Höglund *[TF]: Thomas Fossati *[DN]: David Navarro *[GS]: Göran Selander ## Agenda ### Note Well Remember that the [note well](https://datatracker.ietf.org/submit/note-well/) applies, for [IPR](https://tools.ietf.org/html/bcp79) but also for [WG processes](https://tools.ietf.org/html/bcp25) and [code of conduct](https://tools.ietf.org/html/bcp54). Try to be nice. ### CoRE Resource Directory and received IESG comments - [CA] - Addressed comments - Comments with concrete action plans - Open points and plan to address them - Oddities in examples - "Default" model - first-come-first-served - configured EP names - ... but not going by items by that structure, but by importance of working group feedback - Priorities are assigned from WGF-9 to WGF-0 in - https://github.com/core-wg/resource-directory/issues?q= - https://github.com/core-wg/resource-directory/blob/master/point-to-point-responses.md - Possibly actionable outside document - DTLS retransmission - Related documents - https://tools.ietf.org/html/draft-ietf-core-resource-directory - **Issue # 254 - Propose one fallback / default security module** [CA] Describe the set of possible answers where you match the "identifier" on the registration to information extracted from the security context. [JS] If especially using the OSCORE profile, one can go for the subject claim, or the PSK, or an AS-assigned identifier of the CWT. [CA] Being asked to provide a minimal default behavior that people could be using [CB] Not sure that I understand the list. Establishing some defaults to ensure that the identity hasn't changed? [CA] Yes - doing some actions like changing self-signed certificates would cause a different naming. [CB] Host name or subject identifier is a natural candidate - otherwise tie to the key if that does not exist. [CA] Tied to the key means the most general key in that context? In case of LAKE use the authentication public key not the derived session key. [JJ] Wondering about keeping application level stuff such as observations [CA] No that would be separate - **Issue WGF-9 Are we aligned on "don't just blindly POST empty stuff with your permission unless you're sure the server is what you think it is?" otherwise respond "depends too much on the non-RD application's policies that we could make any more precise statement"** [CA] How much should there be a dependency on untrusted RD, and thus the application needs to do verification, vs the RD is trustworthy. [CA] Dealing with target attributes, such as content format. These are hints, so cannot every be completely wrong. Resource types are different in that they describe operations that can be done. Example of starting a port scan from a different device has been on list. Re-verification could be done by asking the referred to decide for it's well-known/core to double check the answer that was received from the RD. [JJ] Are we over defining this behavior? [CA] Maybe yes. [CB] Things come to mind - Aspect of trust for RD is that it does not suppress registrations. Whether you trust it or not may be of importance. What type of liability is implied here by trust. Does the RD know that what it is told is truth? [CA] RD only accepting statements about links that client is authorized to be authorative on. [CB] For all security models or just this one? [CA] Only for this one. Describing to implementers when this policy is relevant. Used in cases where RD is expected to have only authorative information. [JJ] Is this only public key cases - for certificates? [CA] This would require some form of authentication using certificates. For instance if the entity doing the registration is acting on behalf of the server, so the certificate becomes part of the link setup. [JJ] Implies that client can only register things about itself. [CA] Yes, you can go for that model. But how much should we go into details in a useful way for implementers? - **Issue WGF-9 - Any deployment of simple? Otherwise, /.well-known/rd would be fine with me** [CA] Ben is not happy with assigning a new behavior to a registered well-known resource. Are we aware of any implementations in the wild that support this? [JJ] Not in LwM2M. [CA] Leaning to use of a new different resource. [CA] This is about the issue of posting to /.well-known/core [CB] Yeah, that is weird. Add a note to the document that previous version of the document used this old resource - **Issue WGF-8 - What, that's optional and CoAPS does not pull it in?** [CA] Who would expect a DTLS implementations for CoAP to do replay protection? [JS] Of what? [CA] Previously sent messages. [JS] Definitely. [CA] Optional in DTLS. We can say it has to be enabled, or do a quick update to CoAP about turning on the replay protection. [JJ] Really need to make replay protection mandatory. [CB] Anything in RFC 7925? [TF] No mandatory replay protection in RFC 7925. [JJ] It should really be mandatory. [CA] So we add it to the RD and hope it gets picked up. [JJ] May also be a feedback to be sent to other drafts/groups. [TF] Sure, will do. - **Issue WGF-8 - Who's keeping the exmple in here? also GENERIC-ODDEXAMPLES** [CA] This is about examples, thinking of what LwM2M is doing, some terms (irrelevant?) are not really explained. [JJ] Yeah, some are not relevant, I can look for specs and send it to you. [CA] What of this is needed for the RD spec, not what is coming from outside specs (OMA) [JJ] Then something can be removed. [CA] Probably the whole table. Why are we having this actually? Why don't we just say - LW OMA is using this and be done with it. Don't do the registration examples. [JJ] Makes sense, to avoid confusion and replication. [CB] Little point in enumerating registration parameters without explaining what they mean. Delete the table and change colon into period. Always in dangerous territory when re-phasing data from a different normative document. [JJ] It seems to include things not really needed to understand what matters here. Can we just state at the beginning that this is just an example relevant to LwM2M? [CB] It might even not be entirely correct, if they updated their object. [JJ] It looks correct to me, sure it may change in the future. Can we just point to the new OMA document for the example? [CA] Would remove much of it - about 3 screens - little seems to be required. [CB] I would delete 10.2, and add at the beginning of 10 a pointer to the OMA specs. - **Issue WGF-8 - just-do-it (on which ND messages can carry an RDAO)** [CA] Would it be OK to just say that RDA0 always do this [CB] Let's check where they'd go in DNS server. [CA] OK I think I can act on this. - **Issue WGF-8 - Could use some help here - Status config in DHCP** [CA] Need someone who understands this to come up with some text. [CB] Point is in bullet list on page 16 - Can provide additional information from option - can supply same option if using SLAAC. [CA] We don't have to, right? [CB] Right but if DHCP is running anyway, no more configuration is needed. Can be done even if not doing address configuration. [CA] So just adding more text on when DHCP is used. [CB] Yes. - **Issue WGF-8 - because no sleepy nodes document was even alive when I got active here** [CA] No up-to-date document to reference, but we are talking about it in the introduction. Has the topic died enough that we should remove the reference, or should we give more information? [CB] Reason for no document - all current approaches have patent-thickets around them. Safest approach is to use a proxy. Node alerts proxy and proxy can then forward requests to it. [JJ] Comment seems to be how does this get implemented/work. [CB] All documents written were trying to get patent method adopted. Nobody documented less dangerous versions. ***ACTION ITEM - Carsten will provide a pull request to deal with this*** [JJ] Can we just talk about proxy doing this - comment is about how to talk to a sleeping endpoint. [CA] Proxy has representations but if not then fails. - **Issue WGF-8 - section 3.6 - home building automatation** [JJ] Don't know how much of this is current anymore - topic is very big talking about both home and office automation. [CA] If I find examples to sprikle in then do that, otherwise just add some sprinkling of words talking about where and RD can be used. - **ISSUE WGF-8 - How does an RD know the policies that a client has for security policies** [CA] I don't think this is needed. RD will accept what it knows. [CB] Classical authorization process. Source of authorization is not defined here. The fact that an RD can be authenticated does not say what it is useful for. Need trusted 3rd party to announce what it is usedful for - would be something like an ACE token. [CA] I think I can factor that in. - **Issue WGF-7 - Primary to notify everyone that core-interfaces example will go away** [CA] Have done some point squatting here. if=core.a as example. Better ideas than just use example.core.a ? Can advertise anything desired - so the Kelvin is not an issue [CA] Can do more realistic examples w/o squatting. [CB] Would like unit names to be SenML compatible. - **Issue WFG-7 - More broad document on URIs for bearer tokens** [JJ] Is there something relevant in that document we need to check. - **Issue WGF-7 - What does not support multicast well mean** [CA] Not big expert here. Will not justify ranking. - **Issue WGF-7 - Exposing URIs in endpoint lookup** [CA] Exposing them in lookup - do we have information that would help in justifying this model? [JJ] What does this mean that the RD does not make them accessible? [CA] It was the best structure format that we had when we started working on RD. We are describing the resources, but not expecting the client to be able to make use of that resource. It is just a name and not de-referencable. Any changes here are going to be hard - so just describing why it makes sense is best. If did this in CoRAL, might choose not to give the name of the resource, just a statement that it exists. This is not a link-format option. Might have an information disclosure security problem if the names are not derived from the endpoint name or completely randomly. Should document that this is a possible issue. [JJ] Use case of link catalogs - should we put a comment in here. [CA] That is more about registered links isn't it - [JJ] Not exactly the same thing - yes - **Issue WGF-7 - Odd examples - luminary part** [CA] Looking up groups and deciding by that group if they should join the group. Need to do some additional checking on the links and is not how I would recommend it to be done. Should we remove this part as well? Given that a document is coming that does a better job of how to do group discovery - Example 10.1 [MT] Not finding out existing membership, but looking for what membership should be. Hence not implying/needing any earlier membership registration (which is in fact not defined here). [CA] Designed around the idea that based on link data - you think that you should join group. Requires idea that the link data is something that is useful. Preference would be to remove that part of the example. [CA] Part about automatically joining group and using multicast address configuration are confusing examples about best. - **Issue WGF-7 - "disperse networks"** [CA] Unsure what this means - inclination is to just remove it. - **Issue WGF-7 - talked with 6MAN?** [CA] Not sure what the procedures are here - if somebody has experience with them would like some help (or just pass off the issue) [CB] Been to meetings - question is about getting a code point from them. Might want to present to them - either slot in meeting or send a mail to the mailing list. [CA] Will do this - see if they have comments. - **WAY FORWARD** [CA] Everything below 4 is for people to skip over things and see if they want to comment. [MT] What is the timeframe for an update? End of month / early October? [CA] That should be possible. [MT] Tentatively, let's check again at the next interim. ### AOB * [CA] plugging https://coap.amsuess.com/ Running some applications - one of which is an RD Root is a description of the services that are provided. ***ACTION ITEM - Christian will mention this to the CoRE mailing list*** ***ACTION ITEM - Carsten will mention this in the CoAP Technology website*** * Advertise upcoming doodle for cachable-oscore run-through * Looking for suggestions for the next interim. It can be a wrap-up session on the RD, followed by a discussion on Dynlink.