Minutes interim-2020-core-01: Wed 15:00
minutes-interim-2020-core-01-202004081500-00

# WEDNESDAY, April 08, 2020

13:00-15:00 UTC

Note takers: Francesca, Amelia, Marco, Jaime
Jabber scribe: Jaime, Marco
Queue manager: Jaime, Marco

Numbers in parentheses are minutes of time allocated.

## Intro (10) 13:00

Note well presented.

Agenda reviewed (no objections).

Introducing Marco as new chair. Welcome Marco, thank you Carsten!
New AD: Barry.
New: interims every other week. Time will be 14:00UTC and meeting docs will
available at core-wg.github.io

  * WG and document status
    * Published:
        * multipart-ct-04: RFC 8710 !!
        * hop-limit-07: RFC 8768 !!

    * RFC-Editor's Queue:
        * draft-ietf-core-senml-etch-07
        * draft-ietf-core-senml-more-units-06

    * IESG Processing:
        * draft-ietf-core-resource-directory-24: In Last Call
            * draft-ietf-core-stateless-05: In Last Call

    * In Post-WGLC processing:
      * draft-ietf-core-echo-request-tag-09

    * WGLC to be issued:
      * draft-ietf-core-dev-urn-04

## CoRECONF cluster (Ivaylo) (15) 13:18

  * draft-ietf-core-yang-cbor-12 --- Ivaylo
  * draft-ietf-core-yang-library-01 --- Ivaylo
  * draft-ietf-core-comi-09 --- Ivaylo
  * draft-ietf-core-sid-12 --- Ivaylo

Objectives:

  - Outcome of WGLC, possible discussion on relevant issues
  * draft-ietf-core-sid-12 --- Ivaylo

All remarks are still not processed.

Carsten Bormann (CB): the intention is that we are doing the same thing we
would be doing in the early allocation process. Is that correct representation?
Ivaylo: yes CB: then we probably need a little bit of text because the early
allocation is aimed at IESG and DE does not operate exactly how IESG does. Need
text for that. Esko: You don't need an early allocation anymore because you get
a quick allocation now. CB: Bug or feature? Early allocations are reviewed
after a year and go away if nothing happens. Provisional allocations would be
very quick and get back them back if nothing happens, which is different than
permanent. Esko: OK, I see the intention. CB: SIDs aren't quite as scarce as
other things we're seeing in allocation. Was just trying to explain what we
gain by having an early allocation process. Ivaylo: Let's continue discussion
on mailing list. Jaime: continue the discussion in the mailing list, pretty
mature and no major things. Ivaylo: yes.

  * draft-ietf-core-yang-cbor-12 --- Ivaylo

Do we want to have normative references from CBOR to SID or the other way
around?

Jaime: You have to submit another version of this document regardless. Do
people have opinions on normative references? Ivaylo: Yes. CB: I have very
strong opinions on normative references. In the past normative references that
were not necessary caused big delays to our work. Since YANG-CBOR is a
free-standing document, even if it sits on YANG, it doesn't need all the other
machinery that we are creating. Let's try to process with a minimal amount of
normative references, keeping in mind that the document should be free-standing
in the sense that someone who just wants to use YANG-CBOR can do that without
referencing other docs. Jaime: did you reply to Tom Petch for the feedback he
gave for this? Ivaylo: I might have missed it? Jaime: let's make sure all
comments are adressed in next resubmission.

  * draft-ietf-core-comi-09 --- Ivaylo

It is not clear whether Security Considerations really need to very extensive,
or whether a more general observation is acceptable that authorization requires
care.

No further discussion.

  * draft-ietf-core-yang-library-01 --- Ivaylo

Jaime: Actually the comment from Tom Petch was here, not on CBOR. Do you have a
time-line for resubmissions? Ivaylo: Will probably have all the editorial
changes by tomorrow or end of the week. The other changes depend on the level
of detail required to solve concerns. The SID-draft may take longer time to
work out than the others. We are hopeful it will not be a big delay. Jaime:
Bear in mind to send the latest versions to other potential reviewers who may
be interested. We will do another WGLC when the new documents are submitted.

## Groupcomm (Marco, Christian, Esko) (60) 13:44

* draft-ietf-core-groupcomm-bis-00 (10) --- Esko

    Objectives:

    - Discuss updates (addressed reviews and closed TBDs)
    - Discuss open points (handling different group types, reusage of tokens
    for observation, explicit signaling of multicast messages) - Ask for reviews

Esko: intended to obsolete RFC 7390, updating RFC 7252 and 7641; insecure and
secure (with Group OSCORE) communication are in scope Esko: Taken care of Jim's
and Thomas's reviews, improved definitions, discussed group discovery with the
RD, improved security considerations Esko: Distinction between
CoAP/OSCORE/Application groups, they use different types of identifiers,
example figure Esko: open issue #1 on Github, the port number may change in the
server response compared to the port number of the multicast request, discussed
on the list Esko: open issues #26 and #35 on Gitlab, on using URI-Host for
identifying application group and for consistency requirements for suppression
of responses Esko: Next steps are working on the open issues and process last
review comments. Test selected functions in CoAP implementations.

Jaime: issue 35 what is that?
Esko: a non WG-adopted draft issue, see
https://gitlab.com/crimson84/draft-groupcomm-bis/issues. Jaime: reviews by
Thomas and Jim, sufficient or more reviews needed? Esko: Always good with more
reviews. Maybe next update. Jaime: Any volunteers to review current or next
version? Please indicate in chats on Webex or jabber. Christian Amsuess , Jim
and Thomas Fossati volunteer for next version.

* draft-ietf-core-oscore-groupcomm-08 (15) --- Marco 13:55

    Objectives:

    - Discuss updates (addressed review, sec con, optimized and pairwise mode)
    - Discuss open points (support for pairwise mode, Sender ID for silent
    servers, remove IANA registries from signature+key params, appendix E.2 on
    client sequence number) - Ask for reviews

Marco: We hope to do more testing of message protection, and then to go to WGLC
Jim: number of issues. sl.10. Basenline sync, it should be optional to discard
the first baseline request. If you do pairwise: problem with EdDSA MTI since
both montgomery and edwards implementation would have to be MTI in HW.
Christian: E2 appendix: careful to differentiate between application's
freshness requirements and requirements for reusing the sequence number. Jim:
draft in LWIG that talks about EdDSA with a mapped coordinates where you can do
both key agreement and signing, which could become the MTI --
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
Francesca: there is a discussion in the mailing list on making this document
update OSCORE. : There's a requirement of HMAC-based HKDFs in OSCORE, which may
not really be necessary. Could have sentence in Group OSCORE about "Any [H?]KDF
is fine"; is doing it in this document the best option? Want to do it fast, but
if it's in this document there'll be an "Updates" link that gives the wrong
impression of Group OSCORE being mandatory for OSCORE now. Jim (on Jabber): I
have succesfully done the multicast + observe as well Jaime: If anyone wants to
review, say now. Christian (on jabber): raises his hand for reviewing the next
version of groupcomm

* draft-tiloca-core-oscore-discovery-05 (10) --- Christian 14:16

    Objectives:

    - Discuss updates (addressed review, registration of link to AS, examples
    in CoRAL) - Discuss open points (no re-introduction of group member
    registration --- BACnet example) - Solicit reviews

Christian: just deployed nodes may miss information on how to join an OSCORE
group through the Group Manager (GM). Then we use the CoRE Resource Directory
(RD), it works even if the GM is not deployed yet. Christian: addressed Jim's
review, added to the link to the group also the link to the ACE Authorization
Server associated to the GM. This spares the client from an unouthorized access
just to learn of the AS. Christian: clarified relation between application and
security groups (but still to finalize across documents) Christian: Examples
added also in CoRAL, the link to the AS cannot be formally "navigated", it's
metadata. Christian: we have a long example from BACnet, where devices start
from scratch. Right now the RD is not expressing nodes' membership to a group,
but this example is doing that out of the blue. It's just an example though.
Better to just pull that part of the example out or can confuse, can be defined
just in a separate document. Christian: we got 1 of the promised reviews, we
would need more.

Jaime: on the first example, that's a registration?
Christian: yes, it would look very similar in a look up
Jaime: on the payload?
Christian: on the payload the GM announces one of its join resource, to join
one of its OSCORE groups?

Jaime: in the payload the group and the token to register with?
Christian: the AS.

Jaime: volunteers to review. Jim volunteers on Jabber.

* draft-tiloca-core-observe-multicast-notifications-02 (15) --- Christian 14:26

    Objectives:

    - Discuss updates (congestion control, error response encoding, observation
    cancellation, alternative retrieval of phantom request) - Discuss open
    points (rough client counting, alternative encoding) - Ask for reviews

Christian: allow the distribution of resource updates over multicast, to a lot
of subscribers all observing the same resource on the server. Aligns well with
pubsub. Christian: the group of clients as a whole "controls" the multicast IP
address and the Token value used for all the multicast notifications. Christian
This starts from a common "phantom request" as sent *from* the multicast IP
address of the group. The server creates it and sends it to itself. Then it's
serialized and sent to the clients to align them, as included in an error
response to the clients as they come to try observing. Christian: added
discussion on congestion control, more explicit encoding of phantom request and
other information inside the error response to the clients Christian: described
alternatives to retrieve the phantom request in different ways, e.g. pub-sub
when discovering a topic, or introspection during network debugging by querying
the server

Jaime: related to Thomas's error response draft. are you aware of that draft?
Christian: yes, not exactly the same problem but may be possibly considered.
Jaime: do you have CBOR or CoRAL examples?
Christian: now mainly in CBOR, pointing that they can well be also in CoRAL.
Thomas: the last "problem draft" is also mainly in CBOR.
Jaime: sounds like an interesting topic for an interim. We need to schedule a
discussion for later on, on the connection between different documents:
draft-fossati-core-coap-problem, draft-core-coap-pubsub and this draft
draft-tiloca-core-observe-multicast-notifications. Christian: then it's about
how the server can cancel a group observation. We propose a CoAP option that
the server can use to communicate and update its own estimation of the group
size. If the updated count falls below a threshold, the server can cancel the
group observation. Carsten: you may make a probabilistic estimation on the
group head. Christian: isn't this what we are doing? Carsten: you may send a
sense to select a small subgroup to send a response. You need to maintain a
group size estimate at the group head. Based on that, you can choose the size
of the head. Christian: pretty much what we are doing, we just describe it
based on random events to fall within a range. Carsten: that's good. Christian:
we want to spend more time thinking about alternative serializations inside the
error response, possibly with more serialization of content intended to go on
the wire. Jim (on jabber): It will be interesting to try and implement this
when the details are more nailed down. Jaime: I have no additional comments. If
no one else has any comments maybe we can move on. We will have to move some
stuff until Thursday.

* draft-tiloca-core-groupcomm-proxy-00 (10) --- Esko 14:44
    Objectives:

    - Present new work
    - Christian's comments on the list
    - Ask for reviews

Esko: handling a request from a client, to go through a proxy and forwarded
over multicast to multiple servers Esko: we condsider an approach where the
responses from the different servers are sent back to the client individually
(no aggregation). Group OSCORE is used for security. Esko: the client uses one
new CoAP option to indicate to the proxy it is fine with all this. Each server
uses a second new CoAP option, to indicate its own IP address all the way to
the original client. Esko: presenting the two new options and their properties.
Esko: presenting the workflow, client --> proxy (which identifies the client,
set a timer for how long to wait for responses, observation is handled) -->
server --> proxy --> client (that can retrieve the address of each of the
servers from their response). Esko: got a review from Christian, we have open
points as to an alternative use of the two options and their properties; it
seems also a use case opening for "nested OSCORE" between client and proxy
Esko: main next steps are about addressing open points and Christian's review.
Jim: this seems to assume there is no address mapping involved, if the server
provides its address but it's behind a NAT Marco: the alternative approach
suggested by christian would address this. Esko: If the proxy is also the nat,
the client can reach the proxy then through the proxy it can access the devices
even if the addresses are changed. Christian: the client has to find out anyway
in some way that that particular address is usable. It's premature to think of
this particular interactions. Addresses that come back even from a proxy will
make sense.

Jaime: We don't have any time for further presentations so we will have to move
them to the next session. Thank you all for your time! Hope to see you next
Thursday at the same time.

Σ 120