Re: [DNSOP] [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap

[Martine Sophie Lenders]

Hi!

Martine Lenders, here, one of the co-authors of the draft.

Indeed, as Carsten already stated: Using OSCORE is one of our main use 
cases, using a compressed format for DNS messages is another.


We implemented both DNS over DTLS and DNS over CoAP (DoC), including the 
variants DNS over CoAPS and DNS over OSCORE, for our evaluation of DoC 
[1]. It shows DNS over OSCORE to be in advantage compared to both DNS 
over DTLS or DNS over CoAPS. Yes, compared to DNS over DTLS it adds 
complexity, at least upfront, but it can be assumed that CoAP/OSCORE is 
already present for the application. This amortizes this disadvantage to 
only the construction and parsing of DNS messages. With DNS over DTLS 
(assuming we even use transport encryption with CoAP) we still need to 
implement the state machine of DNS over DTLS, in addition to DNS message 
handling. On the other hand side, we gain additional advantages from the 
CoAP feature set when using DoC, such as block-wise transfer and, as 
previously discussed, en route caching. The latter would also become 
possible in an end-to-end encrypted way with [2].  Some of these 
advantages are mentioned in Section 1 of the draft.


For a compressed message format, we plan to provide a separate draft in 
the future, in an attempt to keep things simple and to easily make that 
content type also usable, e.g., with DoH.


Another use case is the usage of encrypted DNS over Low-Power WANs, 
e.g., LoRaWAN. Here, due to the transport encryption with DTLS, 
compression to fit the small PDUs and handle the low data rates [3], is 
not straightforward. As OSCORE encrypts on the application layer, 
however, we are able to compress most of the surrounding metadata away 
[4], and purely transport the encrypted payload.


Lastly, another possible use cases, which we did not evaluate in any way 
yet, would be an encrypted version of mDNS and thus DNS-SD, utilizing 
OSCORE group communication [5]. Multicast encryption is not covered by 
either of the other encrypted DNS-over-X solutions so far.


Best regards
Martine

[1] https://arxiv.org/pdf/2207.07486.pdf
[2] https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore
[3] https://datatracker.ietf.org/doc/rfc8724
[4] https://datatracker.ietf.org/doc/rfc8824
[5] https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm

Am 15.08.22 um 20:09 schrieb Carsten Bormann:

On 15. Aug 2022, at 19:41, Ted Lemon  wrote:

On Aug 15, 2022, at 1:34 PM, Carsten Bormann  wrote:

On 15. Aug 2022, at 17:11, Ted Lemon  wrote:

This is a good question. I think we’d want to understand what the actual use 
case is for DNS-over-CoAP before proceeding with this,

The main use case is systems that already implement CoAP and do not want to add 
machinery for some protocols that are used only for very specific purposes.

You’re going to have to construct a DNS packet. I presume CoAP is using DTLS,

DTLS is one choice, defined in RFC 7252.  Newer constrained implementation 
often look at OSCORE instead, RFC 8613.


so you have to have DTLS. So again, I don’t see how this reduces complexity. It 
seems like it adds complexity.

I haven’t checked this, but I would expect there are enough differences in how 
DNSoDTLS uses DTLS that the complexity of getting this right exceeds that of 
using CoAP.


I’ll leave that to the authors; obviously, all caches have limitations, but 
being able to make use of CoAP caches along the way would be an improvement.

It is not a given that caching with CoAP makes things better. What is CoAP’s 
caching behavior? How will it handle short TTLs? Reading the document, it’s 
clear this has not been considered.

The -00 version does not have to solve those problems.  Slideware does exist 
for them...


Given that the whole point of this is to make DNS connections private, I would 
assume that the cache shouldn’t have the credentials to peek into the packet. 
Except that it must. So I really don’t understand the threat model here.

OSCORE was designed to offer some capabilities in this regard.  I’m sure a 
future document will include examples for that.
But this is work that best can be done in the working group, between 
implementers and experts for the specific protocols and their caching behaviors.


That can definitely be done (for a definition of “compress” — a concise form 
for some DNS data might be a better approach), but it to me it seemed working 
out the protocol machinery first is the right way to proceed here.  (From the 
point of view of the CoAP protocol, this would just be a separate media type.)

I don’t think this is true. Just because you can do something doesn’t mean you 
should. Until we can come up with some use case for this that solves a problem 
that isn’t already solved, I don’t think the IETF should be pursuing this work 
at all.

It seems to me you are basing this view on a scan of the individual submission 
document.
WG discussions have happened (and many WG members are also cognizant of, e.g., 

Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

[Martine Sophie Lenders]

Hi,

Sorry for the late reply, I was away from any keyboard for the past two 
weeks.


I think there might be a misunderstanding regarding the CNAME behavior, 
due to some poor wording in our draft: The CNAMEs should, of course, 
only be resolved in such a way, if the queried record was an A or  
record. This does not, to my understanding, contradict the behavior 
described for CNAMEs in RFC 1034. We propose a different wording for the 
first sentence in 5.1 to prevent such misunderstandings in the future:


    In the case of CNAME records in a DNS response to an A or  
record query, a DoC server SHOULD follow common DNS resolver behavior 
[RFC1034 
] 
by resolving a CNAME until the originally requested resource record type 
is reached.


Regarding the population of the additional section, we also follow 
recommendations in RFC 1034, to only include records useful to the 
client. We deem this particularly noteworthy when it comes to DNS, as 
from our analysis of DNS traffic, responses can become quite large due 
to an abundance of records in the Additional section. With the message 
size constraints in LLNs, it might thus be necessary to prune the DNS 
message for records actually useful to the querying DoC client.


Lastly, mind, that, at least in our model for DoC, a DoC client does not 
further distribute the information it gathered via DoC.


Regards
Martine

Am 06.09.22 um 17:06 schrieb Ben Schwartz:

Some further notes on this draft.

Section 5.1 says that a DoC server "SHOULD" follow CNAMEs. This is a 
misunderstanding of the nature of DNS transports. DoC is a DNS 
transport, like DoT and DoH.  The choice of transport is independent 
of the DNS server's answering behavior, which must not be modified by 
the transport. Indeed, DPRIVE is now chartered to enable the use of 
alternate transports for recursive-to-authoritative queries for which 
CNAME following has entirely different rules.  This is possible 
precisely because the choice of transport does not alter the logical 
DNS contents.


Section 5.1 also proposes that the population of the Additional 
section might follow different logic when using DoC.


Modifying the logical DNS behavior would create a wide range of 
exciting and unpredictable compatibility issues when trying to use a 
new transport.  I urge the authors to delete Section 5.1, which would 
resolve this problem.  The draft could instead note that the DNS 
queries and responses are not modified when using DoC, except under 
private arrangement between the client and server.


On Fri, Sep 2, 2022 at 12:20 PM Jaime Jiménez  wrote:

Dear CoRE WG,

Thanks to the authors and the reviewers that provided comments on
the list for this draft. Given the in-room support and the list
discussion during the WGA the chairs believe that there is
sufficient support for the adoption of this document in CoRE.

The authors are advised to resubmit the draft-core-dns-over-coap
and to set up a document repo under the CoRE Github organization
at https://github.com/core-wg

BR,

Jaime Jiménez on behalf of the CoRE chairs.

On 15.8.2022 11.26, Jaime Jiménez wrote:

Dear CoRE WG,

We would like to start the call for adoption on draft-lenders-dns-over-coap.
The draft defines a protocol for sending DNS messages over secure CoAP 
(DTLS and/or OSCORE). The draft was discussed during IETF114 and on IETF113 and 
was well-received by the group.

https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/  


During the last IETF meeting there were no objections for adoption so we 
confirm this now on the mailing list. Please let us know if you support 
adopting this draft. As many people will still be on vacation, we the WGA call 
will last a couple of weeks, ending the/1st of September/.

Note that DNSOP and DPRIVE are in the loop as the draft is relevant for 
their working groups too.

BR,
-- 
Jaime Jiménez


___
core mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/core


-- 
Jaime Jiménez


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
core mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/core
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

[Martine Sophie Lenders]

Hi Ben, Hi Carsten,

thanks for your suggestions, Ben! It seems a good idea to clarify 
options for compactification of DNS messages in a separate document, 
since the compactification is indeed not bound to CoAP. We will prepare 
such a draft until the cut-off for IETF 115, so we can discuss whether 
we keep or remove Section 5.1 at the IETF meeting in London. Would that 
work for you?


I tend to agree with Carsten. At least with the current wording (or the 
proposed), the restatements may lead to confusion, but some guidelines 
for the constrained use case should IMHO be part of the document, even 
if only in reference to the new document proposed.


Best
Martine

Am 20.09.22 um 18:17 schrieb Carsten Bormann:

I think we are falling into the restatement antipattern.

This antipattern happens when documents restate mandates from their 
references, invariably creating confusion if this is just a 
restatement or actually new normative text that replaces or updates 
text from the dependency. Don’t do that.


Examples can be put into their own section and clearly marked as such.

Grüße, Carsten

Sent from mobile, sorry for terse

On 20. Sep 2022, at 17:12, Ben Schwartz 
 wrote:



Martine,

Thanks for the proposed updated text regarding CNAMEs.  I agree that 
it is an improvement, but I still think it would be better to omit 
entirely.  By writing that implementations SHOULD follow RFC 1034, 
you imply that they are permitted not to, which seems objectionable.  
I think it would be much clearer to simply say that use of DoC does 
not alter the DNS message contents.


I feel similarly about the Additional section.  If you think that it 
would be useful to deviate from ordinary practices regarding the 
Additional section, I think this should be in a separate draft on 
compact DNS responses, not coupled to DoC.  For example, such 
compactification might be even more relevant to UDP Do53 than to DoC.


--Ben

On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders 
 wrote:


Hi,

Sorry for the late reply, I was away from any keyboard for the
past two weeks.

I think there might be a misunderstanding regarding the CNAME
behavior, due to some poor wording in our draft: The CNAMEs
should, of course, only be resolved in such a way, if the queried
record was an A or  record. This does not, to my
understanding, contradict the behavior described for CNAMEs in
RFC 1034. We propose a different wording for the first sentence
in 5.1 to prevent such misunderstandings in the future:

    In the case of CNAME records in a DNS response to an A or
 record query, a DoC server SHOULD follow common DNS resolver
behavior [RFC1034

<https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-00.html#RFC1034>]
by resolving a CNAME until the originally requested resource
record type is reached.

Regarding the population of the additional section, we also
follow recommendations in RFC 1034, to only include records
useful to the client. We deem this particularly noteworthy when
it comes to DNS, as from our analysis of DNS traffic, responses
can become quite large due to an abundance of records in the
Additional section. With the message size constraints in LLNs, it
might thus be necessary to prune the DNS message for records
actually useful to the querying DoC client.

Lastly, mind, that, at least in our model for DoC, a DoC client
does not further distribute the information it gathered via DoC.

Regards
Martine

Am 06.09.22 um 17:06 schrieb Ben Schwartz:

Some further notes on this draft.

Section 5.1 says that a DoC server "SHOULD" follow CNAMEs.  This
is a misunderstanding of the nature of DNS transports.  DoC is a
DNS transport, like DoT and DoH.  The choice of transport is
independent of the DNS server's answering behavior, which must
not be modified by the transport.  Indeed, DPRIVE is now
chartered to enable the use of alternate transports for
recursive-to-authoritative queries for which CNAME following has
entirely different rules.  This is possible precisely because
the choice of transport does not alter the logical DNS contents.

Section 5.1 also proposes that the population of the Additional
section might follow different logic when using DoC.

Modifying the logical DNS behavior would create a wide range of
exciting and unpredictable compatibility issues when trying to
use a new transport.  I urge the authors to delete Section 5.1,
which would resolve this problem.  The draft could instead note
that the DNS queries and responses are not modified when using
DoC, except under private arrangement between the client and server.

On Fri, Sep 2, 2022 at 12:20 PM Jaime Jiménez  wrote:

Dear CoRE WG,

Thanks to the authors and the reviewers that provided
comments on the list for this dra

Re: [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

[Martine Sophie Lenders]

Hi!

Am 21.09.22 um 21:31 schrieb Ben Schwartz:

Preparing a separate document on compact DNS seems like a fine start to me.


We just published Version -01 of the draft [1]. The most significant 
change in regard to this discussion is that Section 5.1 was now moved to 
its own draft [2]. We are happy to discuss this, e.g., in the DNSOP WG 
meeting or F2F during a break at IETF 115, if the WG meeting agenda does 
not allow for this anymore.


The full listing of changes to the DoC draft can be found in Appendix A 
of [1].


Cheers
Martine

[1] https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/01/
[2] https://datatracker.ietf.org/doc/draft-lenders-dns-cns/



On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders 
mailto:m.lend...@fu-berlin.de>> wrote:


Hi Ben, Hi Carsten,

thanks for your suggestions, Ben! It seems a good idea to clarify
options for compactification of DNS messages in a separate document,
since the compactification is indeed not bound to CoAP. We will
prepare such a draft until the cut-off for IETF 115, so we can
discuss whether we keep or remove Section 5.1 at the IETF meeting in
London. Would that work for you?

I tend to agree with Carsten. At least with the current wording (or
the proposed), the restatements may lead to confusion, but some
guidelines for the constrained use case should IMHO be part of the
document, even if only in reference to the new document proposed.

Best
Martine

Am 20.09.22 um 18:17 schrieb Carsten Bormann:

I think we are falling into the restatement antipattern.

This antipattern happens when documents restate mandates from
their references, invariably creating confusion if this is just a
restatement or actually new normative text that replaces or
updates text from the dependency. Don’t do that.

Examples can be put into their own section and clearly marked as
such.

Grüße, Carsten

Sent from mobile, sorry for terse


On 20. Sep 2022, at 17:12, Ben Schwartz

<mailto:bemasc=40google@dmarc.ietf.org> wrote:


Martine,

Thanks for the proposed updated text regarding CNAMEs.  I agree
that it is an improvement, but I still think it would be better
to omit entirely.  By writing that implementations SHOULD follow
RFC 1034, you imply that they are permitted not to, which seems
objectionable.  I think it would be much clearer to simply say
that use of DoC does not alter the DNS message contents.

I feel similarly about the Additional section.  If you think that
it would be useful to deviate from ordinary practices regarding
the Additional section, I think this should be in a separate
draft on compact DNS responses, not coupled to DoC.  For example,
such compactification might be even more relevant to UDP Do53
than to DoC.

--Ben

On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders
mailto:m.lend...@fu-berlin.de>> wrote:

Hi,

Sorry for the late reply, I was away from any keyboard for
the past two weeks.

I think there might be a misunderstanding regarding the CNAME
behavior, due to some poor wording in our draft: The CNAMEs
should, of course, only be resolved in such a way, if the
queried record was an A or  record. This does not, to my
understanding, contradict the behavior described for CNAMEs
in RFC 1034. We propose a different wording for the first
sentence in 5.1 to prevent such misunderstandings in the future:

    In the case of CNAME records in a DNS response to an A or
 record query, a DoC server SHOULD follow common DNS
resolver behavior [RFC1034

<https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-00.html#RFC1034>]
 by resolving a CNAME until the originally requested resource record type is reached.

Regarding the population of the additional section, we also
follow recommendations in RFC 1034, to only include records
useful to the client. We deem this particularly noteworthy
when it comes to DNS, as from our analysis of DNS traffic,
responses can become quite large due to an abundance of
records in the Additional section. With the message size
constraints in LLNs, it might thus be necessary to prune the
DNS message for records actually useful to the querying DoC
client.

Lastly, mind, that, at least in our model for DoC, a DoC
client does not further distribute the information it
gathered via DoC.

Regards
Martine

Am 06.09.22 um 17:06 schrieb Ben Schwartz:

Some further notes on this draft.

Section 5.1 says that a DoC server "SHOULD" follow CNAMEs. 
This is a misunderstanding of the nature of DNS transports. 
DoC is a DNS transport, like DoT and DoH.  T

[DNSOP] draft-ietf-core-dns-over-coap-01 (was [core] WGA call for draft-lenders-dns-over-coap)

[Martine Sophie Lenders]

Hello Ben,

Thanks for the feedback! We will account for that in the next version of 
the DoC draft (-02) ASAP.


Some discussion regarding the ALPN ID (3) already started here: 
https://github.com/core-wg/draft-dns-over-coap/issues/22, something 
similar for OSCORE might also be required.


Best
Martine

On 24.10.22 22:12, Ben Schwartz wrote:
Thanks for this update.  I think the DoC draft is much improved by this 
separation.


On DoC:

0. Why isn't DoH via CoAP gateway sufficient?  The draft should 
explain.  If the answer is message size overhead, please put a number on it.


1. The TTL rewriting proposed here is notably different from DoH.  I 
think I understand the reason for the divergence but it's not explained 
in the draft.


2. Does DoC live at a URI path?  I assume it does, but I couldn't tell 
from the draft.  If so, consider defining a default path, if this is a 
common practice in CoAP.  In HTTP, default paths are generally 
forbidden, so DoH doesn't have one.  This has been inconvenient.


3. I recommend adding a section describing how to bootstrap DoC in a 
SVCB-DNS record.  I think this may require you to allocate a new ALPN ID 
for CoAP/DTLS (e.g. "coap-dtls").




I don't think the "compact DNS" proposal is worthwhile, at least in the 
current framing.  The normal DNS message format is already quite well 
optimized for compactness, and recursive resolvers rarely return 
something that is unlikely to be useful.  I think this draft would have 
a really minimal impact on the typical message size distribution.  Also, 
DNS is typically used to bootstrap something else, so a small savings in 
DNS overhead becomes negligible for the system as a whole.


The draft also seems to contain a misconception about what is optional 
in CNAME handling: there is no situation in which a stub resolver will 
chase a CNAME chain.  That is always the recursive resolver's job.


On Mon, Oct 24, 2022 at 2:25 PM Martine Sophie Lenders 
mailto:m.lend...@fu-berlin.de>> wrote:


Hi!

Am 21.09.22 um 21:31 schrieb Ben Schwartz:
 > Preparing a separate document on compact DNS seems like a fine
start to me.

We just published Version -01 of the draft [1]. The most significant
change in regard to this discussion is that Section 5.1 was now
moved to
its own draft [2]. We are happy to discuss this, e.g., in the DNSOP WG
meeting or F2F during a break at IETF 115, if the WG meeting agenda
does
not allow for this anymore.

The full listing of changes to the DoC draft can be found in Appendix A
of [1].

Cheers
Martine

[1]
https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/01/
<https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/01/>
[2] https://datatracker.ietf.org/doc/draft-lenders-dns-cns/
<https://datatracker.ietf.org/doc/draft-lenders-dns-cns/>

 >
 > On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders
 > mailto:m.lend...@fu-berlin.de>
<mailto:m.lend...@fu-berlin.de <mailto:m.lend...@fu-berlin.de>>> wrote:
 >
 >     Hi Ben, Hi Carsten,
 >
 >     thanks for your suggestions, Ben! It seems a good idea to clarify
 >     options for compactification of DNS messages in a separate
document,
 >     since the compactification is indeed not bound to CoAP. We will
 >     prepare such a draft until the cut-off for IETF 115, so we can
 >     discuss whether we keep or remove Section 5.1 at the IETF
meeting in
 >     London. Would that work for you?
 >
 >     I tend to agree with Carsten. At least with the current
wording (or
 >     the proposed), the restatements may lead to confusion, but some
 >     guidelines for the constrained use case should IMHO be part
of the
 >     document, even if only in reference to the new document proposed.
 >
 >     Best
 >     Martine
 >
 >     Am 20.09.22 um 18:17 schrieb Carsten Bormann:
 >>     I think we are falling into the restatement antipattern.
 >>
 >>     This antipattern happens when documents restate mandates from
 >>     their references, invariably creating confusion if this is
just a
 >>     restatement or actually new normative text that replaces or
 >>     updates text from the dependency. Don’t do that.
 >>
 >>     Examples can be put into their own section and clearly marked as
 >>     such.
 >>
 >>     Grüße, Carsten
 >>
 >>     Sent from mobile, sorry for terse
 >>
 >>>     On 20. Sep 2022, at 17:12, Ben Schwartz
 >>>     mailto:40google@dmarc.ietf.org>>
 >>>     <mailto:bemasc <mailto:bemasc>=40go

[DNSOP] Next steps: draft-ietf-core-dns-over-coap

[Martine Sophie Lenders]

Hi!

we, the authors of draft-ietf-core-dns-over-coap, are planning to 
present on DNS over CoAP at the next core interim (and at IETF 117) again.


In preparation for that, there are still some things to do and discuss 
ahead:


Discussions on 'ALPN "coap" for DTLS' [1] and 'Using SVCB with 
OSCORE/EDHOC' [2] somewhat got stalled. For our document, I think we 
need at least confirmation or decline that the "coap" ALPN could be used 
for DTLS, SVCB for OSCORE/EDHOC, I think is out of scope at the moment 
anyways.


Furthermore, there is still an open question, if DoC can or should be 
translated at a CoAP-HTTP proxy to DoH. Namely, how the FETCH that DoC 
uses should be translated into the POST/GET of DoH [3].


And last but not least, is there further feedback we did not address yet 
or is there new feedback that you want us to address?


Best
Martine

[1] https://mailarchive.ietf.org/arch/msg/core/I_vkEz046qEWQKGh6dOE1WobIM4/
[2] https://mailarchive.ietf.org/arch/msg/core/QnZdheePgNi3HspxDpmreu3pbxU/
[4] 
https://github.com/core-wg/draft-dns-over-coap/blob/main/draft-ietf-core-dns-over-coap.md#using-a-coap-http-proxy-to-translate-to-doh-seccoap-http-proxy


OpenPGP_0xD3555B9E03C098C7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Next steps: draft-ietf-core-dns-over-coap

[Martine Sophie Lenders]

Hi Ben,

On 23.06.23 22:23, Ben Schwartz wrote:
I think it would be helpful if this document were more explicit about 
its motivation.  In my view, the underlying motivation for this draft is 
to enable seamless management of DNS service within a CoAP-centered 
deployment, by sharing key distribution, access controls, monitoring, 
etc.  The draft claims various performance benefits from DoC, but these 
are unproven and seem unlikely to be significant.


We have a paper on the performance benefits just accepted for CoNEXT, 
which we will cite once it is published. An early pre-print (the final 
paper underwent some major revisions though) is available on arXiv [5].



...

For our document, I think we
need at least confirmation or decline that the "coap" ALPN could be
used
for DTLS, SVCB for OSCORE/EDHOC, I think is out of scope at the moment
anyways.

I'm not sure I follow, but using the same ALPN for multiple transports 
renders that ALPN permanently incompatible with SVCB.  I recommend 
keeping "coap" for TLS/TCP only, and defining a new ALPN ID for CoAP/DTLS.


That makes things clearer for us. In the next version we will word the 
draft in accordance to that: only the "coap" is ALPN for TLS/TCP is 
available at the moment. For DTLS and OSCORE alternative approaches need 
to be created (see [1] and [2] in my original mail) which are, however, 
out of scope of the DoC document, in my opinion.



Furthermore, there is still an open question, if DoC can or should be
translated at a CoAP-HTTP proxy to DoH. Namely, how the FETCH that DoC
uses should be translated into the POST/GET of DoH [3].

I don't think there is any need to specify this.  A DoC server could act 
as a forwarder to an upstream using DoH, DoQ, etc. in accordance with 
the relevant standards, without impacting its compliance as a DoC server.


However, this does resemble a concern I've previously raised: the draft 
does not explain why it is necessary to define a new DoC mechanism, 
rather than simply forwarding RFC 8484 DoH through a CoAP-HTTP proxy.


This question was raised in reaction to your concern, actually. Note, 
that if a proxy is used, the target resource needs to be mentioned in 
the CoAP header, increasing the overall packet size, so a proxy should 
be kept optional. Forwarding DoH through a C-H-proxy would make the 
proxy mandatory. In addition, DoC is greatly benefiting from its usage 
of the CoAP-only FETCH method (see [5]).


The question is more a CoRE question, I think. RFC 8132 does not really 
specify, how FETCH should be translated via a C-H-proxy, so I assume it 
to be use-case dependent. Should the draft specify this for the DoC use 
case, and if yes which method should be used, or should the DoC server 
just act as a recursive resolver, using DoH towards the DNS infrastructure?


Best
Martine

[5] https://arxiv.org/abs/2207.07486


OpenPGP_0xD3555B9E03C098C7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-ietf-core-dns-over-coap-04.txt

[Martine Sophie Lenders]

FYI

 Forwarded Message 
Subject: New Version Notification for draft-ietf-core-dns-over-coap-04.txt
Resent-From: martine.lend...@tu-dresden.de
Date: Mon, 23 Oct 2023 19:47:01 +
From: internet-dra...@ietf.org 
To: Thomas C. Schmidt , Cenk Gündoğan 
, Christian Amsüss , 
Matthias Waehlisch , Cenk Gundogan 
, Christian Amsuess , 
Martine Lenders , Martine Lenders 
, Matthias Waehlisch 
, Thomas Schmidt 



A new version of Internet-Draft draft-ietf-core-dns-over-coap-04.txt has 
been

successfully submitted by Martine Lenders and posted to the
IETF repository.

Name: draft-ietf-core-dns-over-coap
Revision: 04
Title:DNS over CoAP (DoC)
Date: 2023-10-23
Group:core
Pages:16
URL: 
https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-04.txt

Status:   https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/
HTML: 
https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-04.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-core-dns-over-coap-04


Abstract:

   This document defines a protocol for sending DNS messages over the
   Constrained Application Protocol (CoAP).  These CoAP messages are
   protected by DTLS-Secured CoAP (CoAPS) or Object Security for
   Constrained RESTful Environments (OSCORE) to provide encrypted DNS
   message exchange for constrained devices in the Internet of Things
   (IoT).



The IETF Secretariat




smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-lenders-dns-cbor-05.txt

[Martine Sophie Lenders]

FYI


 Forwarded Message 
Subject: New Version Notification for draft-lenders-dns-cbor-05.txt
Resent-From: martine.lend...@tu-dresden.de
Date: Mon, 23 Oct 2023 19:55:59 +
From: internet-dra...@ietf.org 
To: Thomas C. Schmidt , Matthias Waehlisch 
, Carsten Bormann , 
Martine Lenders , Martine Lenders 
, Matthias Waehlisch 
, Thomas Schmidt 



A new version of Internet-Draft draft-lenders-dns-cbor-05.txt has been
successfully submitted by Martine Lenders and posted to the
IETF repository.

Name: draft-lenders-dns-cbor
Revision: 05
Title:A Concise Binary Object Representation (CBOR) of DNS Messages
Date: 2023-10-23
Group:Individual Submission
Pages:20
URL:  https://www.ietf.org/archive/id/draft-lenders-dns-cbor-05.txt
Status:   https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/
HTML: https://www.ietf.org/archive/id/draft-lenders-dns-cbor-05.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-lenders-dns-cbor-05


Abstract:

   This document specifies a compressed data format of DNS messages
   using the Concise Binary Object Representation [RFC8949].  The
   primary purpose is to keep DNS messages small in constrained
   networks.



The IETF Secretariat




smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNS in Constrained Network Scenarios

[Martine Sophie Lenders]

Hi!

This morning I presented two drafts in DNSOP:

- https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/, DNS 
over CoAP (currently discussed in core WG), and
- https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/, CBOR of DNS 
Messages (currently discussed in cbor WG)


We would be happy about your input on both of these drafts.

Ben raised the point during the meeting that a new data format, such as 
CBOR of DNS has issues and referenced the JSON document presented 
before. As far as I understood, the problem there was that there was 
just no representation of EDNS(0) records specified. This is not an 
issue with the CBOR format because of the following reasons: (a) there 
is a dedicated format for EDNS records specified. (b) if a record is, 
for any reason, not representable in CBOR, one can always fallback to 
the “classic” binary format of the resource record. This means, the 
format as specified in RFC 1035, section 3.2.1, is carried it as a byte 
string within the CBOR object (which itself is in a binary format), see 
Section 3.2 of the CBOR draft. So in that sense, CBOR of DNS is 
future-proof as long as such new resource records are parsable by a 
classic DNS parser as well.


For a quick introduction into the message format, I invite you to take a 
look at the beginning (slides 4-7) of my talk I gave in the CBOR WG. I 
did not include these details in my DNSOP talk in the interest of time: 
https://youtu.be/R1l8SBjnjQg?t=1599 (slides: 
https://datatracker.ietf.org/meeting/118/materials/slides-118-cbor-draft-lenders-dns-cbor-01.pdf)


Best
Martine


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS in Constrained Network Scenarios

[Martine Sophie Lenders]

Hi Ben, hi Jerry,

On 10.11.23 22:55, Ben Schwartz wrote:

My point was not really related to EDNS.

My main point is that the last time someone attempted to write a new 
format for DNS messages in DNSOP, it ended up in the Independent Stream, 
because standardizing these things isn't easy.  There are a lot of 
opinions and considerations.


One of the key considerations in that discussion, and also in this one, 
is the need to avoid ossification by moving a portion of the DNS 
ecosystem to a representation that cannot evolve in the same way as 
standard DNS.  This might explain why RFC 8427 (which tries hard to be 
isomorphic to the DNS message format) is totally different from the most 
widely used DNS JSON format 
(https://developers.google.com/speed/public-dns/docs/doh/json#api-specification ).


The advantage of the CBOR-Format here is, I think, that we can and do 
represent fields still in their binary or numerical format (e.g., flags 
or rdata). So we might prevent ossification already: On one hand we do 
not have very specific maps (the CBOR equivalent to JSON objects) in the 
first place (like in most JSON formats I have seen), just arrays. On the 
other, we allow for as much as necessary to be in the original format.


You might solve this by showing that your representation really is 
isomorphic to standard DNS, both now and for any reasonable future 
extensions.  Alternatively, you might want to specify a very restrictive 
"CoAP DNS lookup API", emphasizing that this is not a fully-featured DNS 
format.


Intuitively, I would say it is isomorphic. We'll try to find a formal 
way to prove this.


Either way, I think the work will need extensive discussion and review 
here in DNSOP.


Agreed!

On 13.11.23 09:44, Jerry Lundström wrote:
> On 11/10/23 22:55, Ben Schwartz wrote:
>> Alternatively, you might want to specify a very restrictive "CoAP DNS
>> lookup API", emphasizing that this is not a fully-featured DNS format.
>
> +1 to this!
>
> I admit I don't know much about CoAP but by the description during the
> presentation, being constrained in all it's ways, and that CoAP devices
> will likely never be able to process things like DNSSEC, a lookup
> service seems much more fitting.

The hope is, that even protocols like DoH might benefit from the small 
message footprint.


Regarding DNSSEC: We discussed this in the context of our research 
project already, and there exists a rough, private draft for an 
extension for the CBOR format. We still need to look into more detail if 
and how sensible it is to get this into the mainline format.


Best
Martine


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS in Constrained Network Scenarios

[Martine Sophie Lenders]

Hi Jerry,

On 16.11.23 13:36, Jerry Lundström wrote:

Hi Martine,

On 11/16/23 11:51, Martine Sophie Lenders wrote:


Regarding DNSSEC: We discussed this in the context of our research 
project already, and there exists a rough, private draft for an 
extension for the CBOR format. We still need to look into more detail 
if and how sensible it is to get this into the mainline format.


My point here was, unless you're suppose to run (for example) Unbound on 
a CoAP device using DNS-over-CoAP then there is no need to full support 
DNS wire-format in CBOR.  From the presentation it did not sound like 
this but then again I know very little about CoAP environments.


Going down this path, to fully support DNS wire-format in another 
format, feels a lot like cloning the camel.


Please don't clone the camel!


I might be cloning a camel, so to say, but I also throw out a bunch of 
genes that are not expressed in that particular camel anyway and half 
the number of base pairs in that process. ;-)


Cheers
Martine



Cheers,
Jerry

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Re: [core] Re: Fwd: WG Adoption Call for draft-lenders-core-coap-dtls-svcb

[Martine Sophie Lenders]

Hi Med,

On 29.07.24 13:56, mohamed.boucad...@orange.com wrote:

Hi Carsten, all,

There is a mismatch between what is claimed in the abstract/into vs. 
core documents. Concretely, when reading “This document specifies the 
usage of Service Parameters..” or “This document specifies which 
information from SvcParams ..”, I thought this is a discussion about the 
applicability of existing parameters per 
https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml to CoAP. 
However, the doc focuses on alpn. It seems to me that the main 
contribution is to register an ALPN ID for CoAP over DTLS (i.e., Section 
5.1).


Noted, we will adapt the presentation for -01.

Is there any specific reason why this request is not made as part of 
I-D.ietf-core-dns-over-coap?


We thought about this, but in the end, CoAP over DTLS is used in other 
contexts than just DNS over CoAP. Given that CoAP over TLS defines its 
ALPN ID in its RFC, and CoAP over DTLS was just too early for that, we 
thought it's better to have the ALPN ID for CoAP over DTLS to be its own 
document.


Best
Martine



Cheers,

Med

*De :* Carsten Bormann 
*Envoyé :* lundi 29 juillet 2024 12:17
*À :* c...@ietf.org
*Cc :* dnsop@ietf.org
*Objet :* [core] Fwd: WG Adoption Call for draft-lenders-core-coap-dtls-svcb


Resending as there appears to be a mail forwarding problem.

 Forwarded Message 

*Subject: *



WG Adoption Call for draft-lenders-core-coap-dtls-svcb

*Date: *



Mon, 29 Jul 2024 11:59:31 +0200

*From: *



Marco Tiloca  

*To: *



c...@ietf.org  


*CC: *



dnsop@ietf.org 



Dear all,

During the CoRE session at IETF 120, there was in-room consensus on
the WG supporting the adoption of draft-lenders-core-coap-dtls-svcb [1].

As presented in [2], the present document is part of the "DNS over
CoAP bundle", and it is a normative reference for
draft-ietf-core-dns-over-coap specifying DNS over CoAP [3].
Therefore, having the present document adopted by the WG is a
pre-requirement for having a WG Last Call on [3].


This mail starts a 3 week Working Group Adoption Call for
draft-lenders-core-coap-dtls-svcb [1], giving some more time than
usual due to the holiday season.

Please provide your feedback by replying to this mail before Monday,
19 August 2024.

(This call for adoption has also DNSOP in CC for gathering any
technical input)

Best,
/Marco


[1]
https://datatracker.ietf.org/doc/draft-lenders-core-coap-dtls-svcb/


[2]

https://datatracker.ietf.org/meeting/120/materials/slides-120-core-dns-service-binding-records-with-coap-00.pdf
 


[3] https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/



-- 


Marco Tiloca

Ph.D., Senior Researcher

Phone: +46 (0)70 60 46 501

RISE Research Institutes of Sweden AB

Box 1263

164 29 Kista (Sweden)

Division: Digital Systems

Department: Computer Science

Unit: Cybersecurity

https://www.ri.se  


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.


___
core mailing list -- c...@ietf.org
To unsubscribe send an email to core-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Light weight encrypted DNS proposal

[Martine Sophie Lenders]

Hi Vint,

are you aware about [1]? With OSCORE [2] and EDHOC [3] it pretty much 
aligns with your idea, as far as I can see, and would also provide you 
with a key exchange mechanism for free.


Best
Martine

[1] https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/
[2] https://www.rfc-editor.org/rfc/rfc8613.html
[3] https://www.rfc-editor.org/rfc/rfc9528.html

On 15.08.24 00:06, Vint Joseph wrote:

Hello All,

I hope you're all doing well.

We wanted to share an idea regarding encrypted DNS and get your thoughts 
on it. Our goal is to make the setup for encrypted DNS as simple as our 
current DNS setup. Here are a few key points:
- Simplicity: Ideally, the setup should be as straightforward as 
possible, using UDP and only one or two packets.
- Cost Efficiency: The encryption and decryption processes should not 
introduce significant overhead.
- Stateless Approach: Maintaining state on both the client and server 
sides is costly. While we might not be able to completely move out of 
stateless ideas, we try to maintain this core concept
- UDP Benefits: Using UDP can help avoid the head-of-line blocking 
issues we see with TCP.
- Considering QUIC: While QUIC is a potential solution, it has its own 
complexities, including retransmission mechanisms. We're okay with some 
packet loss if retransmitting DNS queries remains simple (one or two 
packets).
- Crypto Agility: This idea prioritizes simplicity and doesn't fully 
address the need for crypto agility.
I would greatly appreciate your input on this approach and any 
suggestions you might have for improvement.


The core idea/synopsis
We plan to implement a system using elliptic curve cryptography. A 
preshared key, referred to as the public key G^S, is distributed from 
the dns server to the client. The server retains the private key S and 
the corresponding public key G^S, while the client receives the public 
key G^S. When the client needs a DNS response, it generates a key pair 
consisting of a private key C and a public key G^C. The client then 
sends a DNS request encrypted with the shared key G^CS and includes its 
public key G^C in the DNS extension. Upon receiving the public key G^C, 
the DNS server computes the shared key G^CS using its private key S and 
the client's public key G^C. These are ephemeral keys, ensuring that 
each DNS packet has its own session keys. The DNS server responds to the 
DNS query and sends the DNS response encrypted using G^CS. If the DNS 
server plans to change the keys, then a public key G^S1 is sent to the 
client , in the response packet. But these are optimizations which can 
be done later.

Thank you and I'm looking forward to your feedback!

Best regards,
Vineeth

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org