IOTOPS at IETF 123 Madrid

Thursday 24 July 2025
10:00 (UTC)/ 12:00 (Madrid)
1 hour

Meetecho: https://meetings.conf.meetecho.com/ietf123/?session=34253
Notes: https://notes.ietf.org/notes-ietf-123-iotops
Chairs: Alexey Melnikov and Henk Birkholz

Abbreviations:

CA: Christian Amsüss
CB: Carsten Bormann
HB: Henk Birkholz
HT: Hannes Tschofenig
MCR: Michael Richardson

Action items

• chairs: ask for early YANG review of "old" document

Notes

Notes taken by Michael Richardson, Ivaylo Petrov, and Jan Romann

12:00 Administrivia
(5 min; chairs)
presentation

Henk goes through the slides

No bashing of the agenda

12:05 draft-ietf-iotops-security-protocol-comparison
(5+5 min; John/Francesca)
Presentation

Francesca:

• Short update on the comparison of CoAP security protocols document

• Status: currently with the authors to respond to Med's review

  • Will add more motivation, operational considerations, clarify
    terminology and references (informative vs. normative)

• Went through the IESG statement on normative references

  • States that normative references are needed when defining a new
    technology, which we are not doing, which is why we want to keep
    the references informative
    • Med agreed, but said that the topic might come up again,
      therefore I wanted to bring this to the WG
      • I am seeing thumbs up in the audience, so then we have
        this for the record and I will point the IESG to the
        minutes of this meeting when it comes up again

• Up next is the re-submission of the document and then we can start
  the IETF LC.

12:15 draft-ietf-iotops-mud-acceptable-urls
(5+5 min; Michael)
presentation

MCR presenting the history of the draft - first adopted by OPSAWG, but
happy to have it here now.
MCR describes MUD updates of firmware and false positives as that will
make people ignore that. So we don't want false positives.
MCR: it's fine to sometimes allow something that the device never does.

MCR: Adding new permissions with new firmware update is fine, describes
when that might need a new URL instead of just updating the file pointed
by the URL.
MCR: Mud can be fetched through a few ways - it's easy by DHCP, but
malware can abuse it. LLDP is slightly more secure, but it can still be
circumvented.
MCR: IDevID is the best, but can't change the URL later on.
MCR: It can be good for a first URL. The proposal is to allow to only
change the last part of the URL, not changing the origin, not changing
the model of device, so that should be fine.
MCR: You can change the URL if you get aquired by another company by
updating the MUD file.
JPB: you said IDevID is permanent, but what about deploying LDEVID?
MCR: Quantum safe profiles are in the works, maybe initially it's fine
to use IDevID and switch right away
CB: RFC 8520 is on Standards Track.
MCR: Maybe it was AD sponsored and I will withdraw my concern about
whether we can update it in IETF.
CA (via chat): I like new-URL-in-old-MUD-file way better than limiting
which parts of URLs can be touched. (But there might be good reasons to
do the latter)
MCR: They are not mutually exclusive, they are two steps of doing it.
HB: Can also continue discussion on the mailing list.

12:25 draft-ietf-iotops-ol
(5+5 min; Michael/Carsten)
presentation
CB:

• Problem with MUD files is that they can be copyrighted
• So they have an owner who can license you to use them
• So when you are using them in a network, you depend on whether you
  are allowed to use them
• As you see in the slides, the YANG for that is relatively simple
• The YANG essentially says that you augment and that you can have
  zero or more license-types (which are SPDX identifiers) or just
  generic URIs
• So the questions are:
  1. Is this the right type of information?
  2. Is using a YANG augment the right way to do this?
     • Not a YANG expert, so I need help with question 1, but I am
       also not a lawyer, so I also need help with question 2

HB (without the chair hat):

• You want to have a dedicated SPDX license tag to clarify the
  requirements you have for the license
• Could enumerate these to make sure no to use the wrong one

CB: Already made an update of SPDX (?)

MCR:

• MUD uses a well-bespoke extension mechanism that I would like to
  have reviewed
• But I think augment is the wrong choice here, as it produces the
  wrong output, it might be just a group, but the YANG people might
  correct us here, the TLS people got it wrong as well
• Otherwise it looks good to me

CB:

• Maybe the chairs could initiate an early review by the YANG people?
• If we can fix the YANG issue and perform the SPDX update, then we
  should be able to go to WGLC

12:35 draft-richardson-iotops-mud-query
(5+10 min; Michael)
presentation

MCR:

• A lot of people have Intrusion Detection Systems, but they are often
  wrong when it comes to IoT devices
• On the other hand, there are new regulations coming up in the UK and
  California for example, so the question is whether you need strong
  identity to perform regulation, which raises privacy issues

• So if we could use the IDevID in a TLS connection as a solution for
  enumerating devices

  • "Bad guys" could use it as well, but they have better heuristics
    than the "good guys" anyway.
  • Random people could find out which devices are on the network as
    well, but the solution to that is: Don't let random people into
    your network.

• Proposed solution:

  • Derive a list of systems from neighbor list, then do TLS on a
    new defined port -- and you are done
  • You can get the MUD from the IDevID certificate

HT:

• Could you also do DTLS?

MCR:

• Yes

HT:

• Then you could also do EDHOC...

MCR:

• Well, if you do not do certificates, then you won't have any
  benefit.

HT:

• But what is the benefit if the device is already onboarded?

MCR:

• There is probably not that much benefit then. This is useful for
  cases when usual onboading hasn't been done. Maybe a preinstalled
  device.

MCR:

• You could sign the DHCP request, but it takes a lot of plumbing
• So I would propose doing it link-local
• You could find out the MUD URL from the IDevID, if there is none,
  then you do not get it, but you can still identify the device

HT:

• There might be other possibilities

MCR:

• Agree, wanted to start the discussion
• Propose to use IPv6 link local, will not require a new discovery
  mechanism, do not propose to use mDNS
• We could further restrict it
• IPv6 link-local is already widely available, even if the devices are
  not using it

• Technical problems are that it requires

  • IPv6, since IPv4 link-local is not configured on a lot of
    devices - especially after they get a DHCP response with an
    address.
  • IDevID
    • probably not possible to retrofit these in most cases

• Is related to RATS and work from the EDHOC WG

  • this approach could be used as some kind of remote attestation

• Question is: can we get vendors to implement this and convince the
  regulators that this fulfills requirements?

HT:

• As we have seen, we cannot rely on the regulators
  • Might not even get what you initially wanted

MCR:

• In the UK, a corresponding law is in force for a year now

HB:

• (Starts a poll on whether the WG is interested in working on this
  topic)

  • Results:
    • Yes: 13
    • No: 0
    • No Opinion: 7

• So there is no objections, considering that we have about 50 people
  in the room. We will check on the mailing list.

MCR:

• I am also looking for co-authors, not attached to the solution, just
  the problem.

12:50 IoT DNS Security and Privacy Guidelines
(10min; Jim/Abhi)
presentation

Jim and Abhishek presenting

DNS security and privacy guidelines catered to IoT.
There are resource constraints, IoT devices miss security agents. When
IoT devices they can be fingerprinted, so privacy can be lost. The goal
is to help network security people manage large deployments.

There might be devices that ignore DNS initially, but that doesn't
affect them then.

A passive thread - listening for DNS traffic and active one.
They tried checking port randomization and that was fairly poorly
implemented.
Amplifying attack was possible - affecting many devices
98% of the devices were fingerprinted successfully.
Some devices were contacting hardcoded DNS servers, caching was limited,
etc.
Found a bunch of vulnerabilities and found no papers specific to this
topic.

HT: What kind of devices were you looking at - Linux or big?
Abhishek: There were different types - from smart plugs to smart TVs
HT: in some devices you find very restricted DNS
Abhishek: 80-90% of the devices were resource constraint
HT: Maybe then that's a feature - there might be no privacy rights for a
fridge and the vendors probably didn't see the need to protect that kind
of information - so not using DNS over HTTP, etc.
HT: tinyDTLS don't have this kind of features, so maybe.
Abhishek: Even with DoH looking at the packet size, you might infer the
type of devices.
Jim: There are mitigations that we have listed, etc. Take a look please.

• caching will be useful in many cases
• DNSSEC validation should be done by manufacturers.
• We appreciate any feedback on the draft
  Daniel: Wanted to say that this makes sense and one element that
  actually challenges the assumptions is that you might have devices
  (like smart toasters or toothbrushes) that are very much linked to
  your digital identity.

13:00 FIN