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

[[e-mail]]

Hi Christian, 

Thank you for raising this point.

I think that you have a reasonable exception case where alpn may not be present. So, rather than "MUST alpn or ..." you proposed, I suggest the candidate changes at: https://tinyurl.com/latest-dnr-changes.

Please check and let me know if this works for you. Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : Christian Amsüss <[e-mail]>
> Envoyé : dimanche 26 mars 2023 19:01
> À : [e-mail]
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : DNR: Mandatory ALPN indication and non-TLS protocols (eg.
> OSCORE)
> 
> 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.