Subject: [core] Disclosing Implementation Information: draft-bormann-t2trg-rel-impl-01.txt

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Mar 2020 17:13:19 +0100

In 2018, we had a discussion about providing self-description information that tells a client something about the implementation (and version) of the server.  So I wrote a brief draft, and I seem to remember everybody nodded, but it wasn’t quite clear whether that was because they agreed or because they fell asleep.

By now, it has become more clear that disclosure of implementation information can be quite useful.  Actually, we already have RFC 8520 (MUD) for some very specific information of this kind.  A more free-form version still seems useful, and can use Web Linking (RFC 8288) and Link-Format (RFC 6690) so the specification itself is quite minimal.

So I have added some security considerations (pointing out, among other things, that this disclosure is not always desirable) and cleaned up the text a bit.  See links below.

Comments (+1, -1, or actual text) would be welcome, both from T2TRG and from CoRE.  It seems the CoRE working group might want to consider working group adoption of this draft or a next version, at which time it would transition from the RG context to the WG.

Grüße, Carsten

> On 2020-03-27, at 16:58, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> Title           : impl-info: A link relation type for disclosing implementation information
> Author          : Carsten Bormann
> Filename        : draft-bormann-t2trg-rel-impl-01.txt
> Pages           : 4
> Date            : 2020-03-27
> 
> Abstract:
>   For debugging, it is often helpful to have information about the
>   implementation of a peer.  The present specification defines a link
>   relation type, "impl-info", that can be used to convey such
>   information via self-description, such as in the "/.well-known/core"
>   resource.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bormann-t2trg-rel-impl/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-bormann-t2trg-rel-impl-01
> https://datatracker.ietf.org/doc/html/draft-bormann-t2trg-rel-impl-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-bormann-t2trg-rel-impl-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 29 Mar 2020 12:08:50 +0000

Would it make sense to standardize how to exactly express the information about the implementation and version? Being able to find that information seems useful -- but incomplete :-)

And then I'm wondering if there's a risk that we might end up with something like this in the future:

1. Client makes a GET request on the implementation information resource
2. Server returns a string like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
3. Client behaves differently based on the implementation information

Klaus

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Friday, March 27, 2020 5:13 PM
> To: [email-masked]; [email-masked] WG <[email-masked]>
> Subject: [core] Disclosing Implementation Information: draft-bormann-t2trg-
> rel-impl-01.txt
>
> In 2018, we had a discussion about providing self-description information that
> tells a client something about the implementation (and version) of the
> server.  So I wrote a brief draft, and I seem to remember everybody nodded,
> but it wasn’t quite clear whether that was because they agreed or because
> they fell asleep.
>
> By now, it has become more clear that disclosure of implementation
> information can be quite useful.  Actually, we already have RFC 8520 (MUD)
> for some very specific information of this kind.  A more free-form version still
> seems useful, and can use Web Linking (RFC 8288) and Link-Format (RFC
> 6690) so the specification itself is quite minimal.
>
> So I have added some security considerations (pointing out, among other
> things, that this disclosure is not always desirable) and cleaned up the text a
> bit.  See links below.
>
> Comments (+1, -1, or actual text) would be welcome, both from T2TRG and
> from CoRE.  It seems the CoRE working group might want to consider working
> group adoption of this draft or a next version, at which time it would
> transition from the RG context to the WG.
>
> Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 29 Mar 2020 14:47:46 +0200

> Would it make sense to standardize how to exactly express the information about the implementation and version? Being able to find that information seems useful -- but incomplete :-)

If we want to encourage clients changing their behavior based on what they find, as in your example below: Yes.
If not:
The resource at the other end of the link has a media type.

We could still go ahead and define one or more media types for this.
I’m just not sure that we’ll find more commonality than text/plain or text/html here.
(We could find ourselves in security.txt land, though [1].  Hmm.)

> 3. Client behaves differently based on the implementation information

Any way of standardizing self-describing information increases this risk of sniffing against that.
Implementations might react on impl-info or on the mere fact that the temperature sensor resource is called “/temp” and not “/t”...

Grüße, Carsten

[1]: https://securitytxt.org/

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 30 Mar 2020 08:23:28 +0200

On Fri, Mar 27, 2020 at 05:13:19PM +0100, Carsten Bormann wrote:
> Comments (+1, -1, or actual text) would be welcome, both from T2TRG
> and from CoRE.  It seems the CoRE working group might want to consider
> working group adoption of this draft or a next version, at which time
> it would transition from the RG context to the WG.

+1 on making implementation information something that is common, and on
rel-impl as a starting point.

We're seeing millions of CoAP devices on the Internet now, and I'm
rather confident some of them do not implement all the amplification
mitigation RFC7252 says they should do. With implementation information,
reactions to large-scale attacks amplified through them can be made into
a productive "everyone still using version X of Y *please* update to X2,
which has been released two years ago already" rather than a blunt
"Don't use CoAP".

Servers written using aiocoap have been showing a link to the library
version by default[1] since version 0.4b1, and I've heard some positive
feedback from the RIOT community towards making this default as well.

> Would it make sense to standardize how to exactly express the
> information about the implementation and version? Being able to find
> that information seems useful -- but incomplete :-)

Structured information can be there in the payload using media types, as
Carsten pointed out.

I know some neat metadata format that can either embed such
representations, or just include them if they use the same metadata
format[2], but practically expect that the operators or tools that look
those up will manage to follow the link.

KR
c

[1]: https://aiocoap.readthedocs.io/en/latest/module/aiocoap.resource.html?highlight=wkc#aiocoap.resource.WKCResource
[2]: 
```
core: impl-info <https://example.com/product1/0.99b1> {
    base:representation h'a2....' { http:type "application/metadata+cbor" }
    # alternatively
    versioninfo:vendor "Example Ltd"
    versioninfo:product "ProductOne"
    versioninfo:semver "0.99b1"
}
```

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 30 Mar 2020 14:00:20 +0300

Hi,

chair hat off. I find the draft very useful and easy to implement.
I'd expect that CoAP implementations out there can incorporate it quickly.
If there are other potential link-relations that are needed we might
want to bundle them in one document similar to RFC6903.

Ciao, Jaime

On Fri, Mar 27, 2020 at 05:13:19PM +0100, Carsten Bormann wrote:
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core