diff --git a/draft-lenders-core-dnr.md b/draft-lenders-core-dnr.md index ffaa8b4..569df55 100644 --- a/draft-lenders-core-dnr.md +++ b/draft-lenders-core-dnr.md @@ -113,7 +113,7 @@ CoAP comes with 3 security modes that would need to be covered by the SvcParams: OSCORE keys are not usable indefinitely and need to be set up, for example through an EDHOC key exchange {{-edhoc}}, - which may use credentials from trusted authorization server (AS) + which may use credentials from trusted ACE Authorization Server (AS) as described in the ACE EDHOC profile {{-ace-edhoc}}. As an alternative to EDHOC, keys can be set up by such an AS as described in the ACE OSCORE profile {{-ace-oscore}}. @@ -127,7 +127,7 @@ mechanisms, which this document will discuss. The terms “DoC server” and “DoC client” are used as defined in {{-doc}}. -The term “constrained node” is used as defined in {{-constr-nodes}}. +The terms “constrained node” and "constrained network" are used as defined in {{-constr-nodes}}. SvcParams denotes the field in either DNS SVCB/HTTPS records as defined in {{-svcb}}, or DHCP and RA messages as defined in {{-dnr}}. SvcParamKeys are used as defined in {{-svcb}}. @@ -145,17 +145,25 @@ identify classic transport layer security, the question is raised if this is nee for when there is only object security. There is an ALPN ID for CoAP over TLS that was defined in {{-coap-tcp}} but it is not advisable to use the same ALPN ID for CoAP over DTLS. Object security may be selected in addition to transport layer security, so defining an ALPN ID for each -combination might not be viable or scalable. For OSCORE specifically, additional information is +combination might not be viable or scalable. For some ways of setting up object security, additional information is needed for the establishment of an encryption context and for authentication with an authentication -server (AS). Orthogonally to the security mechanism the transfer protocol needs to be established. +server (AS). Orthogonally to the security mechanism, the transfer protocol needs to be established. -Beyond the SvcParamKeys the question of what the field values of the Encrypted DNS Options defined +Beyond the SvcParamKeys, there is the question of what the field values of the Encrypted DNS Options defined in {{-dnr}} might be with EDHOC or ACE EDHOC. While most fields map, -“authentication-domain-name” (ADN) and its corresponding ADN field may not matter in the EDHOC case. +“authentication-domain-name” (ADN) and its corresponding ADN length field may not matter in ACE driven cases. -- TBD but might be out-of-scope: - - replace coap+... URI schemas with hostname literals - - Increased RA size / fragmentation +Out of scope of this document are related issues adjacent to its problem space. +they are listed both for conceptual delimitation, +and to aid in discussion of more comprehensive solutions: + +* There is ongoing work in addressing the trouble created by CoAP using a diverse set of URI schemes + in the shape of `coap+...`, such as `coap+tcp` {?I-D.ietf-core-transport-indication}. + The creation of URI authority values that express the content of SVCB records together with IP literals + is part of the solution space that will be explored there. + +* Route Advertisements (RAs) as used in {{-dnr}} can easily exceed the link layer fragmentation threshold of constrained networks. + The presence of DNR information in an RA can contribute to that issue. # Solution Sketches @@ -217,7 +225,8 @@ svc-params: - docpath="/dns" ~~~~~~~~ -Note that “coaptransfer” may not necessarily be needed, as it is implied by the ALPN ID. +Note that “coaptransfer” is not needed, as it is implied by the ALPN ID; +thus, no values for it would be allocated for transfer protocols that use transport security. ## DoC over OSCORE using EDHOC While the “alpn” SvcParamKey is needed for the transport layer security (see {{sec:solution-tls}}), @@ -239,6 +248,9 @@ svc-params: - port=61616 ~~~~~~~~ +The use of objectsecurity="edhoc" with an authenticator-domain-name and no further ACE details indicates +that the client can use CA based authentication of the server. + ## DoC over ACE-OSCORE Using ACE, we require an OAuth context to authenticate the server in addition to the “objectsecurity” key. We propose three keys “oauth-aud” for the audience, “oauth-scope” for the