Re: [Add] DNR: Mandatory ALPN indication and non-TLS protocols (eg. OSCORE)

[Dan Wing <[e-mail]>]

Sounds reasonable to me. 

As you know well, many specs are TLS-specific, too, of course. You’ll likely need an over-arching Updates RFC for all of those to IANA register OSCORE.

-d

> On Mar 26, 2023, at 11:11 AM, Christian Amsüss <[e-mail]> wrote:
> 
> Hello DNR authors and -group,
> hello CoRE group (as this mainly affects OSCORE based protocols),
> 
> (Context)
> A protocol of the CoRE group, DNS-over-CoAP[1], when used with
> encryption (as is recommended), can use either of two security
> mechanisms: DTLS and OSCORE, with some expectations that the latter will
> be used a lot.
> 
> Following DNSOP suggestions in for draft-ietf-core-dns-over-coap, I've
> looked at the DNR draft from the point of view of advertising
> DNS-over-CoAP services. While announcing DNS-over-CoAP-over-DTLS would
> be straightforward[^2], there is no clear path yet about how OSCORE
> protected services would be announced. This path is about to be
> explored, with no apparent need for ADD interaction -- except for one
> detail:
> 
> (Proposal)
> DNR currently mandates that the SvcParams field 'MUST include at least
> "alpn" SvcParam"'. Given that ALPN is specific to TLS at least since
> RFC8447, that mandate rules out any advertisement of secure
> communication that is not TLS based.
> 
> I suggest to say
> 
>> This field MUST include at least "alpn" SvcParam (...), *or an SvcParam
>> that indicates some other security and disambiguation mechanism*.
> 
> Depending on the requirements that led to the "MUST" in the first place,
> it may be necessary to add that
> 
>> In the latter case, that SvcParam MUST be included in the "mandatory"
>> SvcParam.
> 
> Please let me know if this is the preferred way to support non-TLS
> protocols, and the change is motivated sufficiently in this mail. I'm
> confident we paint a more concrete picture of how this would play out in
> collaboration with the OSCORE and EDHOC authors, but that activity is
> just getting started after having been made aware of SVCB through DNR,
> so it may take until after the current meeting to provide the additional
> motivation.
> 
> 
> Best regards
> Christian
> 
> 
> [1]: https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/
> 
> [^2]: This will need some text somewhere stating how it extends on the
> CoAP-over-TLS ALPN, but nothing major.
> 
> -- 
> I shouldn't have written all those tank programs.
>  -- Kevin Flynn