[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 [127.0.0.1]) 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-Level:
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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [10.13.13.254]) 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 meeting. BR c [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
- [core] Using SVCB with OSCORE/EDHOC Christian Amsüss
- Re: [core] Using SVCB with OSCORE/EDHOC Carsten Bormann
- Re: [core] Using SVCB with OSCORE/EDHOC chrysn