[core] Using SVCB with OSCORE/EDHOC

Christian Amsüss <christian@amsuess.com> Sun, 26 March 2023 11:55 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0860AC14CE3B for <core@ietfa.amsl.com>; Sun, 26 Mar 2023 04:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Zkux-JMlAw5O for <core@ietfa.amsl.com>; Sun, 26 Mar 2023 04:55:50 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82ED9C14CE36 for <core@ietf.org>; Sun, 26 Mar 2023 04:55:48 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 32QBtkXM040601 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <core@ietf.org>; Sun, 26 Mar 2023 13:55:46 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com []) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id EF9751D9A7 for <core@ietf.org>; Sun, 26 Mar 2023 13:55:45 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A9BCC2003B for <core@ietf.org>; Sun, 26 Mar 2023 13:55:45 +0200 (CEST)
Received: (nullmailer pid 6065 invoked by uid 1000); Sun, 26 Mar 2023 11:55:45 -0000
Date: Sun, 26 Mar 2023 13:55:45 +0200
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org
Message-ID: <ZCAywSGXT9Yv16ZC@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="b6ce19kL+/KHf4sb"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Bc36wzeg7bzNxNgj4W1k7GEErKw>
Subject: [core] Using SVCB with OSCORE/EDHOC
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Mar 2023 11:55:55 -0000

Hello OSCORE and EDHOC authors,
(limiting this to CoRE as it's not about EDHOC itself but how it's used
with CoAP)

processing DNS-over-CoAP reviews has sent me down the rabbit hole of
SVCB[1]. These records' main purpose is to advertise alternative
services, similar to SRV (thus overlapping with what [2] is doing for
CoAP, but that's not the point here).

That record can also transport data for setting up Encrypted Client
Hello and choosing the right TLS ALPN, and that is information similar
to what EDHOC (or other OSCORE bootstrappers) can utilize. Furthermore,
they are used in DNR[3] to advertise local services with extra
information (which currently[4] enforce the use of ALPNs). Had that
format been around when RD's RDAO[5] was specified, we might have used
it instead of the plain address. Starting DTLS is relatively
straightforward from these options because it frequently uses PKIX;
starting EDHOC from there could be done the same way, but might be done
more efficiently eg. by announcing the server's CCS. Properties of
oscore-edhoc[6] might be relevant.

I don't have a full plan here, but I think there might be value in
looking into how SVCB records and OSCORE/EDHOC can be combined, both
directly for DNS-over-CoAP and for other applications -- and would like
to explore these with the group.

Let's see if there's something useful in this! Apart from list
discussions, I'm also around in gather.town for most of the current

[1]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
[2]: https://datatracker.ietf.org/doc/draft-ietf-core-transport-indication/
[3]: https://datatracker.ietf.org/doc/draft-ietf-add-dnr/
[4]: https://mailarchive.ietf.org/arch/msg/core/yFHfHUHDDwh0HANDJEqj_TmkiMc
[5]: https://www.rfc-editor.org/rfc/rfc9176.html#name-resource-directory-address-
[6]: https://www.ietf.org/archive/id/draft-ietf-core-oscore-edhoc-07.html#name-web-linking

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