[DNSOP] Re: Request Feedback: draft-sheth-dns-integration

[Ben Schwartz]

Section 5.7 of  draft-ietf-dnsop-domain-verification-techniques-05 says


   Some Application Service Providers currently require the Validation
   Record to remain in the zone indefinitely for periodic revalidation
   purposes.  This practice should be discouraged.  Subsequent
   validation actions using an already disclosed secret are no guarantee
   that the original owner is still in control of the domain, and a new
   challenge needs to be issued.

However, this draft implicitly takes the opposite view, as the authors refer to 
systems that require their validation records to be published as long as the 
corresponding association exists.

I think the discrepancy is very interesting.  We need to distinguish "this 
domain is authorized by account $X" and "this domain authorizes account $X".  
When performed in the DNS, the former requires a secret and applies to a point 
in time; the latter requires no secrets and applies continuously.

In general, I think the latter is probably simpler, easier to manage, and more 
secure.  Perhaps the DCV draft ought to note this.

--Ben

From: Sheth, Swapneel 
Sent: Monday, August 5, 2024 12:04 PM
To: dnsop@ietf.org 
Cc: Kaizer, Andrew ; br...@blueskyweb.xyz 
; nick@ens.domains 
Subject: [DNSOP] Request Feedback: draft-sheth-dns-integration

DNSOP, Just before IETF 120 we published a draft "Integration of DNS Domain 
Names into Application Environments: Motivations and Considerations" along with 
co-authors from Bluesky and Ethereum Name Service. You may have seen us 
socializing


DNSOP,

Just before IETF 120 we published a draft "Integration of DNS Domain Names into 
Application Environments: Motivations and 
Considerations"
 along with co-authors from Bluesky and Ethereum Name Service.  You may have 
seen us socializing it at the hackathon and 
HotRFC
 or heard the request for feedback during Thursday's DNSOP session when the 
chairs mentioned it during the "Drafts of Note" of section.

During IETF 120 we received a lot of good feedback around this draft and would 
like further feedback!  Since the initial 00 version, we have changed the draft 
to informational and are in the process of evaluating how best to incorporate 
the other feedback we received.

The goal of this draft is to provide informational guidance to communities who 
are trying to incorporate DNS domain names into their applications.  The draft 
currently provides motivations for why applications opt to utilize domain names 
and qualities that applications should consider as they build and maintain 
their integrations, e.g., having processes in place to account for domain name 
lifecycle events or DNS protocol evolution.  We would appreciate feedback on 
the current draft and other motivations/qualities we should consider including 
that would make this draft as useful as possible to these communities.

We would be happy to take feedback here on the mailing list.

Thanks,
Swapneel Sheth


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

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

[Ben Schwartz]

Thanks for the background, Christian.  I think one or two sentences on this 
topic would be worth including in the draft.

--Ben



From: Christian Amsüss
Sent: Tuesday, July 30, 2024 6:26 AM
To: Ben Schwartz
Cc: mohamed.boucad...@orange.com; Carsten Bormann; c...@ietf.org; dnsop@ietf.org
Subject: Re: [core] Re: Fwd: WG Adoption Call for 
draft-lenders-core-coap-dtls-svcb

Hello  Rich,

> I'm also surprised by the choice of mnemonic, which is very short.  If
> the extra 7 octets of "coap-dtls" would make a material difference in
> some use case, perhaps the draft should explain that.

This was mentioned just very briefly during the tls-reg-review[1], so
I'm happy to elaborate here. I have no current use cases where they hit
the precise boundaries, but two observations:

* In general, CoAP is one of the IETF protocols used in situations where
  sizes matter a lot -- while a DTLS messages usually fit well within a
  UDP MTU, CoAP is designed for running over fragmenting link layers,
  and the Client Hello and Server Hello are just the messages that
  already fragment[2]. With cTLS[3] being worked on, there is hope to
  push those below the fragmentation threshold -- provided we don't add
  too much on top of it while cTLS is shrinking.

* The process of designing EDHOC to fit with its required use cases
  involved byte shaving and just barely fit some of the maximum lengths.
  [4] describes how going over a fragmentation limit can cause
  exhaustion of slots and thus delay onboarding by an hour. To my
  understanding, DTLS/cTLS is not aiming for that precise space, but it
  does illustrate that this byte shaving around CoAP is not a vain
  exercise.

I think that these considerations are well understood among CoAP users
(who are the main audience of this document); if you prefer an
explanation in the document, we're happy to elaborate there as well.

Best regards
Christian

[1]: 
https://mailarchive.ietf.org/arch/browse/tls-reg-review/?gbt=1=RiTWJ3-vE95YQ76Zk3VZySB4YEs
[2]: https://dl.acm.org/doi/pdf/10.1145/3609423#page=12
[3]: https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/
[4]: https://www.ietf.org/archive/id/draft-ietf-lake-reqs-04.html#name-time

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

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

[Ben Schwartz]

The technical content of this draft seems appropriate to me, and worth 
advancing.

I agree with Med's note about the presentation.

I'm also surprised by the choice of mnemonic, which is very short.  If the 
extra 7 octets of "coap-dtls" would make a material difference in some use 
case, perhaps the draft should explain that.

--Ben

From: mohamed.boucad...@orange.com 
Sent: Monday, July 29, 2024 7:56 AM
To: Carsten Bormann ; c...@ietf.org 
Cc: dnsop@ietf.org 
Subject: [DNSOP] Re: [core] Fwd: WG Adoption Call for 
draft-lenders-core-coap-dtls-svcb

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


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).



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



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 

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Ben Schwartz]

TLS 1.3 clients using ECH will not fall back to non-ECH upon unauthenticated 
failure, just as TLS clients of any kind will not fall back to a lower version 
upon unauthenticated failure.  To control the TLS version, or the usage of ECH, 
one must either control the client's behavior directly or be able to 
authenticate as the TLS destination to the client's satisfaction.  In an 
enterprise context, the latter is often accomplished by implanting a special 
local certificate authority into the client's trust store.

--Ben

From: Paul Vixie 
Sent: Thursday, July 25, 2024 12:11 AM
To: Paul Wouters ; Ben Schwartz 
Cc: Tommy Jensen ; dnsop ; Damick, 
Jeffrey ; Engskow, Matt ; Jessica 
Krynitsky 
Subject: Re: [DNSOP] Re: [EXTERNAL] New Version Notification for 
draft-tjjk-cared-00.txt

On Tuesday, July 23, 2024 1:56:50 PM PDT Ben Schwartz wrote:
> It seems like there's some confusion here.  ECH is an extension to TLS that
> is still under development (and now nearly final).  Use of ECH is optional
> in TLS 1.3.  Any entity that can control the TLS version in use also has
> the ability to disable ECH, so allowing TLS 1.3 does not require an
> administrator to permit ECH.
>
> --Ben Schwartz

If a client who tries TLS 1.3 with ECH can be detected by an enterprise ("next
generation") firewall using the spoofed-SYNACK trick so common for HTTPS, and
made to fail, and would then have some reason to retry TLS 1.3 without ECH,
rather than just giving up or moving straight to TLS 1.2, this is the first
i'm hearing of it. is this advice-to-implementors specified somewhere? i'd
like to see it referenced in:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/__;!!Bt8RZUm9aw!_mzGaaZFnvwxN4QOGxmIc2AyuEoPGnSu43oxV_tTqWky9LWWsRLui4Ozhk1Boyxi5O2alFFKlw$

...and i suggest simply referencing that advice in the draft under discussion.

--
P Vixie



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

[DNSOP] Re: An Interplanetary DNS Model

[Ben Schwartz]

It seems we have a terminology mismatch: segmented encryption that covers each 
network hop but requires re-encryption at some relays, as proposed, is the 
opposite of "end to end encryption".

Regardless, I do not think rewriting of domain names to append a supra-root 
hierarchy within the domain name syntax is a good solution for resource naming 
between semi-isolated networks.

The right solution will depend heavily on the social, political, and economic 
relationships between the users of these networks.  For space, these questions 
are matter of science fiction at present, and we should not regard them as 
standards questions until we start getting complaints from grumpy sysadmins on 
the moon.  Good standards are reactive, not speculative.

If you want to pursue standardization today, I recommend focusing on a use 
case, where proposed standards could be deployed to improve the lives of 
current users.  Improving the functionality of internet protocols for users 
riding in an elevator, driving on remote highways, camping in the wilderness, 
living in a submarine, or flying on the Tiangong space station, would be 
appropriate for the IETF.

--Ben

From: Scott Johnson 
Sent: Wednesday, July 24, 2024 3:02 AM
To: Lorenzo Breda 
Cc: d...@ietf.org ; dnsop@ietf.org 
Subject: [DNSOP] Re: An Interplanetary DNS Model

Hi Lorenzo,

I may have accidentally trimmed the lists from my previous reply, thanks
for reincluding them!

On Tue, 23 Jul 2024, Lorenzo Breda wrote:

> Il giorno mar 23 lug 2024 alle ore 08:16 Scott Johnson
>  ha scritto:
>   Hi Lorenzo,
>
>   On Mon, 22 Jul 2024, Lorenzo Breda wrote:
>
>   > I don't like the way this system permits the same name to
>   refer to
>   > different resources on different planets.
>
>   It is not one of my favorite aspects either, but, at
>   present, it is the
>   only concept that will actually work that I am aware of.  I
>   look at it
>   like a phone call to another country.  One must first
>   prepend the country
>   code.  This is not necessary for calls made to the same
>   number from the
>   same country.
>
>
> Yes, but a lot of content we access on the Internet contains URIs. This
> proposed DNS system potentially lets me reach a web resource on the web
> from another planet, but the URIs referenced by the resource could be
> broken, could reference a legit different resource or could even be
> spoofed. The phone communication doesn't transmit phone numbers.

I see it this way: There will be IP networks on the Moon, and eventually
Mars.  This will be the case chiefly because a) the intrinsic "store and
forward" properties of BP, b) relativistic time dilation, and c)
unavoidable, variable clock skew all work against there being stable time,
or an equivalent of NTP to provide stable time for solely BP networks.
Time flows faster on the Moon. Atomic clocks in each device are expensive.
Still, a stable, synced time reference is required.  IP has that
functionality in NTP, and is a 0-gram payload upgrade.

Given that there this Lunar IP network will exist and face the "latency
barrier" from my previous post, as well as inherent security implications
as respects communicating via IP directly from Earth, we arrive at a
condition where there exist isolated IP networks on each world.
At present, I am aware of no other proposal to provide any IP level
interconnectivity between these two IP networks, much less one that scales
beyond the relatively small distance of Earth/Moon communications.

The need for a BP network between these "islands of IP" is apparent; more
so when considering scaling to Mars, Europa, Alpha Centauri, Sirius, or
where ever else we eventually go.  My work (almost 3 years in the making)
proposes a mechanism by which service requests can transit this BP
network.  Fundamentally, at present, we have a choice between the
evolution and development of what has been proposed, and no mechanism
whatsoever for IP interaction between these disparate networks.

Specific protocols and, to your point, data structures, will require
attention to be made fully functional.

Points have been made as to the lack of end to end confidentiality and
integrity in https application of this model.  While this is an issue that
bears discussion, segmented confidentiality and integrity does provide end
to end protection, however it does so using mechanisms appropriate to the
underlying network.  In a Earth/Mars transit, there are exactly two
times/places where cryptographic protection is not available
(notwithstanding terrestrial MiTM which can break relatively weak TLS in
realtime).  Both happen inside the appropriate IP/BP daemon(s) on the
gateway, on each end of the BP network.  I could see a proprietary gateway
being a problem for network users here; how could a user ensure that the
gateway vendor is not tapping this interprocess operation?  With a fully
open standard, this issue 

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Ben Schwartz]

It seems like there's some confusion here.  ECH is an extension to TLS that is 
still under development (and now nearly final).  Use of ECH is optional in TLS 
1.3.  Any entity that can control the TLS version in use also has the ability 
to disable ECH, so allowing TLS 1.3 does not require an administrator to permit 
ECH.

--Ben Schwartz

From: Paul Vixie 
Sent: Tuesday, July 23, 2024 4:01 PM
To: Paul Wouters 
Cc: Tommy Jensen ; Ben Schwartz ; 
dnsop ; Damick, Jeffrey ; Engskow, Matt 
; Jessica Krynitsky 
Subject: Re: [DNSOP] Re: [EXTERNAL] New Version Notification for 
draft-tjjk-cared-00.txt


--
P Vixie

On Tuesday, July 23, 2024 12:52:28 PM PDT Paul Wouters wrote:
> On Jul 23, 2024, at 12:09, Paul Vixie 
wrote:
> > Making TLS 1.2 available as a fallback is vital. Many secure private edge
> > networks will never allow TLS 1.3 because of ECH.
>
> You can do TLS 1.3 without ECH ?

if an endpoint wants TLS 1.3 with ECH, there's no way to negotiate them down
to TLS 1.3 without ECH. there is a way to negotiate them down to TLS 1.2.

> Making  a weaker version of TLS mandatory would be unwise, unless it’s to
> give more time for migration away from it.

migration for military, government, and many corporate networks can't happen.
for reasons of law, regulation, or policy, they must see the client hello
before they can decide whether to block the flow. "just secure your devices"
can't work due to the way the supply chain works. the only alternative will be
to block outbound entirely and force all traffic through a non-intercepting
proxy.

ietf knew this, but RFC 8890 forbade us to consider it. i was a dissenter. the
fact that you refer to TLS 1.2 as "weaker" may indicate a preference that we
mandate a technology that often _cannot_ be used even those the alternative
("effective mandate") will be a technology (explicit proxy) which is in fact
weaker than TLS 1.2. we should not argue from talking points.

don't put it in terms of migration. just recommend that fallback be allowed.
50 years from now, smarter people than us can think of a better way forward.
as things are today, secure private edge networks including military,
government, and many commercial networks, will not allow TLS 1.3 to be used.

paul


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

[DNSOP] Re: Fwd: New Version Notification for draft-andrews-private-ds-digest-types-00.txt

[Ben Schwartz]

OK, thanks for the explanation.  That helps me understand the scenario where 
this would be needed, but it seems like simpler solutions are possible.  For 
example, the resolver could be configured to restrict the use of PRIVATEDNS 
keys to specific subtrees where their usage is known.

This draft effectively turns PRIVATEDNS into a general-purpose extension point 
for _public_ DNSSEC algorithms.  These algorithms could be used interoperably 
in public, so they would be quite different from normal Private Use range 
values in an IANA registry.  That's an interesting idea, but it seems like a 
significant revolution in DNSSEC algorithm registration without an obvious 
motivation.

--Ben

From: Mark Andrews 
Sent: Tuesday, July 23, 2024 12:28 PM
To: Ben Schwartz 
Cc: dnsop 
Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-andrews-private-ds-digest-types-00.txt

At the moment you can only have one private algorithm per key type world wide. 
This is all to do with how you prove a zone is to be treated as insecure. If 
example. com is using private. example. com and example. net is using private. 
example. net

At the moment you can only have one private algorithm per key type world wide.

This is all to do with how you prove a zone is to be treated as insecure.   If 
example.com is using private.example.com and example.net is using 
private.example.net how done  validator that knows about private.example.com 
prove that example.net response are to be treated as insecure when there is a 
DS with PRIVATEDNS returned?
--
Mark Andrews

On 23 Jul 2024, at 07:46, Ben Schwartz  wrote:


Two questions I didn't see addressed:

Why would a zone need to be signed with multiple private algorithms?

Why isn't it sufficient to treat all private algorithms as a single algorithm 
for DS purposes, and distinguish by the Key Tag and/or trial hashing?

--Ben Schwartz

From: Mark Andrews 
Sent: Monday, July 22, 2024 1:08 PM
To: dnsop 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-andrews-private-ds-digest-types-00.txt

This addresses a gap in the DNSSEC specification. DS records need to identify 
specific DNSSEC algorithms rather than a set of DNSSEC algorithms. Begin 
forwarded message: From: internet-drafts@ ietf. org Subject: New Version 
Notification for draft-andrews-private-ds-digest-types-00. txt
This addresses a gap in the DNSSEC specification.  DS records need to identify 
specific DNSSEC algorithms rather than a set of DNSSEC algorithms.

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for 
draft-andrews-private-ds-digest-types-00.txt
Date: 22 July 2024 at 10:05:24 GMT-7
To: "M. Andrews" , "Mark Andrews" 

A new version of Internet-Draft draft-andrews-private-ds-digest-types-00.txt
has been successfully submitted by Mark Andrews and posted to the
IETF repository.

Name: draft-andrews-private-ds-digest-types
Revision: 00
Title:Private DS Digest Types
Date: 2024-07-22
Group:Individual Submission
Pages:5
URL:  
https://www.ietf.org/archive/id/draft-andrews-private-ds-digest-types-00.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-andrews-private-ds-digest-types-00.txt__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxGA5SwNi0$>
Status:   
https://datatracker.ietf.org/doc/draft-andrews-private-ds-digest-types/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-andrews-private-ds-digest-types/__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxG78jzG2E$>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-andrews-private-ds-digest-types<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-andrews-private-ds-digest-types__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxGSCgFVBk$>


Abstract:

  When DS records where defined the ability to fully identify the
  DNSSEC algorithms using PRIVATEDNS and PRIVATEOID was overlooked.

  This documents specifies 2 DS Algorithm Types which allow the DNSSEC
  algorithm sub type to be encoded in the DS record.



The IETF Secretariat



--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

[DNSOP] Re: Fwd: New Version Notification for draft-andrews-private-ds-digest-types-00.txt

[Ben Schwartz]

Two questions I didn't see addressed:

Why would a zone need to be signed with multiple private algorithms?

Why isn't it sufficient to treat all private algorithms as a single algorithm 
for DS purposes, and distinguish by the Key Tag and/or trial hashing?

--Ben Schwartz

From: Mark Andrews 
Sent: Monday, July 22, 2024 1:08 PM
To: dnsop 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-andrews-private-ds-digest-types-00.txt

This addresses a gap in the DNSSEC specification. DS records need to identify 
specific DNSSEC algorithms rather than a set of DNSSEC algorithms. Begin 
forwarded message: From: internet-drafts@ ietf. org Subject: New Version 
Notification for draft-andrews-private-ds-digest-types-00. txt

This addresses a gap in the DNSSEC specification.  DS records need to identify 
specific DNSSEC algorithms rather than a set of DNSSEC algorithms.

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for 
draft-andrews-private-ds-digest-types-00.txt
Date: 22 July 2024 at 10:05:24 GMT-7
To: "M. Andrews" , "Mark Andrews" 

A new version of Internet-Draft draft-andrews-private-ds-digest-types-00.txt
has been successfully submitted by Mark Andrews and posted to the
IETF repository.

Name: draft-andrews-private-ds-digest-types
Revision: 00
Title:Private DS Digest Types
Date: 2024-07-22
Group:Individual Submission
Pages:5
URL:  
https://www.ietf.org/archive/id/draft-andrews-private-ds-digest-types-00.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-andrews-private-ds-digest-types-00.txt__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxGA5SwNi0$>
Status:   
https://datatracker.ietf.org/doc/draft-andrews-private-ds-digest-types/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-andrews-private-ds-digest-types/__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxG78jzG2E$>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-andrews-private-ds-digest-types<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-andrews-private-ds-digest-types__;!!Bt8RZUm9aw!8QIT18AIL9ewonmo3nayaXnt_PX8h4hi70SPJjNzLRWNe6kEEmiVeLvmEm6RBqxGSCgFVBk$>


Abstract:

  When DS records where defined the ability to fully identify the
  DNSSEC algorithms using PRIVATEDNS and PRIVATEOID was overlooked.

  This documents specifies 2 DS Algorithm Types which allow the DNSSEC
  algorithm sub type to be encoded in the DS record.



The IETF Secretariat



--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Ben Schwartz]

I am generally skeptical of the idea that we should write recommendations that 
are "for enterprise".  The notion of "enterprise" is too slippery for technical 
standards.  Enterprises are also technically integrated by definition, so they 
are less reliant on technical standards than multi-party arrangements.

This draft is framed as making the argument for choosing mTLS as the 
authentication mechanism for DoE, but I don't think this choice is within the 
IETF's purview.  Operators are free to deploy any compatible authentication 
mechanism.  Our job is to define these mechanisms and make sure they work, not 
to tell them that they made the wrong choice.

I do think this could be a useful draft if framed as "So you've decided to use 
mTLS auth for DNS resolution".  Helping operators to understand the risks, 
limitations, and strengths of mTLS in this context could be valuable.

--Ben

From: Tommy Jensen 
Sent: Monday, July 22, 2024 7:52 PM
To: Ben Schwartz ; dnsop 
Cc: Damick, Jeffrey ; Jessica Krynitsky 
; Engskow, Matt 
Subject: Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

Hey Ben, Thank you for reading the draft and your comments. I agree we would 
not need a draft for saying mTLS works as expected. This draft is saying 
something different: "mTLS is the way one should auth clients to encrypted DNS 
servers

Hey Ben,

Thank you for reading the draft and your comments.

I agree we would not need a draft for saying mTLS works as expected. This draft 
is saying something different: "mTLS is the way one should auth clients to 
encrypted DNS servers for many reasons, cross-protocol use among them." The 
cost of doing something like "make OAuth or Privacy Pass work with DoT and DoQ" 
needs to be weighed against what benefits that would give over using mTLS that 
matter to the narrow use case where using client auth with encrypted DNS is 
appropriate (where both client and server are managed by the same authority, 
such as enterprise end-to-end).

For example, you talk about "privacy properties" of PrivacyPass — which 
properties are you thinking about that would apply to the enterprise use case 
and be more useful than mTLS as a result? That's not a leading question, I 
legitimately don't know enough about PrivacyPass to know. Conversely, can you 
expand on the downsides of mTLS versus OAuth or PrivacyPass? If you would like 
to see a different recommendation, it would be good to understand why. If you 
disagree with the requirements the draft defined to based its reasoning on, 
that's a good place to start too (I note the markdown didn't survive the 
submission and the bulleted lists in the first two paragraphs of section 6 are 
not lists, sorry about that).

Thanks,
Tommy


From: Ben Schwartz 
Sent: Monday, July 22, 2024 4:18 PM
To: Tommy Jensen ; dnsop 
Cc: Damick, Jeffrey ; Jessica Krynitsky 
; Engskow, Matt 
Subject: Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

mTLS might be the most pragmatic approach today in many situations, but I don't 
think we can recommend it in the way that this draft would.  It has some 
significant downsides, especially when compared against something like OAuth 
(which might integrate better with user account systems) or Privacy Pass* 
(which has much better privacy properties).  It's true that these mechanisms 
can't be used with DoT and DoQ today, but it is within our power to fix that if 
we care to.

If the only significance of this draft is today "mTLS works as you would expect 
for DoT, DoQ, and DoH", then I don't think we need a draft to tell us that.

--Ben

*I am a co-chair of PRIVACYPASS but I am speaking only as an individual 
participant..

From: Tommy Jensen 
Sent: Thursday, June 27, 2024 2:41 PM
To: dnsop 
Cc: Damick, Jeffrey ; Jessica Krynitsky 
; Engskow, Matt 
Subject: [DNSOP] Re: [EXTERNAL] New Version Notification for 
draft-tjjk-cared-00.txt

Hello dnsop,

Not to distract from the "should we deprecate DNS64" discussion I started after 
proposing updates to 7050, but this is the second draft (last one, I promise) 
I'll be proposing to this group as interesting work ahead of IETF 120. Joining 
me are co-authors Jessica from Microsoft and Jeff and Matt from Amazon.

In light of enterprises increasingly using encrypted DNS for their own 
"Protective DNS" resolvers, we are proposing best practices for when and how to 
use client authentication with encrypted DNS. Since this is a Good Thing for 
enterprises who control both peers (stronger security for client policy 
application and security auditing post-attack) and a Bad Thing otherwise 
(privacy violations for the non-enterprises cases common to consumers), we feel 
there is a need to specify when implementors should or should not use it.

Spoiler alert: we prefer mTLS 

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Ben Schwartz]

mTLS might be the most pragmatic approach today in many situations, but I don't 
think we can recommend it in the way that this draft would.  It has some 
significant downsides, especially when compared against something like OAuth 
(which might integrate better with user account systems) or Privacy Pass* 
(which has much better privacy properties).  It's true that these mechanisms 
can't be used with DoT and DoQ today, but it is within our power to fix that if 
we care to.

If the only significance of this draft is today "mTLS works as you would expect 
for DoT, DoQ, and DoH", then I don't think we need a draft to tell us that.

--Ben

*I am a co-chair of PRIVACYPASS but I am speaking only as an individual 
participant..

From: Tommy Jensen 
Sent: Thursday, June 27, 2024 2:41 PM
To: dnsop 
Cc: Damick, Jeffrey ; Jessica Krynitsky 
; Engskow, Matt 
Subject: [DNSOP] Re: [EXTERNAL] New Version Notification for 
draft-tjjk-cared-00.txt

Hello dnsop, Not to distract from the "should we deprecate DNS64" discussion I 
started after proposing updates to 7050, but this is the second draft (last 
one, I promise) I'll be proposing to this group as interesting work ahead of

Hello dnsop,

Not to distract from the "should we deprecate DNS64" discussion I started after 
proposing updates to 7050, but this is the second draft (last one, I promise) 
I'll be proposing to this group as interesting work ahead of IETF 120. Joining 
me are co-authors Jessica from Microsoft and Jeff and Matt from Amazon.

In light of enterprises increasingly using encrypted DNS for their own 
"Protective DNS" resolvers, we are proposing best practices for when and how to 
use client authentication with encrypted DNS. Since this is a Good Thing for 
enterprises who control both peers (stronger security for client policy 
application and security auditing post-attack) and a Bad Thing otherwise 
(privacy violations for the non-enterprises cases common to consumers), we feel 
there is a need to specify when implementors should or should not use it.

Spoiler alert: we prefer mTLS as the ideal authentication mechanism. I'll let 
the draft speak for itself as to why. Feedback and discussion is welcome.

Thanks,
Tommy


From: internet-dra...@ietf.org 
Sent: Thursday, June 27, 2024 11:32 AM
To: Jeffrey Damick ; Jessica Krynitsky 
; Matt Engskow ; Tommy 
Jensen 
Subject: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

A new version of Internet-Draft draft-tjjk-cared-00.txt has been successfully
submitted by Tommy Jensen and posted to the
IETF repository.

Name: draft-tjjk-cared
Revision: 00
Title:Client Authentication Recommendations for Encrypted DNS
Date: 2024-06-27
Group:Individual Submission
Pages:11
URL:  
https://www.ietf.org/archive/id/draft-tjjk-cared-00.txt
Status:   
https://datatracker.ietf.org/doc/draft-tjjk-cared/
HTML: 
https://www.ietf.org/archive/id/draft-tjjk-cared-00.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-tjjk-cared


Abstract:

   For privacy reasons, encrypted DNS clients need to be anonymous to
   their encrypted DNS servers to prevent third parties from correlating
   client DNS queries with other data for surveillance or data mining
   purposes.  However, there are cases where the client and server have
   a pre-existing relationship and each peer wants to prove its identity
   to the other.  For example, an encrypted DNS server may only wish to
   accept resolutions from encrypted DNS clients that are managed by the
   same enterprise.  This requires mutual authentication.

   This document defines when using client authentication with encrypted
   DNS is appropriate, the benefits and limitations of doing so, and the
   recommended authentication mechanism(s) when communicating with TLS-
   based encrypted DNS protocols.



The IETF Secretariat


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

[DNSOP] Re: [dtn] An Interplanetary DNS Model

[Ben Schwartz]

This document seems to propose that "https" URLs will route through gateways 
that terminate end-to-end security, destroying the "https" scheme's 
confidentiality and integrity properties.  That's a red flag for me.

Rather than trying to retrofit compatibility with existing terrestrial 
protocols into this (hypothetical and quite distant) scenario, I think we would 
be better served by developing protocols that serve real demands today, and 
delaying other technical solutions until real demand appears.

--Ben

From: Nordgren, Bryce - FS, MT 
Sent: Monday, July 22, 2024 3:42 PM
To: Scott Johnson ; d...@ietf.org ; 
dnsop@ietf.org 
Cc: ipnsig...@googlegroups.com ; 
awg-ipn...@googlegroups.com 
Subject: [DNSOP] Re: [dtn] An Interplanetary DNS Model

Just spitballing, but instead of a new TLD, what about "{earth,moon,mars}. sol. 
arpa" as your suffix? This seems like it's right in the wheelhouse of the 
"Address Resolution Parameter Area". . . https: //en. wikipedia. org/wiki/. arpa

Just spitballing, but instead of a new TLD, what about 
"{earth,moon,mars}.sol.arpa" as your suffix?

This seems like it's right in the wheelhouse of the "Address Resolution 
Parameter Area"...

https://en.wikipedia.org/wiki/.arpa




[Forest Service Shield]

Bryce Nordgren, FRIT
Physical Scientist

Forest Service

Missoula Fire Science Lab

p: 406-829-6955
c: 406-396-4147
bryce.l.nordg...@usda.gov

5775 Hwy 10 W
Missoula, MT 59808
www.fs.fed.us
[USDA 
Logo][Forest
 Service 
Twitter][USDA
 Facebook]

Caring for the land and serving people






From: Scott Johnson 
Sent: Monday, July 22, 2024 3:00 AM
To: d...@ietf.org ; dnsop@ietf.org 
Cc: ipnsig...@googlegroups.com ; 
awg-ipn...@googlegroups.com 
Subject: [dtn] An Interplanetary DNS Model

Hi Everyone,

Sorry for the 4-way cross posting, but I wanted to reach all of those
parties who may have interest.

I have published an internet-draft version of a document I have been
privately publishing, in order that the community may understand, pick
apart, improve, and fill in the blanks.  This is in response to community
interest and related efforts, in order that we best arrive at a
standardized practice and architecture for Interplanetary Internet
communications.  I welcome and look forward to comments which could help
us reach this laudable goal.  I am not sure of the exact venue for WG
adoption, given the scope of the concepts.  As such will I refrain from
asking for WG adoption at this time, pending discussion from the DTN and
DNS communities.

Please find the draft here:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-johnson-interplanetary-dns%2F=05%7C02%7Cbryce.l.nordgren%40usda.gov%7Ca6aa16d3a3434c34031208dcaa2d44ba%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C1%7C0%7C638572358631001081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=BTPmN%2B7FDxrLZPRDDZZoD6YNKHG1d5ROtFlDjqZg1Vs%3D=0

I would also be interested in revisiting Marc Blanchet's smtp and http
over BP related drafts in the light of the above document, to see if
adaptation can be made to make these efforts dovetail together.

Thanks to all,
Scott Johnson
Spacely Packets, LCC

___
dtn mailing list -- d...@ietf.org
To unsubscribe send an email to dtn-le...@ietf.org




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Response to draft-fbw-dnsop-dnszonehop

[Ben Schwartz]

For those lacking context on "aggressive negative caching", see 
https://datatracker.ietf.org/doc/rfc8198/

--Ben Schwartz

From: Roy Arends 
Sent: Monday, July 22, 2024 3:45 PM
To: dnsop 
Subject: [DNSOP] Response to draft-fbw-dnsop-dnszonehop

I saw this on the agenda for this afternoon.

The proposed solution against zone-walking is to exclude names from an nsec 
chain.

Example, say "B" needs to kept private from zone-walking, so have:

A.example. NSEC C.example.
B.example. A 192.168.10.10
C.example. NSEC ...

This is a terrible idea. This will break DNSSEC. Agressive negative caching 
will make sure that B won't exist, since the A NSEC C record proves it.

Happy to discuss it in the WG this afternoon.

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

[DNSOP] Re: Fwd: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt

[Ben Schwartz]

I think dry-run DNSSEC is an interesting idea.  I suggest that the authors also 
consider how it would interact with DELEG, which aims to improve the state of 
DNSSEC configuration and improve delegation flexibility.  Some variants of the 
DELEG proposal might already enable some kind of dry-run DNSSEC capability.

For this draft, I find the current text hard to read.  I also think that the 
expectations are underspecified.  This specification permits some rather 
complex arrangements with mixtures of "dry-run" and "production" DS records, 
and I couldn't say with any confidence what a resolver is supposed to do when 
confronted with such a mixture.

I'm also interested in the possibilities for malicious use of this extension.  
Can a malicious domain cause a resolver to do an enormous amount of work?  Can 
a malicious intermediary cause an enormous volume of error reports?

--Ben

From: Yorgos Thessalonikefs 
Sent: Tuesday, July 16, 2024 10:34 AM
To: dnsop@ietf.org 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-yorgos-dnsop-dry-run-dnssec-02.txt

Dear dnsop,

We submitted a new version of the "dry-run DNSSEC" draft.
This work was reinitiated now that RFC9567 (DNS Error Reporting) is a
standard document and my plan to incorporate it into Unbound during the
IETF120 Hachathon.

This update mainly addresses the following feedback we got from IETF114
and the mailing list:

** Burn a bit of the DS Type Digest Algorithms **
The difference between a dry-run DS and a normal DS will be the Type
Digest Algorithm. There will be a dry-run equivalent value for normal
digest algorithms. The document currently only specifies one dry-run DS
Type Digest Algorithm (for SHA256) but this could change in a later
revision to generally use the most-significant bit for this distinction.

This results in static lengths for each dry-run DS Type Digest Algorithm.


** NOERROR reports **
The idea of an upstream to signal that it would like NOERROR reports
sent to the reporting agent (from RFC9567), was going to be included in
that RFC but with no concrete use-case at the time it was left out.
NOERROR reporting is definitely a requirement for this draft since a
zone operator would appreciate a signal that notices the existence of
dry-run validators with no errors to report.

Currently it is described as an unsolicited EDNS option next to the
Report-Channel but future revisions could treat generation of NOERROR
reports as implied in the presence of dry-run DSes.


We are looking forward for any feedback either here on the mailing list
or in person in Vancouver.

Best regards,
-- Yorgos

 Forwarded Message 
Subject: New Version Notification for
draft-yorgos-dnsop-dry-run-dnssec-02.txt
Date: Mon, 08 Jul 2024 13:12:06 -0700
From: internet-dra...@ietf.org
To: Roy Arends , Willem Toorop
, Yorgos Thessalonikefs 

A new version of Internet-Draft draft-yorgos-dnsop-dry-run-dnssec-02.txt has
been successfully submitted by Yorgos Thessalonikefs and posted to the
IETF repository.

Name: draft-yorgos-dnsop-dry-run-dnssec
Revision: 02
Title:dry-run DNSSEC
Date: 2024-07-08
Group:Individual Submission
Pages:14
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.txt__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93qeY0jMc$
Status: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93V7AZJBM$
HTML:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.html__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93NMRAJNU$
HTMLized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W93aAlvuRU$
Diff:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-yorgos-dnsop-dry-run-dnssec-02__;!!Bt8RZUm9aw!9yxbk6zobQ5e2KAbITIs5ksKFCgMQL_bo2J1iUYKBhWlpDCxuRgYvdi_j-8kynjmfe0e2W9343QzeyE$

Abstract:

  This document describes a method called "dry-run DNSSEC" that allows
  for testing DNSSEC deployments without affecting the DNS service in
  case of DNSSEC errors.  It accomplishes that by introducing new DS
  Type Digest Algorithms that when used in a DS record, referred to as
  dry-run DS, signal to validating resolvers that dry-run DNSSEC is
  used for the zone.  DNSSEC errors are then reported with DNS Error
  Reporting, but any bogus responses to clients are withheld.  Instead,
  validating resolvers fallback from dry-run DNSSEC and provide the
  response that would have been answered without the presence of a dry-
  run DS.  A further EDNS option is presented for clients to opt-in for
  dry-run 

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

[Ben Schwartz]

On Jul 10, 2024, at 1:03 PM, Philip Homburg  wrote:


  I see several different directions this could go that might be
  useful.

  1. "DNS at the 99th percentile"

  Rather than normatively declare limits on things like NS count
  or CNAME chain length, it would be interesting to measure
  behaviors out in the real world.  How long can your CNAME chain
  be before resolution failure rates exceed 1%?  How many NS
  records or RRSIGs can you add before 99% of resolvers won't try
  them all?

That has a bit of risk that we need a new document every year.

That’s fine.  Not every useful DNS-related document has to be an IETF RFC.

  2. "DNS Lower Limits"

  Similar to the current draft, but a change of emphasis: instead
  of setting upper bounds on the complexity of zones, focus on
  setting lower bounds on the capability of resolvers.

This is the same thing. If some popular resolvers implement the lower bound
then it effectively because an upper bound on the complexity of zones.

That’s a pretty big “if”, especially when multiplied across all the 
recommendations in the draft.  Even then, it wouldn’t apply to zones with an 
unusual client base.

  3. "DNS Intrinsic Limits"

  Given the existing limits in the protocol (e.g. 64 KB responses,
  255 octet names), document the extreme cases that might be
  challenging to resolve.  This could be used to create a live
  test suite, allowing implementors to confirm that their resolvers
  scale to the worst-case scenarios.

Why? Do we really care if a resolver limits the size of RRsets to 32 KB?

Yes.  Unnecessary limits restrict our flexibility even if mainstream use cases 
don’t exist today.  Large RRsets have been considered in many contexts over the 
years, most recently for postquantum keys and signatures.

Tests can help to make sure that resolvers don't crash. But they may just
return early when they see something ridiculous.

  4. "DNS Proof of Work"

  In most of these cases, the concern is that a hostile stub can
  easily request resolution of a pathological domain, resulting
  in heavy load on the recursive resolver.  This is a problem of
  asymmetry: the stub does much less work than the resolver in
  each transaction.  We could compensate for this by requiring
  the stub to increase the amount of work that it does.  For
  example, we could

  * Recommend that resolvers limit the amount of work they will
  do for UDP queries, returning TC=1 when the limit is reached.

That immediately prompts a question what the 'limit' is.

The limit is not standards-relevant.  It could be “10 milliseconds of CPU time” 
or “3 cache misses” or whatever.  The stub doesn’t need to know; it just 
retries over TCP as already required.

For example, a resolver could set TC=1 after encountering 2 CNAMEs. But
I'm sure that will make a lot of people very unhappy.

A resolver can return TC=1 for all UDP queries if it wants, and this is often 
discussed as a DoS defense mechanism.  Returning TC=1 for 1% of queries should 
not be a serious problem for anyone.

  * Create a system where stubs pad their UDP query packets to
  prevent reflection-amplification attacks.

That seems unrelated to this draft.

  * Develop a novel proof-of-work extension, e.g. a continuation
  system that requires the stub to reissue heavy queries several
  times before getting the answer.

That raises exactly the same question: what is 'heavy’?

Implementation-defined.  There’s no need to standardize it; the stub just 
“continues” the query until it gets an answer or loses patience.

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

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

[Ben Schwartz]

I see several different directions this could go that might be useful.

1. "DNS at the 99th percentile"

Rather than normatively declare limits on things like NS count or CNAME chain 
length, it would be interesting to measure behaviors out in the real world.  
How long can your CNAME chain be before resolution failure rates exceed 1%?  
How many NS records or RRSIGs can you add before 99% of resolvers won't try 
them all?

2. "DNS Lower Limits"

Similar to the current draft, but a change of emphasis: instead of setting 
upper bounds on the complexity of zones, focus on setting lower bounds on the 
capability of resolvers.

3. "DNS Intrinsic Limits"

Given the existing limits in the protocol (e.g. 64 KB responses, 255 octet 
names), document the extreme cases that might be challenging to resolve.  This 
could be used to create a live test suite, allowing implementors to confirm 
that their resolvers scale to the worst-case scenarios.

4. "DNS Proof of Work"

In most of these cases, the concern is that a hostile stub can easily request 
resolution of a pathological domain, resulting in heavy load on the recursive 
resolver.  This is a problem of asymmetry: the stub does much less work than 
the resolver in each transaction.  We could compensate for this by requiring 
the stub to increase the amount of work that it does.  For example, we could

* Recommend that resolvers limit the amount of work they will do for UDP 
queries, returning TC=1 when the limit is reached.
* Create a system where stubs pad their UDP query packets to prevent 
reflection-amplification attacks.
* Develop a novel proof-of-work extension, e.g. a continuation system that 
requires the stub to reissue heavy queries several times before getting the 
answer.

--Ben

From: Kazunori Fujiwara 
Sent: Tuesday, July 9, 2024 6:06 AM
To: dnsop@ietf.org 
Subject: [DNSOP] draft-fujiwara-dnsop-dns-upper-limit-values

Dear DNSOP,

I submitted new draft that proposes to consider "Upper limit value for DNS".
If you are interested, please read and comment it.

I will attend IETF Hackathon.
I would like to hear comments about the draft.

Abstract:

   There are parameters in the DNS protocol that do not have clear upper
   limit values.  If a protocol is implemented without considering the
   upper limit, it may become vulnerable to DoS attacks, and several
   attack methods have been proposed.  This draft proposes reasonable
   upper limit values for DNS protocols.

Name: draft-fujiwara-dnsop-dns-upper-limit-values
Revision: 00
Title:Upper limit value for DNS
Date: 2024-07-08
Group:Individual Submission
Pages:6
URL:  
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-fujiwara-dnsop-dns-upper-limit-values-00.txt__;!!Bt8RZUm9aw!_lsMWK02HedzneFr7X0_6TfwEg09CBgtmX_uc21HIPHwU7goaPidjlUsBGu9yIAf3tP9XpIKP38wnGo$
Status:   
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-dns-upper-limit-values/__;!!Bt8RZUm9aw!_lsMWK02HedzneFr7X0_6TfwEg09CBgtmX_uc21HIPHwU7goaPidjlUsBGu9yIAf3tP9XpIKUGuh744$
HTMLized: 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-dns-upper-limit-values__;!!Bt8RZUm9aw!_lsMWK02HedzneFr7X0_6TfwEg09CBgtmX_uc21HIPHwU7goaPidjlUsBGu9yIAf3tP9XpIKD2pUkrE$

--
Kazunori Fujiwara, JPRS 

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

[DNSOP] Re: Fwd: I-D Action: draft-zhang-dnsop-ns-selection-00.txt

[Ben Schwartz]

Hi Davey,

To clarify, the "DNS Load Balancing" side meeting will not be concerned 
primarily with nameserver selection.  Instead, the topic of the side meeting 
will be about using DNS to perform load balancing of other services and 
protocols.

I think this draft's term ("Nameserver Selection") is good, and we should use 
that to distinguish it from "DNS Load Balancing".

There is certainly some overlap between these notions (as each can be used to 
implement the other in some fashion), but I would prefer to let both topics 
mature separately for now.

--Ben

From: Davey Song 
Sent: Wednesday, July 3, 2024 2:47 AM
To: dnsop 
Subject: [DNSOP] Fwd: I-D Action: draft-zhang-dnsop-ns-selection-00.txt

Hi folks, I noticed the momentum on DNS load balancing and NS selection topics. 
Our co-authors have just compiled a draft summarizing the research findings and 
best practices in this field, and made some recommendations for developers on 
secure
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Hi folks,

I noticed the momentum on DNS load balancing and NS selection topics. Our 
co-authors have just compiled a draft summarizing the research findings and 
best practices in this field, and made some recommendations for developers on 
secure and robust NS selection algorithms. Comments are welcome.

Davey
-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Wed, Jul 3, 2024 at 2:19 PM
Subject: I-D Action: draft-zhang-dnsop-ns-selection-00.txt
To: mailto:i-d-annou...@ietf.org>>


Internet-Draft draft-zhang-dnsop-ns-selection-00.txt is now available.

   Title:   Secure Nameserver Selection Algorithm for DNS Resolvers
   Authors: Fenglu Zhang
Baojun Liu
Linjian Song
Shumon Huque
   Name:draft-zhang-dnsop-ns-selection-00.txt
   Pages:   18
   Dates:   2024-07-02

Abstract:

   Nameserver selection algorithms employed by DNS resolvers are not
   currently standardized in the DNS protocol, and this has lead to
   variation in the methods being used by implementations in the field.
   Recent research has shown that some of these implementations suffer
   from significant security vulnerabilities.  This document provides an
   in-depth analysis of nameserver selection utilized by mainstream DNS
   software and summarizes uncovered vulnerabilities.  Furthermore, it
   provides recommendations to defend against these security and
   availability risks.  Designers and operators of recursive resolvers
   can adopt these recommendations to improve the security and stability
   of the DNS.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-zhang-dnsop-ns-selection/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-zhang-dnsop-ns-selection-00

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
I-D-Announce mailing list -- i-d-annou...@ietf.org
To unsubscribe send an email to 
i-d-announce-le...@ietf.org
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-rfc7958bis

[Ben Schwartz]

I think this document is ready for publication with some nits.

Section 1.1

I like the "assumed and not derived" notion for a "trust anchor", but it's 
tricky and bears a bit more explanation.  Rather than repeating it in the 
following sentence, perhaps you could say "the decision to trust this entity is 
made outside of the system that relies on it".  My point is that "assumed and 
not derived" requires a certain sort of "horizon" comprising a single "system"; 
expand the horizon and it is indeed derived.  For example, trust in these 
DNSKEYs can be derived from the CMS signature, making the ICANN CA the trust 
anchor, but that process is outside of DNSSEC, so from DNSSEC's perspective the 
root key is the trust anchor.

Section 3.1

The existence of a protocol called "HTTPS" is controversial in the HTTP world.  
I recommend checking with the HTTPBIS chairs or other relevant experts on this 
point of style.

Section 3.3

This section says "cryptographic assurance for the contents of the trust anchor 
now comes from the web PKI as described in Section 3.2", but Section 3.2 
outlines two ways to verify the contents: an attached signature or TLS.  The 
TLS case looks like the Web PKI, especially since it is not guaranteed to chain 
to any particular root CA,  but the attached signature does not seem to 
represent a dependency on the Web PKI.

--Ben Schwartz


From: Tim Wicinski 
Sent: Wednesday, June 19, 2024 12:32 PM
To: dnsop 
Cc: dnsop-chairs 
Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc7958bis

All The authors have updated the document based on some early reviews.   Since 
this is an update from the original RFC7958, I urge folks to take a look at the 
diff from the original: https: //author-tools. ietf. 
org/iddiff?url1=rfc7958=draft-ietf-dnsop-rfc7958bis-02=--htmlThis
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

All

The authors have updated the document based on some early reviews.  Since this 
is an update from the original RFC7958, I urge folks to take a look at the diff 
from the original:


https://author-tools.ietf.org/iddiff?url1=rfc7958=draft-ietf-dnsop-rfc7958bis-02=--html<https://author-tools.ietf.org/iddiff?url1=rfc7958=draft-ietf-dnsop-rfc7958bis-02=--html>



This starts a Working Group Last Call for: draft-ietf-dnsop-rfc7958bis
"DNSSEC Trust Anchor Publication for the Root Zone"

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/<https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/>

The Current Intended Status of this document is: Informational

Benno will be the document shepherd

Please review the draft and offer relevant comments.

For WGLC, we need positive support and constructive comments; lack of objection 
is not enough.
So if you think this draft should be published as an RFC, please say so.

If you feel the document is *not* ready for publication, please speak out with 
your reasons.


This starts a two week Working Group Last Call process, and ends on: July 3rd, 
2024

thanks


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

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Ben Schwartz]

Some users seem to need an invitation to join this Slack instance.  If you'd 
like to be added, please email me off-list.

--Ben

From: Ben Schwartz 
Sent: Friday, June 28, 2024 2:23 PM
To: DNSOP Working Group 
Cc: shane.k...@ibm.com 
Subject: [DNSOP] Re: Side Meeting - DNS Load Balancing

Clarification: while you may use your Datatracker login email to make an 
account on the IETF Slack, this Slack instance is not connected to the 
Datatracker. You can use any of the offered login flows to connect. --Ben From: 
Ben Schwartz Sent: 
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Clarification: while you may use your Datatracker login email to make an 
account on the IETF Slack, this Slack instance is not connected to the 
Datatracker.  You can use any of the offered login flows to connect.

--Ben

From: Ben Schwartz
Sent: Friday, June 28, 2024 12:47 PM
To: DNSOP Working Group 
Cc: shane.k...@ibm.com 
Subject: Side Meeting - DNS Load Balancing

Hi DNSOP,

The practice of DNS Load Balancing -- sending different answers to different 
resolvers to optimize latency and avoid overload -- has been around for at 
least 25 years, and remains as popular as ever.  It's never really been 
supported in the DNS standards though, and it particularly conflicts with the 
concepts of zone files, zone transfers, and offline signing.

I think it's time we did better on this front.  To that end, Shane Kerr and I 
will be hosting a side meeting at IETF 120 on DNS Load Balancing, tentatively 
scheduled for Wednesday afternoon:

https://wiki.ietf.org/en/meeting/120/sidemeetings#wednesday-24-july<https://wiki.ietf.org/en/meeting/120/sidemeetings#wednesday-24-july>

We hope to develop a strategy for standardization, discuss topics that should 
be in or out of scope, and possibly present a demo of what standards support 
for load balancing could look like.  Please join us (in-person or remotely) if 
you have an interest in this topic.

For  discussion in the next few weeks before the meeting, we'll be 
experimenting with the IETF's new Slack channels for collaboration.  If you 
have thoughts or questions, please join our channel (using your Datatracker 
account):

https://ietf.slack.com/archives/C07AC0KDNJY<https://ietf.slack.com/archives/C07AC0KDNJY>

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

[DNSOP] Re: Side Meeting - DNS Load Balancing

[Ben Schwartz]

Clarification: while you may use your Datatracker login email to make an 
account on the IETF Slack, this Slack instance is not connected to the 
Datatracker.  You can use any of the offered login flows to connect.

--Ben

From: Ben Schwartz
Sent: Friday, June 28, 2024 12:47 PM
To: DNSOP Working Group 
Cc: shane.k...@ibm.com 
Subject: Side Meeting - DNS Load Balancing

Hi DNSOP,

The practice of DNS Load Balancing -- sending different answers to different 
resolvers to optimize latency and avoid overload -- has been around for at 
least 25 years, and remains as popular as ever.  It's never really been 
supported in the DNS standards though, and it particularly conflicts with the 
concepts of zone files, zone transfers, and offline signing.

I think it's time we did better on this front.  To that end, Shane Kerr and I 
will be hosting a side meeting at IETF 120 on DNS Load Balancing, tentatively 
scheduled for Wednesday afternoon:

https://wiki.ietf.org/en/meeting/120/sidemeetings#wednesday-24-july

We hope to develop a strategy for standardization, discuss topics that should 
be in or out of scope, and possibly present a demo of what standards support 
for load balancing could look like.  Please join us (in-person or remotely) if 
you have an interest in this topic.

For  discussion in the next few weeks before the meeting, we'll be 
experimenting with the IETF's new Slack channels for collaboration.  If you 
have thoughts or questions, please join our channel (using your Datatracker 
account):

https://ietf.slack.com/archives/C07AC0KDNJY

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

[DNSOP] Side Meeting - DNS Load Balancing

[Ben Schwartz]

Hi DNSOP,

The practice of DNS Load Balancing -- sending different answers to different 
resolvers to optimize latency and avoid overload -- has been around for at 
least 25 years, and remains as popular as ever.  It's never really been 
supported in the DNS standards though, and it particularly conflicts with the 
concepts of zone files, zone transfers, and offline signing.

I think it's time we did better on this front.  To that end, Shane Kerr and I 
will be hosting a side meeting at IETF 120 on DNS Load Balancing, tentatively 
scheduled for Wednesday afternoon:

https://wiki.ietf.org/en/meeting/120/sidemeetings#wednesday-24-july

We hope to develop a strategy for standardization, discuss topics that should 
be in or out of scope, and possibly present a demo of what standards support 
for load balancing could look like.  Please join us (in-person or remotely) if 
you have an interest in this topic.

For  discussion in the next few weeks before the meeting, we'll be 
experimenting with the IETF's new Slack channels for collaboration.  If you 
have thoughts or questions, please join our channel (using your Datatracker 
account):

https://ietf.slack.com/archives/C07AC0KDNJY

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

Re: [DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt

[Ben Schwartz]

It seems like this draft says that the indicated MRDS overrides the EDNS 
BUFSIZE value.  This seems likely to create problems if the MRDS value could be 
set by a lower layer in the stack or a downstream processing component (without 
knowledge of DNS), resulting in responses that are too large for the DNS 
client's allocated buffer.  In other words, just because I am capable of 
receiving very large UDP packets does not mean that I am capable of processing 
very large DNS responses.

In general, support for very large DNS responses in UDP is considered harmful 
because of the potential for reflection-amplification attacks.  For this 
reason, as well as concerns about legacy compatibility and general complexity, 
I think we would be better off not attempting to use UDP Options with DNS.

--Ben Schwartz

From: DNSOP  on behalf of C. M. Heard 
Sent: Sunday, April 28, 2024 5:02 PM
To: DNSOP 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt

Greetings, TSVWG currently has the document "Transport Options for UDP" (https: 
//datatracker. ietf. org/doc/html/draft-ietf-tsvwg-udp-options) in Working 
Group Last Call. It includes a capability to fragment datagrams at the UDP layer
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Greetings,

TSVWG currently has the document "Transport Options for UDP" 
(https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options>)
 in Working Group Last Call. It includes a capability to fragment datagrams at 
the UDP layer rather than the IP layer, and one of the use cases that has been 
discussed over there is using that capability to transmit large DNS responses 
without suffering the disadvantages of IP fragmentation or fallback to TCP. But 
we need a reality check from the subject matter experts over here to help us 
determine whether this idea is viable. Accordingly, I put together a short (and 
at this point not very polished) individual draft describing how this might 
work. Your feedback will be greatly appreciated.

Thanks and regards,

Mike Heard

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Sun, Apr 28, 2024 at 12:52 PM
Subject: New Version Notification for 
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
To: C. M. Heard (Mike) mailto:he...@pobox.com>>


A new version of Internet-Draft
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt has been successfully
submitted by C. M. (Mike) Heard and posted to the
IETF repository.

Name: draft-heard-dnsop-udp-opt-large-dns-responses
Revision: 00
Title:Use of UDP Options for Transmission of Large DNS Responses
Date: 2024-04-28
Group:Individual Submission
Pages:8
URL:  
https://www.ietf.org/archive/id/draft-heard-dnsop-udp-opt-large-dns-responses-00.txt<https://www.ietf.org/archive/id/draft-heard-dnsop-udp-opt-large-dns-responses-00.txt>
Status:   
https://datatracker.ietf.org/doc/draft-heard-dnsop-udp-opt-large-dns-responses/<https://datatracker.ietf.org/doc/draft-heard-dnsop-udp-opt-large-dns-responses/>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses<https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses>


Abstract:

   This document describes an experimental method for using UDP Options
   to facilitate the transmission of large DNS responses without the
   use of IP fragmentation or fallback to TCP.



The IETF Secretariat


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

Re: [DNSOP] [Editorial Errata Reported] RFC9460 (7871)

[Ben Schwartz]

\DDD escaping in RFC 1035 is decimal, not octal [1].

--Ben

P.S. I agree that this is unusual and surprising.

[1] 
https://datatracker.ietf.org/doc/html/rfc1035#:~:text=%5CDDD%20%20%20%20%20%20%20%20%20%20%20%20where%20each%20D%20is%20a%20digit%20is%20the%20octet%20corresponding%20to%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20the%20decimal%20number%20described%20by%20DDD.

From: DNSOP  on behalf of RFC Errata System 

Sent: Monday, March 25, 2024 12:44 PM
To: rfc-edi...@rfc-editor.org 
Cc: m...@kilabit.info ; i...@bemasc.net ; 
mbis...@evequefou.be ; erik+i...@nygren.org 
; dnsop@ietf.org 
Subject: [DNSOP] [Editorial Errata Reported] RFC9460 (7871)

!---|
  This Message Is From an External Sender

|---!

The following errata report has been submitted for RFC9460,
"Service Binding and Parameter Specification via the DNS (SVCB and HTTPS 
Resource Records)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7871

--
Type: Editorial
Reported by: Shulhan 

Section: D.2. ServiceMode

Original Text
-
example.com.   SVCB   1 foo.example.com. key667="hello0qoo"

\# 32 (
00 01  ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b  ; key 667
00 09  ; length 9
68 65 6c 6c 6f d2 71 6f 6f ; value
)

\x00\x01   # priority
\x03foo\x07example\x03com\x00  # target
\x02\x9b   # key 667
\x00\x09   # length 9
hello\xd2qoo   # value

Corrected Text
--
example.com.   SVCB   1 foo.example.com. key667="hello0qoo"

\# 32 (
00 01  ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b  ; key 667
00 09  ; length 9
68 65 6c 6c 6f 88 71 6f 6f ; value
)

\x00\x01   # priority
\x03foo\x07example\x03com\x00  # target
\x02\x9b   # key 667
\x00\x09   # length 9
hello\x88qoo   # value

Notes
-
The escaped octal number "0" when encoded to hexadecimal should be "88" or 
"\x88", NOT "d2" or "\xd2".

The "d2" or "\xd2" is hexadecimal value for decimal number "210".

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
will log in to change the status and edit the report, if necessary.

--
RFC9460 (draft-ietf-dnsop-svcb-https-12)
--
Title   : Service Binding and Parameter Specification via the DNS 
(SVCB and HTTPS Resource Records)
Publication Date: November 2023
Author(s)   : B. Schwartz, M. Bishop, E. Nygren
Category: PROPOSED STANDARD
Source  : Domain Name System Operations
Stream  : IETF
Verifying Party : IESG

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

Re: [DNSOP] unrelated name server name recommendation

[Ben Schwartz]

To rephrase, it sounds like you are proposing a rule that zones should be 
configured to use at most one glueless delegation step.

Under this rule, one cannot place an "unrelated nameserver name" anywhere 
beneath a zone cut that itself uses an unrelated nameserver.  Effectively, all 
zones below such a zone cut are "second class" zones for this purpose.  This 
breaks a symmetry of the DNS: there are now two different kinds of zones, where 
previously there was only one.  It's also strange that this distinction depends 
on the configuration of some parent or grandparent zone that is not controlled 
by the zone in question, and can change at any time.

I appreciate that glueless delegations have some downsides, and may be worth 
avoiding in some cases, but I think the proposed rule is too restrictive.  I 
would be more interested in a document (perhaps non-IETF) showing how adding 
complexity to your zone's resolution process impacts resolution time, error 
rate, and frequency of misconfigurations.

--Ben Schwartz

From: DNSOP  on behalf of Kazunori Fujiwara 

Sent: Sunday, March 3, 2024 11:34 PM
To: dnsop@ietf.org 
Subject: [DNSOP] unrelated name server name recommendation

!---|
  This Message Is From an Untrusted Sender
  You have not previously corresponded with this sender.
|---!

dnsop WG,

"unrelated" (or, previosly called as out-of-bailiwick) name server names are
necessary for DNS hosting providers.

However, it increases name resolution costs.
Furthermore, it makes it easy to make mistakes like cyclic dependencies.

So, I would like to make some recommendations on "unrelated" name server names.

I submitted "draft-fujiwara-dnsop-unrelated-name-server-00" as a first step.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-unrelated-name-server/

I prposed that
  the domain names that host the name server names MUST be resolvable by
  delegations using one or more in-domain name server names.

I'm not able to write well, I'm looking for good text.

Let's improve the current DNS before DELEG RR.

--
Kazunori Fujiwara, JPRS 

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

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

[Ben Schwartz]

I agree that SVCB can usually be thought of as descriptive, not prescriptive.  
The publisher provides information about their service, and the recipient makes 
use of it in some reasonable way.  For the "testing" flag, the descriptive 
information is basically "this endpoint does not carry my SLA".

I don't think the existence of server support for a less-secure protocol is 
sufficient signal.  We should plan to spend decades with some resolvers 
implementing downgrade-resistant DoT, some implementing DoT with fallback 
heuristics, and some resolvers not implementing DoT at all.  During that 
period, auth servers won't be able to disable Do53, so we won't be able to use 
that as a signal about the reliability of the DoT service.

You can see a variation on this problem in draft-ietf-tls-svcb-ech, which says 
that ECH-aware clients can distinguish between "fail open" and "fail closed" by 
whether ECH is offered on all records in the ServiceMode RRset.  This works 
because ECH-aware clients never fall back from ECH to non-ECH within a single 
ServiceMode record, so "fail closed" is expressible by offering ECH on every 
record in the RRset.

We currently don't have a no-fallback rule like that for encrypted transports 
in DELEG.  We could certainly add one, but doing so would likely double the 
number of DELEG ServiceMode records for decades.  That's inconvenient, 
especially if these records start to include nontrivial payloads.

--Ben

From: DNSOP  on behalf of Edward Lewis 

Sent: Wednesday, February 14, 2024 7:23 AM
To: Manu Bretelle 
Cc: dnsop@ietf.org 
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting 
expectations in protocol definitions

From: Manu Bretelle  Date: Tuesday, February 13, 2024 at 
19: 03 To: Edward Lewis  Cc: "dnsop@ ietf. org" 
 Subject: Re: [DNSOP] [Ext] Re: General comment about
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

From: Manu Bretelle 
Date: Tuesday, February 13, 2024 at 19:03
To: Edward Lewis 
Cc: "dnsop@ietf.org" 
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting 
expectations in protocol definitions



First - why am I resisting this proposal?  I believe that for the sake of 
operations, development of protocols must trend towards simplicity.  I would 
add a flag or field when necessary and only then, lest it be forgotten (a 
burden with no benefit upon code maintainers) or worse a stumbling block 
(misused, mis-set, generally mis-understood).



On Tue, Feb 13, 2024 at 7:35 AM Edward Lewis 
mailto:edward.le...@icann.org>> wrote:





>An operator dipping its toes with DELEG and encrypted protocols may be willing 
>to signal to a resolver that such failures are likely operational failure 
>because this is a testing endpoint that may be unstable due to lack of 
>operational expertise. A privacy aware resolver can then decide to fallback on 
>clear-text. Again, there is nothing preventing the resolver to fail hard here, 
>this is out of the control of the auth server operator. All that can be done 
>is to "signal".



Wouldn’t the availability of the fallback transport be enough signal that the 
service operator does not have full faith in the preferred transport?  Having a 
separate flag is like a second source of data, there might be an inconsistency 
between the two, which is a generic form of root cause.



>I could also imagine an operator going through their first cert rotation to be 
>erring on the side of safety and switching to "testing" mode temporarily.

A bit of my concern is that sometimes we forget to remove the training wheels 
once we’ve learned.  A common error in operations is to forget the cleanup 
phase (remove old files, etc.) once new functionality has been proven.  This is 
a reason why I’m hesitant to support having a flag like this.

>If you look back at DNSSEC, had it been possible to turn DNSSEC in 
>"permissive" mode, would more operators have taken the leap to enable it 
>knowing that resolvers that would validate records would have been willing to 
>fallback while the flag is on? I think from an operational point of view, this 
>is something that can be of great help to build operational confidence and 
>expertise without taking the risk to break one's DNS.



Yes, yes it would.  Early on there was criticism that DNSSEC was “ok” or 
“fail”.  When operators messed up their key rotations (this happened quite 
often around 2010), there were calls to “purge caches” and even some thought 
given to automating a way for operators to initiate a global cache purge of 
their data.  (Failed, of course - there’s no way.)  This was followed by the 
development of negative trust anchors after the COMCAST/NASA.gov issue, 
something that was an uphill battle by operators to get documented in an IETF 
document.  More recently, an operator asked me about a developing a new 
resource record type that could be published at a zone apex to 

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

[Ben Schwartz]

Manu and I have now published a draft describing this "testing" flag: 
https://datatracker.ietf.org/doc/draft-manuben-svcb-testing-flag/

While we think this is relevant to DELEG, it is entirely independent and could 
be used in any SVCB setting (although it doesn't have any obvious utility for 
HTTPS records at present).

--Ben Schwartz

From: Manu Bretelle 
Sent: Wednesday, February 7, 2024 2:19 PM
To: Peter Thomassen 
Cc: Edward Lewis ; Ben Schwartz ; 
dnsop@ietf.org 
Subject: Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting 
expectations in protocol definitions

On Thu, Feb 1, 2024 at 4: 49 AM Peter Thomassen  wrote: On 
2/1/24 13: 34, Edward Lewis wrote: > The proper response will depend on the 
reason - more accurately the presumed (lacking any out-of-band signals) reason 
- why
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd


On Thu, Feb 1, 2024 at 4:49 AM Peter Thomassen 
mailto:pe...@desec.io>> wrote:


On 2/1/24 13:34, Edward Lewis wrote:
> The proper response will depend on the reason - more accurately the presumed 
> (lacking any out-of-band signals) reason - why the record is absent.

Barring any other information, the proper response should IMHO not depend on 
the presumed reason, but assume the worst case. Anything else would break 
expected security guarantees.


Agreed, I don't think that the protocol should prescribe what to do in case of 
"operational error". Differentiating an "operational error" from an actual 
malicious interference is very likely going to be a slippery slope.
That being said, I think it will be useful for adoption that resolvers provide 
a feature to use DELEG and fallback to NS when things are not correct. This is 
not something that is to be part of the protocol though.

What I see could be useful is if we could signal something alike the qualifier 
in SPF [0]. This way an operator could onboard their zone into DELEG in 
"testing mode", allowing them to enable DELEG with the comfort of falling back 
to NS, build confidence and flip the switch. This could have the side effect of 
ever having DELEG delegations in "testing mode" though.


[0] https://www.spf-record.com/syntax<https://www.spf-record.com/syntax>

Manu



> From observations of the deployment of DNSSEC, [...]
> It’s very important that a secured protocol be able to thwart or limit damage 
> due to malicious behavior, but it also needs to tolerate benign operational 
> mistakes.  If mistakes are frequent and addressed by dropping the guard, then 
> the security system is a wasted in investment.

That latter sentence seems right to me, but it doesn't follow that the protocol 
needs to tolerate "benign operational mistakes".

Another approach would be to accompany protocol deployment with a suitable set 
of automation tools, so that the chance of operational mistakes goes down. That 
would be my main take-away from DNSSEC observations.

In other words, perhaps we should consider a protocol incomplete if the spec 
doesn't easily accommodate automation and deployment without it would yield 
significant operational risk.

Let's try to include automation aspects from the beginning.

Peter

--
https://desec.io/<https://desec.io/>

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

Re: [DNSOP] General comment about downgrades vs. setting expectations in protocol definitions

[Ben Schwartz]

In this line of reasoning, let's remember the "herd immunity" effect.  If 
receivers mostly respond to expectation violations by transparent fallback, an 
attacker on the wire has more incentive to attempt the downgrade attack.  If 
receivers mostly "fail closed", this incentive is reduced.  This is a 
collective security effect, not something that can be determined unilaterally 
by each receiver.

--Ben Schwartz

From: DNSOP  on behalf of Edward Lewis 

Sent: Tuesday, January 30, 2024 1:21 PM
To: dnsop@ietf.org 
Subject: [DNSOP] General comment about downgrades vs. setting expectations in 
protocol definitions

!---|
  This Message Is From an External Sender

|---!

I hear talk about "downgrade attacks" frequently, across different ideas.  
Hearing it again in the context of DELEG, I had this thought.

We often wind up mired in discussions about downgrades, what they mean, the 
consequences.  I'd suggest, as definers of protocols, we think in terms of 
ensuring that receivers of messages have an expectation of something.  Inside 
protocol rules, data may be expected and arrive, expected and not, unexpected 
and arrive, or unexpected and not arrive.  A downgrade attack is a diagnosis of 
"expected and not".

A protocol ought to be documented to set up the receiver's expectations and 
define what the receiver does when they are not met.

Apologies for this generic message, when looking at the DELEG documents again, 
it'll be something I'll keep in mind.  I.e., the proposal to define one of the 
flags in the DNSKEY resource record format is setting up an expectation

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

Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1

[Ben Schwartz]

Negotiation is handled via the SVCB "mandatory" mechanism: 
https://datatracker.ietf.org/doc/html/rfc9460#name-servicemode-rr-compatibilit

Basically, extensions are ignorable by default unless they are marked 
mandatory.  If a record has a mandatory parameter that you don't understand, 
you skip that record.

--Ben

From: DNSOP  on behalf of John Levine 
Sent: Tuesday, January 30, 2024 10:11 AM
To: dnsop@ietf.org 
Cc: d...@fl1ger.de 
Subject: Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1

!---|
  This Message Is From an External Sender

|---!

It appears that Ralf Weber   said:
>I agree that future extensions will require code changes, but having a
>record type that is extensible from the start might make it easier to
>deploy new parameters then it is to do a full RRTYPE, at least that is
>the hope.

If the RRTYPE is extensible, how do two DNS servers negotiate which
extensions they can handle?  So far we have been fairly careful to
add things in a way that either you do it or you don't and even that
has problems we all have seen.

R's,
John

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

Re: [DNSOP] DELEG and parent only resolution

[Ben Schwartz]

To your last point, I've proposed some examples of how "alpn" and "tlsa" ought 
to work here: https://github.com/fl1ger/deleg/pull/16/files

--Ben Schwartz

From: DNSOP  on behalf of Kazunori Fujiwara 

Sent: Tuesday, January 30, 2024 1:55 AM
To: dnsop@ietf.org 
Subject: [DNSOP] DELEG and parent only resolution

!---|
  This Message Is From an Untrusted Sender
  You have not previously corresponded with this sender.
|---!

I read draft-dnsop-deleg-00.

It proposes new name resolution using only information on the parent side.

In the past, the dnsop WG debated parent centric name resolution
and child centric, and some people did not like parent centric.

If people prefer parent-centric/parent-only name resolution,
there are solutions other than DELEG,
such as parent centric name resolution,
distinguishing the handling of authoritative data, referrals, and glue,
and adding a signature of referral/in-domain in the parent.

Is anyone interested in proceeding with minor fixes that are not DELEG?
Previously, I prposed draft-fujiwara-dnsop-resolver-update and
draft-fujiwara-dnsop-delegation-information-signer.
(They are too old and need to be updated.)

Or, I would like to read complete version of draft-dnsop-deleg
that have alpn and tlsa parameters.

Regards,

--
Kazunori Fujiwara, JPRS 

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

Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

[Ben Schwartz]

Thanks for pointing out the attack of using random NS RRSets ("NS 
$RANDOM.victim.example") with zero TTL.  However, I believe this is still 
mitigated well by RFC 9520 Section 3.2: "When an incoming query matches a 
cached resolution failure, the resolver MUST NOT send any corresponding 
outgoing queries until after the cache entries expire.".

An attacker might be able to bypass this cache by using a different  QNAME 
each time to initiate the attack.  Excluding DNSSEC, this would still only 
result in at most minor amplification due to the resolver's NS limit.  (The 
attacker must emit two packets in each round (the query and a large NS 
response), whereas the victim must emit K small NXDOMAIN responses, where K is 
the resolver's NS limit.)

We should be able to measure the actual amplification achieved by this attack 
in modern recursive resolver implementations.  If it is large, then we should 
consider possible mitigations.

--Ben

From: zuop...@cnnic.cn 
Sent: Sunday, January 7, 2024 1:59 AM
To: Ben Schwartz ; dnsop 
Subject: Re: Re: [DNSOP] Fw: New Version Notification for 
draft-zuo-dnsop-delegation-confirmation-00.txt

Thanks for your valuable comment ! negative caching (RFC 2308) and failure 
caching (RFC 9520) can mitigate NXNSAttack–like attack to some extent, but I 
don’t think they are sufficient enough, because for a resolver that adopts 
these 2 RFCs
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Thanks for your valuable comment !

negative caching (RFC 2308) and failure caching (RFC 9520) can mitigate 
NXNSAttack–like attack to some extent, but I don’t think they are sufficient 
enough, because for a resolver that adopts these 2 RFCs only caches failure 
answer for a single record at a time, it can't avoid queries for a large number 
of random NS records.

Aggressive NSEC (RFC 8198) is useful against to NXNSAttack –like attack, 
because it allows a DNSSEC-validating resolver to generate negative answers 
within a range. But if a NSEC3 RR has an Opt-Out flag, it can’t be used for 
aggressive negative caching.  In addition, DNSSEC adoption rate remains low in 
some area and this situation may not change significantly over a long period of 
time for policy reasons.

Compared to DNSSEC, the draft is relatively simple, it uses OPT RR option to 
confirm NS record only when a resolver is requesting address (Glue record) of 
delegation points. And it is compatible with current DNS protocol.



zuop...@cnnic.cn

From: Ben Schwartz<mailto:bemasc=40meta@dmarc.ietf.org>
Date: 2024-01-03 23:49
To: zuop...@cnnic.cn<mailto:zuop...@cnnic.cn>; dnsop<mailto:dnsop@ietf.org>
Subject: Re: [DNSOP] Fw: New Version Notification for 
draft-zuo-dnsop-delegation-confirmation-00.txt
Thanks for this proposal.  I note the following text on the motivation in 
Section 1.3:

   If a malicious Delegated Zone specifies a large amount of
   fake NS pointing to victim zones, much more queries from recursive
   DNS to victim zones will be triggered.  This protocol vulnerability
   can be abused to launch new types of attacks, such as NXNSAttack.

   Current mitigation measures against such attacks are based on
   optimizing DNS software implementations, such as limiting the number
   of outgoing queries for NS glue.

I think this is a helpful description of the motivation, but it omits some 
additional mitigations that already exist, such as negative caching (RFC 2308), 
failure caching (RFC 9520), and Aggressive NSEC (RFC 8198).  I don't see any 
argument in this draft that the current mitigations are insufficient, or are 
likely to fail in the future.

This draft adds a significant amount of complexity to the DNS protocol.  I 
don't think it makes sense to add complexity if our current mitigations are 
sufficient.

--Ben Schwartz

From: DNSOP  on behalf of zuop...@cnnic.cn 

Sent: Tuesday, January 2, 2024 2:35 AM
To: dnsop 
Subject: [DNSOP] Fw: New Version Notification for 
draft-zuo-dnsop-delegation-confirmation-00.txt

‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd

  Hi all,

 We submitted a draft about DNS delegation confirmation.

 In the current DNS delegation mechanism, a delegated zone/child zone c

Re: [DNSOP] Fw: New Version Notification for draft-zuo-dnsop-delegation-confirmation-00.txt

[Ben Schwartz]

Thanks for this proposal.  I note the following text on the motivation in 
Section 1.3:

   If a malicious Delegated Zone specifies a large amount of
   fake NS pointing to victim zones, much more queries from recursive
   DNS to victim zones will be triggered.  This protocol vulnerability
   can be abused to launch new types of attacks, such as NXNSAttack.

   Current mitigation measures against such attacks are based on
   optimizing DNS software implementations, such as limiting the number
   of outgoing queries for NS glue.

I think this is a helpful description of the motivation, but it omits some 
additional mitigations that already exist, such as negative caching (RFC 2308), 
failure caching (RFC 9520), and Aggressive NSEC (RFC 8198).  I don't see any 
argument in this draft that the current mitigations are insufficient, or are 
likely to fail in the future.

This draft adds a significant amount of complexity to the DNS protocol.  I 
don't think it makes sense to add complexity if our current mitigations are 
sufficient.

--Ben Schwartz

From: DNSOP  on behalf of zuop...@cnnic.cn 

Sent: Tuesday, January 2, 2024 2:35 AM
To: dnsop 
Subject: [DNSOP] Fw: New Version Notification for 
draft-zuo-dnsop-delegation-confirmation-00.txt

‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd

  Hi all,

 We submitted a draft about DNS delegation confirmation.

 In the current DNS delegation mechanism, a delegated zone/child zone can 
specify any NS records at the zone apex without requiring confirmation from the 
zone maintaining Glue records of these NS record. This could be exploited to 
lunch new types of attacks such as NXNSattack.

 This draft suggests a lightweight and backward-compatible mechanism to 
mitigate the risk of these attacks.

 Any comments are welcome!


zuop...@cnnic.cn

From: internet-drafts<mailto:internet-dra...@ietf.org>
Date: 2024-01-02 14:42
To: Peng Zuo<mailto:zuop...@cnnic.cn>; Zhiwei Yan<mailto:y...@cnnic.cn>
Subject: New Version Notification for 
draft-zuo-dnsop-delegation-confirmation-00.txt
A new version of Internet-Draft draft-zuo-dnsop-delegation-confirmation-00.txt
has been successfully submitted by Zhiwei Yan and posted to the
IETF repository.

Name: draft-zuo-dnsop-delegation-confirmation
Revision: 00
Title:A lightweight DNS delegation confirmation protocol
Date: 2024-01-01
Group:Individual Submission
Pages:13
URL:  
https://www.ietf.org/archive/id/draft-zuo-dnsop-delegation-confirmation-00.txt<https://www.ietf.org/archive/id/draft-zuo-dnsop-delegation-confirmation-00.txt>
Status:   
https://datatracker.ietf.org/doc/draft-zuo-dnsop-delegation-confirmation/<https://datatracker.ietf.org/doc/draft-zuo-dnsop-delegation-confirmation/>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-zuo-dnsop-delegation-confirmation<https://datatracker.ietf.org/doc/html/draft-zuo-dnsop-delegation-confirmation>


Abstract:

   Delegation occurs when an NS record is added in the parent zone for
   the child origin.  In the current DNS delegation mechanism, a
   delegated zone/child zone (see Section1.1 for definition of delegated
   zone) can specify any NS records at the zone apex without requiring
   confirmation from the zone maintaining Glue records of the NS record.
   Recently, new types of attacks that exploit this flaw have been
   discovered.  This draft suggests a protocol-level solution for DNS
   delegation confirmation to reduce the risk of these attacks.



The IETF Secretariat



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-dane-03.txt

[Ben Schwartz]

I'm not personally aware of any "https" origins that ignore the "Host" header.  
I expect that there are a few out there, running buggy custom server software 
on very small origins, but any widely used HTTP server implementation will have 
the correct behavior.  In particular, any HTTP server implementation that 
supports virtual-hosting must inspect the Host header to work at all.

--Ben

From: DNSOP  on behalf of Viktor Dukhovni 

Sent: Saturday, December 2, 2023 1:14 PM
To: dnsop@ietf.org 
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-dane-03.txt

!---|
  This Message Is From an External Sender

|---!

> On 29 Nov 2023, at 1:14 pm, Ben Schwartz  wrote:
>
> This draft is essentially identical to -02 except for the new Appendix A, 
> which discuss the impact of Unknown Key-Share Attacks: 
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-dane-03#name-unknown-key-share-attacks
>
> I would appreciate more review on that section, which attempts a fairly 
> tricky security analysis.
>
> Otherwise, I believe this draft is ready for WGLC (except for the 
> Acknowledgements section, which still needs to be filled in).

Thanks for this work.  I have read the draft and on an initial read-through,
only found a trivial editorial nit:

Section 5.2, second paragraph:

s/To prevents the above .../To prevent the above .../

Otherwise, the text looks good.  That said, indeed Appendix A deserves more 
care than
an initial read-through.

Do you know whether the requirements of 
https://www.rfc-editor.org/rfc/rfc9110#section-7.4
essentially universally supported by HTTPS (1.1 or later) servers?  Or is a 
non-trivial,
perhaps significant, minority of servers that would be vulnerable to UKS 
despite section 7.4?

The non-HTTPS protocols are easier to reason about, and for these I don't 
expect to need to
search for unexplored corner cases.

--
Viktor.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-dane-03.txt

[Ben Schwartz]

Hi DNSOP,

This draft is essentially identical to -02 except for the new Appendix A, which 
discuss the impact of Unknown Key-Share Attacks: 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-dane-03#name-unknown-key-share-attacks

I would appreciate more review on that section, which attempts a fairly tricky 
security analysis.

Otherwise, I believe this draft is ready for WGLC (except for the 
Acknowledgements section, which still needs to be filled in).

--Ben

From: DNSOP  on behalf of internet-dra...@ietf.org 

Sent: Wednesday, November 29, 2023 1:10 PM
To: i-d-annou...@ietf.org 
Cc: dnsop@ietf.org 
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-dane-03.txt

!---|
  This Message Is From an External Sender

|---!

Internet-Draft draft-ietf-dnsop-svcb-dane-03.txt is now available. It is a
work item of the Domain Name System Operations (DNSOP) WG of the IETF.

   Title:   Using DNSSEC Authentication of Named Entities (DANE) with DNS 
Service Bindings (SVCB) and QUIC
   Authors: Benjamin M. Schwartz
Robert Evans
   Name:draft-ietf-dnsop-svcb-dane-03.txt
   Pages:   13
   Dates:   2023-11-29

Abstract:

   Service Binding (SVCB) records introduce a new form of name
   indirection in DNS.  They also convey information about the
   endpoint's supported protocols, such as whether QUIC transport is
   available.  This document specifies how DNS-Based Authentication of
   Named Entities (DANE) interacts with Service Bindings to secure
   connections, including use of port numbers and transport protocols
   discovered via SVCB queries.  The "_quic" transport name label is
   introduced to distinguish TLSA records for DTLS and QUIC.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-dane/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-dane-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-svcb-dane-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [DNSOP] RFC 9460: ServiceParamKey for web integrity

[Ben Schwartz]

Using DNS in this way is particularly operationally challenging because DNS is 
"eventually consistent".  DNS TTLs are routinely "stretched" by resolvers and 
clients: even short-lived records can take many hours to reach 100% effective 
rollout.  In the "B" proposal, every HTTP content update could be blocked for 
hours or days waiting on DNS, with no way for the server operator to know when 
it is finally safe to make the change.

I think DNS is simply the wrong tool for this job.  The most direct solution 
I've thought of involves a new X.509 OID for "HTTP content auditor" and a 
signature from the auditor on every returned resource, but that's off-topic for 
this working group.  You might also want to review the Mirror Protocol, which 
solves a different variant of this problem: 
https://datatracker.ietf.org/doc/draft-group-privacypass-consistency-mirror/.

--Ben Schwartz


From: James Addison 
Sent: Tuesday, November 28, 2023 6:51 AM
To: Ben Schwartz 
Cc: dnsop@ietf.org 
Subject: Re: [DNSOP] RFC 9460: ServiceParamKey for web integrity

!---|
  This Message Is From an Untrusted Sender
  You have not previously corresponded with this sender.
|---!

Hi Ben,

Thanks for your response.  Please find some comments inline, with one
intra-line edit from your message, annotated with pipe symbols.

On Tue, Nov 28, 2023 at 3:35 AM Ben Schwartz  wrote:
>
> Hi James,
>
> RFC 9460 is quite flexible, and its IANA registration procedures are 
> relatively open, so there are few barriers to attempting a specification like 
> you describe.|

Thanks - I'd like to be able to participate.  The intended goal is to
find existing mechanisms to provide high integrity assurance for
delivery of a static single-page HTML web application to clients -- or
to explore what those mechanisms could be if they do not yet exist.

>  |However, I do not think it would be a wise approach, for several reasons:
>
> HTTP is not normally used to serve a single resource per origin.

Acknowledged - I don't have an on-topic response for this, although I
do believe that integrity within websites (and I admit that is not all
HTTP services) could be enhanced, and am aware of one[1] such request
for the W3C SRI spec.

> HTTP resources admit a variety of representations, resulting in distinct 
> digest values.

This is certainly true in a number of situations - dynamic websites
and differing character set encodings spring to mind.  Despite that I
think that there are cases where it is valuable to deliver static
content with high integrity.  Doing so can align well with client
implementation simplicity and cache hit rates.

> The security offered by this feature would be extremely limited in the common 
> case where DNSSEC is not applied end-to-end.

The proposal should allow some limited tampering of webserver
responses to be detected in the absence of DNSSEC, but I agree that
adding DNSSEC provides stronger guarantees.

> Deploying this feature would be operationally challenging if the content can 
> ever change, because of the need to perform coordinated updates to HTTP 
> content and DNS records.

The deployment mechanism that I use currently -- a TXT record where
the character string is prefixed with an uppercase B -- involves two
invocations of the openssl command (one dgst, one base64) and then
entry of the resulting hash into DNS.  For software development
lifecycles that include automation, I do not believe that it should be
onerous to optionally publish one or two digest values into DNS,
although I also do not think that the specification should constrain
the record update procedure.

> Resource integrity is most valuable when the resource digest is held by a 
> party who is not the resource publisher, in order to prevent the publisher 
> from substituting a malicious resource.  However, in this design, the 
> resource publisher (i.e. the origin) also controls the DNS records on its own 
> zone.

Agreed, although I think it should be acceptable (despite perhaps
appearing less trustworthy) for both entities to be the same.

To further improve integrity (outside of the scope of either the DNS
or SRI specifications) it could make sense to allow independent
parties to rebuild the deployed web resource content from its source
code (perhaps retrieved from yet another entity) -- to verify that all
three of the DNS-published digest, the digest calculated from the
fetched resource, and the digest calculated after building the web
application entrypoint page from source have the same value (this is
similar to the idea of reproducible builds).

[1] - https://github.com/w3c/webappsec/issues/497

[snip]
> 
> From: DNSOP  on behalf of James Addison 
> 

Re: [DNSOP] RFC 9460: ServiceParamKey for web integrity

[Ben Schwartz]

Hi James,

RFC 9460 is quite flexible, and its IANA registration procedures are relatively 
open, so there are few barriers to attempting a specification like you 
describe.  However, I do not think it would be a wise approach, for several 
reasons:

  *   HTTP is not normally used to serve a single resource per origin.
  *   HTTP resources admit a variety of representations, resulting in distinct 
digest values.
  *   The security offered by this feature would be extremely limited in the 
common case where DNSSEC is not applied end-to-end.
  *   Deploying this feature would be operationally challenging if the content 
can ever change, because of the need to perform coordinated updates to HTTP 
content and DNS records.
  *   Resource integrity is most valuable when the resource digest is held by a 
party who is not the resource publisher, in order to prevent the publisher from 
substituting a malicious resource.  However, in this design, the resource 
publisher (i.e. the origin) also controls the DNS records on its own zone.

I believe in the value of enabling web servers to commit to the contents of 
certain web pages, but I don't think DNS is likely to play a significant role 
in any good solution to that problem.

--Ben Schwartz

From: DNSOP  on behalf of James Addison 

Sent: Wednesday, November 22, 2023 12:52 PM
To: dnsop@ietf.org 
Subject: [DNSOP] RFC 9460: ServiceParamKey for web integrity

!---|
  This Message Is From an Untrusted Sender
  You have not previously corresponded with this sender.
|---!

Hello,

This is a follow-up / redirection from a discussion thread[1] on the
dnsext mailing list regarding a proposal for an additional DNS RR
type.  Feedback received there indicates that instead of a distinct
record type, a ServiceParamKey for use with the RFC 9460 HTTPS record
type could potentially cater to the requirements.

In short summary of the previous thread: the request is for addition
of an integrity record, in a similar or identical format to that
specified by W3C HTML SubResource Integrity specification[2], to be
available alongside existing A/ records for domains containing
webservers.  The contents of the record would be used by web browser
clients to validate whether the response they receive from an initial
request to the root URI path from any of the hosts in the domain
matches an expected hash value.

The motivation of the request is to provide an optional
out-of-HTTP-band integrity check for web clients that download a
single-page web application from a fixed  URI path on a domain name.
The risk that it intends to mitigate is that one or more hosts within
the domain could have become compromised to respond with web content
that does not match that intended by the domain owner, regardless of
the presence of TLS during the web requests.

I have two questions about this in relation to RFC 9460:

* Would it seem valid to suggest an HTTPS ServiceParamKey to contain
an integrity record of this kind?

* Given a desire to deliver content using _either_ plaintext HTTP _or_
TLS-enabled HTTPS (traditionally TCP ports 80, 443 respectively) -
would Section 9.5 of RFC 9460 (footnote three) conflict with the
plaintext HTTP delivery mechanism?

Thank you,
James

[1] - https://mailarchive.ietf.org/arch/msg/dnsext/vtbGXqBKSKzBqYAAE1VMhATiuw4/

[2] - https://www.w3.org/TR/2016/REC-SRI-20160623/

[3] - https://www.rfc-editor.org/rfc/rfc9460.html#section-9.5

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

Re: [DNSOP] DNS in Constrained Network Scenarios

[Ben Schwartz]

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).

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.

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

--Ben


From: DNSOP  on behalf of Martine Sophie Lenders 

Sent: Friday, November 10, 2023 3:42 PM
To: dnsop 
Cc: dns...@ietf.org 
Subject: [DNSOP] DNS in Constrained Network Scenarios

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

[Ben Schwartz]

Thus far, I don't think we've heard from any browser vendors who believe that 
it would be prudent and worthwhile to display server-generated error pages of 
this kind to ordinary end-users on their personal devices.  Absent that 
support, I think it would not be sensible for us to try to develop such a 
mechanism.

(If such a browser vendor did appear, I would argue against them on both 
security and human rights grounds.)

--Ben

From: Gianpaolo Angelo Scalone, Vodafone 
Sent: Thursday, November 9, 2023 11:23 AM
To: Tim Wicinski 
Cc: Ben Schwartz ; Ben Schwartz 
; dnsop@ietf.org 
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

Hi Tim, sorry the comment was more for Ben :-) on the consumer users use case. 
Inviato da Outlook per Android C2 General From: Tim Wicinski  Sent: Thursday, November 9, 2023 5: 21: 09 PM To: Gianpaolo Angelo Scalone,
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Hi Tim, sorry the comment was more for Ben :-) on the consumer users use case.

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>


C2 General


From: Tim Wicinski 
Sent: Thursday, November 9, 2023 5:21:09 PM
To: Gianpaolo Angelo Scalone, Vodafone 
Cc: Ben Schwartz ; Ben Schwartz 
; dnsop@ietf.org 
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt


External Email: Be cautious about the sender email address, attachments and 
links. If uncertain use Report Message button.

Thanks both of you - I knew I was missing this when I hit send.

tim


On Thu, Nov 9, 2023 at 11:20 AM Gianpaolo Angelo Scalone, Vodafone 
mailto:gianpaolo-angelo.scal...@vodafone.com>>
 wrote:
Hi Tim ,
I'm not proposing that the browser shows an https page in any use case,
Only as result of out of band request or if received from well known service,
Eventually by creating a service for hosting well known high reputation static 
only blocking pages.
Without this the user remain subject to false positives without being able to 
request a reclassification,
Resulting in potentially unwanted censorship...

Gianpaolo

Inviato da Outlook per Android<https://aka.ms/AAb9ysg>



C2 General

________
Da: Ben Schwartz 
mailto:40meta@dmarc.ietf.org>>
Inviato: Giovedì, Novembre 9, 2023 5:14:26 PM
A: Tim Wicinski mailto:tjw.i...@gmail.com>>; Ben Schwartz 
mailto:bem...@meta.com>>
Cc: Gianpaolo Angelo Scalone, Vodafone 
mailto:gianpaolo-angelo.scal...@vodafone.com>>;
 dnsop@ietf.org<mailto:dnsop@ietf.org> mailto:dnsop@ietf.org>>
Oggetto: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt


External Email: Be cautious about the sender email address, attachments and 
links. If uncertain use Report Message button.

Tim,

The EDE error codes cover that use case already, by allowing the browser to 
generate that error page, and without requiring the DNS filter to run an HTTP 
server at all.

--Ben Schwartz

From: DNSOP mailto:dnsop-boun...@ietf.org>> on behalf 
of Tim Wicinski mailto:tjw.i...@gmail.com>>
Sent: Thursday, November 9, 2023 10:48 AM
To: Ben Schwartz 
mailto:40meta@dmarc.ietf.org>>
Cc: Gianpaolo Angelo Scalone, Vodafone 
mailto:40vodafone@dmarc.ietf.org>>;
 dnsop@ietf.org<mailto:dnsop@ietf.org> mailto:dnsop@ietf.org>>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

On Thu, Nov 9, 2023 at 10: 02 AM Ben Schwartz  wrote: Note that "mailto" URIs can pre-populate subject and body contents, 
so information about the specific blocked item and other metadata could
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd


On Thu, Nov 9, 2023 at 10:02 AM Ben Schwartz 
mailto:40meta@dmarc.ietf.org>> wrote:
Note that "mailto" URIs can pre-populate subject and body contents, so 
information about the specific blocked item and other metadata could be 
populated automatically.  This seems sufficient for enterprise use cases like 
allowing employees to tell corporate IT that they are blocking something 
incorrectly.

HTTP error pages are primarily relevant to end users on personal devices whose 
access is being blocked by their ISP.   That is not an environment in which it 
is safe or appropriate for the network to inject block pages.

Ben

In the Enterprise case , the end user does need to see some simple web based 
feedback.  My employer's Firewalls throw up a very basic "You can not go to 
example.com<http://example.com/>".

tim



--Ben Schwartz

From: DNSOP mailto:dnsop-boun...@ietf.org>> on behalf 
of Gianpaolo Angelo Scalone, Vodafone 
mailto:40vodafone@dmarc.ietf.org>>
Sent: Thursday, November 9, 2023 4:08 AM
To: dnsop@ietf.org<mailto:dnsop@ietf.org> 
mailto:dnsop@i

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

[Ben Schwartz]

Tim,

The EDE error codes cover that use case already, by allowing the browser to 
generate that error page, and without requiring the DNS filter to run an HTTP 
server at all.

--Ben Schwartz

From: DNSOP  on behalf of Tim Wicinski 

Sent: Thursday, November 9, 2023 10:48 AM
To: Ben Schwartz 
Cc: Gianpaolo Angelo Scalone, Vodafone 
; dnsop@ietf.org 

Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

On Thu, Nov 9, 2023 at 10: 02 AM Ben Schwartz  wrote: Note that "mailto" URIs can pre-populate subject and body contents, 
so information about the specific blocked item and other metadata could
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd


On Thu, Nov 9, 2023 at 10:02 AM Ben Schwartz 
mailto:40meta@dmarc.ietf.org>> wrote:
Note that "mailto" URIs can pre-populate subject and body contents, so 
information about the specific blocked item and other metadata could be 
populated automatically.  This seems sufficient for enterprise use cases like 
allowing employees to tell corporate IT that they are blocking something 
incorrectly.

HTTP error pages are primarily relevant to end users on personal devices whose 
access is being blocked by their ISP.   That is not an environment in which it 
is safe or appropriate for the network to inject block pages.

Ben

In the Enterprise case , the end user does need to see some simple web based 
feedback.  My employer's Firewalls throw up a very basic "You can not go to 
example.com<http://example.com>".

tim



--Ben Schwartz

From: DNSOP mailto:dnsop-boun...@ietf.org>> on behalf 
of Gianpaolo Angelo Scalone, Vodafone 
mailto:40vodafone@dmarc.ietf.org>>
Sent: Thursday, November 9, 2023 4:08 AM
To: dnsop@ietf.org<mailto:dnsop@ietf.org> 
mailto:dnsop@ietf.org>>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

Hi, I still think that a mechanism to reach an HTTPS resource is needed. 
Considering the security implications of rendering directly an HTTPS URI, It 
could be an additional field, to be used by the client For out of band 
connection to retrieve

Hi,

I still think that a mechanism to reach an HTTPS resource is needed.

Considering the security implications of rendering directly an HTTPS URI,

It could be an additional field, to be used by the client

  *   For out of band connection to retrieve the needed page info from 
resolvers with high reputation that have agreements with the browser
  *   To connect to an high reputation service (to be created) having the only 
purpose to host blocking pages on behalf of the various DNS filtering services
 *   This high reputation service would be defined in a separated RFC
 *   Access criteria and content to be defined
 *   Management criteria to be defined



Having such a service would allow to access high reputation information about 
the eventual blocking reason and provide the end user modern methods to 
understand the blocking or request an amendment in case of false positives.



The mechanism proposed in draft-ietf-dnsop-structured-dns-error-07.txt is a big 
improvement respect the existing situation, but still requires some knowledge 
that common users may not have and so limit the capability to require 
amendments only to users well educated on the topic.

With a SIP contact or an EMAIL contact the end user should know what to ask 
very well, with an HTTPS URI a request to amend the blocking could be populated 
with the relevant information, empowering also less experienced users (here we 
are sort of providing a pre internet solution to an internet problem).



Many countries request filtering of DNS traffic for CSAM or for Adult Content 
Filtering reasons, so a good way to avoid false positives would provide the 
population a better access to internet.



Gianpaolo




C2 General

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

[Ben Schwartz]

Note that "mailto" URIs can pre-populate subject and body contents, so 
information about the specific blocked item and other metadata could be 
populated automatically.  This seems sufficient for enterprise use cases like 
allowing employees to tell corporate IT that they are blocking something 
incorrectly.

HTTP error pages are primarily relevant to end users on personal devices whose 
access is being blocked by their ISP.   That is not an environment in which it 
is safe or appropriate for the network to inject block pages.

--Ben Schwartz

From: DNSOP  on behalf of Gianpaolo Angelo Scalone, 
Vodafone 
Sent: Thursday, November 9, 2023 4:08 AM
To: dnsop@ietf.org 
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt

Hi, I still think that a mechanism to reach an HTTPS resource is needed. 
Considering the security implications of rendering directly an HTTPS URI, It 
could be an additional field, to be used by the client For out of band 
connection to retrieve


Hi,

I still think that a mechanism to reach an HTTPS resource is needed.

Considering the security implications of rendering directly an HTTPS URI,

It could be an additional field, to be used by the client

  *   For out of band connection to retrieve the needed page info from 
resolvers with high reputation that have agreements with the browser
  *   To connect to an high reputation service (to be created) having the only 
purpose to host blocking pages on behalf of the various DNS filtering services
 *   This high reputation service would be defined in a separated RFC
 *   Access criteria and content to be defined
 *   Management criteria to be defined



Having such a service would allow to access high reputation information about 
the eventual blocking reason and provide the end user modern methods to 
understand the blocking or request an amendment in case of false positives.



The mechanism proposed in draft-ietf-dnsop-structured-dns-error-07.txt is a big 
improvement respect the existing situation, but still requires some knowledge 
that common users may not have and so limit the capability to require 
amendments only to users well educated on the topic.

With a SIP contact or an EMAIL contact the end user should know what to ask 
very well, with an HTTPS URI a request to amend the blocking could be populated 
with the relevant information, empowering also less experienced users (here we 
are sort of providing a pre internet solution to an internet problem).



Many countries request filtering of DNS traffic for CSAM or for Adult Content 
Filtering reasons, so a good way to avoid false positives would provide the 
population a better access to internet.



Gianpaolo




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

Re: [DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

[Ben Schwartz]

Thanks!  I think this is an improvement.  Ideally this would use an existing 
schema language instead of inventing a new one, but your approach here seems 
reasonable.

I think the draft should probably add Mnemonic and Data Type columns to the 
EDNS OPT registry, to make sure that future opcodes are representable.

Nits:

Looking at dig output, I see that the built-in fields are represented in a 
manner that is clearly distinct from the option-codes:

; EDNS: version: 0, flags: do; udp: 1232
; OPT=15: 00 14 ("..")

I think you could accomplish a similar effect (and reduce divergence from dig) 
by changing "Version", "FLAGS", "RCODE" and "UDPSIZE" to lower-case.

The LLQ option seems like it would benefit from an "object" type instead of 
"list".

Section 13 (on escaping) highlights what a mess we have with weird characters 
in DNS names and zone files.  This was a big pain in SVCB with 
character-strings and comma-separated lists, and continues to be a big pain in 
other drafts (e.g. [1]).  I think we might want to invest some time in a proper 
standard for ASCII representation of DNS names.

--Ben

[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-alias-proxy-status-05#section-2.1


From: DNSOP  on behalf of libor.peltan 

Sent: Friday, October 20, 2023 11:15 AM
To: Ben Schwartz ; libor.peltan 
; Tom Carpay ; dnsop 

Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Hi Ben, DNSOP, thank you so much for your reading and comments. We considered 
both of your suggestions useful, and substantially updated the document to 
reflect them: - for each EDNS option, abstract name, type and value are 
defined, and both
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi Ben, DNSOP,


thank you so much for your reading and comments. We considered both of your 
suggestions useful, and substantially updated the document to reflect them:

 - for each EDNS option, abstract name, type and value are defined, and both 
presentation and JSON formats are derived from those, leading to mutual 
unification

 - the presentation format is as similar as arguably possible to current 
dig/kdig text output


The new version of the draft can be seen here: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-02.html<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-02.html>


We also already have a piece of "running code": kdig 3.3.2 implements both JSON 
and presentation format in accordance to the draft.


We think this might be of interest of DNSOP.


Thanks,


Libor


Dne 29. 08. 23 v 19:01 Ben Schwartz napsal(a):
I have reviewed this draft.  It seems potentially useful and like a reasonable 
attempt to define a solution.

I would like to see a unified rule connecting the text and JSON 
representations, rather than explicitly defining new formats for each key (and 
in some cases even changing the key names, e.g. NSID vs. NSIDHEX).  For 
example, some options could be defined as having "list" type output, and then 
we could define generically how list values are represented in JSON and text.  
Similarly for numbers, strings, etc.  Alternatively, the JSON format could be 
defined first, and the text format could be defined via an algorithm that acts 
generically on the JSON values.

I think it's worth taking a close look at the existing commonly used 
presentation formats before defining a new one.  For example, it might be 
worthwhile to standardize a text representation that is closer to the current 
"dig" output, for the sake of compatibility with existing systems.

--Ben Schwartz

From: DNSOP <mailto:dnsop-boun...@ietf.org> on behalf 
of libor.peltan 
<mailto:libor.peltan=40nic...@dmarc.ietf.org>
Sent: Wednesday, May 31, 2023 4:33 AM
To: dnsop <mailto:dnsop@ietf.org>
Subject: [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Hi dsnop, we'd like to turn your attention again to our draft https: //www. 
ietf. org/archive/id/draft-peltan-edns-presentation-format-01. html We believe 
this document shall fill a missing gap in specifications, and help 
interoperability of DNS
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html>

We believe this document shall fill a missing gap in specifications, and help 
interoperability of DNS tools. Therefore, we think it'd make sense if this 
document once becomes a dnsop-homed RFC.

We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Fu

Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

[Ben Schwartz]

This draft originally proposed returning a webpage.  After reviews from the 
working group raising concern about allowing the DNS server to inject a 
webpage, it was changed to provide a contact URI instead ... but it then lists 
"https:" as an example of a suitable contact URI scheme.  This apparent 
contradiction ("https:" is not a form of contact info) strikes me as an awkward 
compromise, and a fine example of "design by committee".

Ultimately, it seems that this draft as aimed at browsers, and should provide 
information that browser makers believe can safely be displayed to users.  I 
think the most sensible solution is (1) replace the "https:" example in the 
draft with "mailto:; and (2) note that clients are free to ignore contact URIs 
with unsupported schemes.

Even a "mailto:; scheme is not without risk here, and I wouldn't be surprised 
if some browser vendors feel it is unsafe to display.  However, it sounds like 
there is some interest from potential clients, perhaps enough to support 
continuing with this draft.

--Ben

From: DNSOP  on behalf of tirumal reddy 

Sent: Friday, October 20, 2023 6:09 AM
To: Tommy Pauly 
Cc: Vodafone Gianpaolo Angelo Scalone 
; DNSOP WG 

Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

I would like to clarify that the purpose of the "c" (contact) field is not to 
display an error page but to provide contact details of the IT/InfoSec team for 
reporting misclassified DNS filtering. Its function is to report legitimate
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
I would like to clarify that the purpose of the "c" (contact) field is not to 
display an error page but to provide contact details of the IT/InfoSec team for 
reporting misclassified DNS filtering. Its function is to report legitimate 
domain names that have been incorrectly blocked due to misclassification.

There is no mention in the draft that the "c" (contact) field is intended for 
displaying an error page. It is assumed that the client application would 
handle the display of an error page, and the content of the "c" field would be 
optionally used in specific scenarios, such as TRR.

To improve clarity, we could update the draft and specify that the error page 
must be displayed by the client application, and the "c" field link may be 
optionally provided to raise complaints. Furthermore, to minimize security 
risks, the client can retrieve the URL from the contact field in an isolated 
environment. It must also take additional precautions, such as clearly labeling 
the page as untrusted. This isolation should prevent the transmission of 
cookies, block JavaScript execution, and prevent the auto-fill of credentials 
or personal information. The isolated environment should be separate from the 
user's normal browsing environment.

Cheers,
-Tiru





On Fri, 20 Oct 2023 at 01:42, Tommy Pauly 
mailto:40apple@dmarc.ietf.org>> wrote:


On Oct 19, 2023, at 12:44 PM, Warren Kumari 
mailto:war...@kumari.net>> wrote:

I still don't understand why (other than marketing/advertising) this is needed 
— the EDE "4.18. Extended DNS Error Code 17 - Filtered" ("The server is unable 
to respond to the request because the domain is on a blocklist as requested by 
the client. Functionally, this amounts to "you requested that we filter domains 
like this one.") seems to cover it.

If browsers are willing to do anything with the EDE codes (like "ERROR: Your 
DNS filtering provider says you shouldn't go here") what additional 
**important** information needs to be communicated? And if browsers are not 
willing to do anything with just EDE codes, it sure doesn't seem like they 
would want to do that **and** follow an unauthenticated URL…

Safari is now displaying the EDE-code based information! So we are willing to 
show that.

The case that might still be interesting is providing the user some (hopefully 
safe) way to contact the blocker to dispute why this is being blocked — so a 
way to send an email to an administrator, but not something else. Showing 
advertising or marketing or any arbitrary page is not something I think would 
fly.

Tommy

Anything more simply adds complexity and security risks, and entails privacy 
concerns for the user too…

W


On Thu, Oct 19, 2023 at 4:05 AM, Vodafone Gianpaolo Angelo Scalone 
mailto:Gianpaolo-Angelo.Scalone=40vodafone@dmarc.ietf.org>>
 wrote:

Hi,

I think that we have now 2 good potential compromises:

  1.  A browser interstitial page explaining that the following page is 
generated by the service that blocked the actual page, with a button indicating 
“proceed to the blocking page” and another “dismiss”
  2.  A graphical representation of the blocking page, rendered as image with 
no clickable links, with a button indicating “proceed to the blocking page” and 
another “dismiss”



This would be understandable by customers and provide a good user experience 

Re: [DNSOP] Fwd: New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

[Ben Schwartz]

This is fun to think about, but it seems to me that these networks should avoid 
any reliance on the ICANN DNS tree.  I doubt that any network of space probes 
on Io can accept the risk of a technical or governance issue on .io.

Regardless, I think the draft would more helpful if drawn from real-world(s) 
systems, rather than speculating about architectures that might apply in some 
distant hypothetical scenario.  (If some of the proposed architectures are 
inspired by real systems, I suggest adding citations to that effect.)

--Ben Schwartz

From: DNSOP  on behalf of Marc Blanchet 

Sent: Sunday, October 8, 2023 3:17 PM
To: dnsop@ietf.org 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-many-dnsop-dns-isolated-networks-00.txt

Hello, The primary use case of this draft is the deployment of naming 
infrastructure on celestial bodies networks, but could be applied for other use 
cases. Would love to get people reviews and comments. Marc. Début du message 
transféré :De: 
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Hello,
 The primary use case of this draft is the deployment of naming infrastructure 
on celestial bodies networks, but could be applied for other use cases.

Would love to get people reviews and comments.

Marc.

Début du message transféré :

De: internet-dra...@ietf.org
Objet: New Version Notification for 
draft-many-dnsop-dns-isolated-networks-00.txt
Date: 8 octobre 2023 à 15:16:10 HAE
À: "Marc Blanchet" 

A new version of Internet-Draft draft-many-dnsop-dns-isolated-networks-00.txt
has been successfully submitted by Marc Blanchet and posted to the
IETF repository.

Name: draft-many-dnsop-dns-isolated-networks
Revision: 00
Title:Domain Name System in Mostly Isolated Networks
Date: 2023-10-08
Group:Individual Submission
Pages:7
URL:  
https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.txt<https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.txt>
Status:   
https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/<https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/>
HTML: 
https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.html<https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.html>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-many-dnsop-dns-isolated-networks<https://datatracker.ietf.org/doc/html/draft-many-dnsop-dns-isolated-networks>


Abstract:

  This document lists operational methods to enable local DNS name
  resolving on an isolated network, where that network have
  intermittent reachability to Internet and/or have very long delays,
  disabling the real-time query and response flow to the authoritative
  name servers on Internet.



The IETF Secretariat



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

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

[Ben Schwartz]

Regarding the suitability of SVCB, note that SVCB requires a registered URI 
scheme.  If you are willing to adopt a mental model that includes URIs like 
"dns-notify://ns1.example.com/..." then it might be usable; otherwise not.

Also, SVCB is designed primarily for bootstrapping authenticated transports.  
If the transport is not authenticated, the mapping would have to explain the 
threat model and security implications.  A relevant example is the SVCB mapping 
for DNS, which contains special recommendations to avoid downgrade attacks 
(https://www.ietf.org/archive/id/draft-ietf-add-svcb-dns-09.html#name-adversary-on-the-transport-).

--Ben Schwartz

From: DNSOP  on behalf of Peter Thomassen 

Sent: Sunday, September 24, 2023 6:24 AM
To: pmev...@godaddy.com ; dnsop@ietf.org 

Subject: Re: [DNSOP] Call for Adoption: 
draft-thomassen-dnsop-generalized-dns-notify

!---|
  This Message Is From an External Sender

|---!

Hi Patrick,

On 9/20/23 23:12, pmev...@godaddy.com wrote:
> I will probably not be able to contribute a lot, but reading it make me think 
> of the following points:

Thank you very much for your feedback; even if you don't feel able to 
contribute a lot, that's VERY helpful :)

> - I didn't see discussion about the possible return codes for the NOTIFY 
> message, and in which case which DNS error code would happen and what would 
> it mean (or is §3.12 of RFC1996 enough?)

Good point. I'm not sure if doing anything beyond that would add any reliable 
benefit, as the return code cannot be signed.

For example, if one would specify REFUSED for when a parent-side rate limit is 
exceeded, an suitable attacker could trick the child into thinking that a DS 
rollover cannot currently be triggered, which may mislead the child about what 
to do next.

Perhaps it's better to not send such signals, and rather have the child 
determine its next steps by assessing the actual situation (i.e., observing 
which DS records are deployed etc.).

It would be interesting to learn what you think about this.

This is tracked at 
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/11.

> - maybe I missed it but didn't find clear indications that the NOTIFY message 
> should (or should not) be with ANCOUNT>0 and the answer section having the 
> relevant records to sync, or in contrary forbidding this to force retrieval 
> by usual DNS queries enforced by DNSSEC protections

Section 4 says:

[...]  Upon receipt of NOTIFY(CDS), the parent SHOULD initiate the
same scan that would otherwise be triggered based on a timer.

In other words, records provided in the NOTIFY message are not to be used.

Some more thoughts on this topic are here: 
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/13

> - SRV instead of new record type is discussed in §9.1 but then rejected: was 
> SVCB discussed? I think it could be used without having to override anything, 
> as you can write a proper profile for it (as HTTPS does), and have more 
> SvcParamKeys

I'm deferring to Johan.

> - it is a different use case, but the same mechanism could be useful in 
> another case, so even if not discussed in the draft, maybe having it in mind 
> could allow to easily work on it later: instead of manual/web based way to 
> ask recursive resolvers to flush a given (name, rdtype) entry (because of 
> some emergency switch wanted), use some kind of NOTIFY to send that signal 
> (with of course the problem of authenticating the source, but it is similar 
> for CDS/CDNSKEY and in part discussed in §11)

Neat idea! I think this needs some input from resolver people.

> - while not creating an amplification problem, I think some explanations 
> should be given around the case of some attacker trying to disrupt by sending 
> lots of notify, which can be rate-limited or ignored, but my worries is if 
> the notify receiver then just decides to "ignore" all notifies for a given 
> zone (not taking into account emitter IPs, or just seeing too many of them), 
> which would then prevent the real owner to send notify, or more precisely to 
> make them worth. Of course nothing breaks but convergence may then go back to 
> slower agenda, which means the attacker succeeded somehow to disrupt the real 
> owner operations.

Yes. Some extra thoughts are here: 
https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/17#issuecomment-1513789295

Peter

--
https://desec.io/

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

Re: [DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

[Ben Schwartz]

I have reviewed this draft.  It seems potentially useful and like a reasonable 
attempt to define a solution.

I would like to see a unified rule connecting the text and JSON 
representations, rather than explicitly defining new formats for each key (and 
in some cases even changing the key names, e.g. NSID vs. NSIDHEX).  For 
example, some options could be defined as having "list" type output, and then 
we could define generically how list values are represented in JSON and text.  
Similarly for numbers, strings, etc.  Alternatively, the JSON format could be 
defined first, and the text format could be defined via an algorithm that acts 
generically on the JSON values.

I think it's worth taking a close look at the existing commonly used 
presentation formats before defining a new one.  For example, it might be 
worthwhile to standardize a text representation that is closer to the current 
"dig" output, for the sake of compatibility with existing systems.

--Ben Schwartz

From: DNSOP  on behalf of libor.peltan 

Sent: Wednesday, May 31, 2023 4:33 AM
To: dnsop 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Hi dsnop, we'd like to turn your attention again to our draft https: //www. 
ietf. org/archive/id/draft-peltan-edns-presentation-format-01. html We believe 
this document shall fill a missing gap in specifications, and help 
interoperability of DNS
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html>

We believe this document shall fill a missing gap in specifications, and help 
interoperability of DNS tools. Therefore, we think it'd make sense if this 
document once becomes a dnsop-homed RFC.

We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Future EDNS(0) Options (thanks to Pieter 
Lexis); nitpicks.

Thank you!

Libor and Tom


 Přeposlaná zpráva 
Předmět:New Version Notification for 
draft-peltan-edns-presentation-format-01.txt
Datum:  Wed, 31 May 2023 01:30:33 -0700
Od: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Komu:   Libor Peltan <mailto:libor.pel...@nic.cz>, Tom 
Carpay <mailto:tomcar...@gmail.com>



A new version of I-D, draft-peltan-edns-presentation-format-01.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 01
Title: EDNS Presentation and JSON Format
Document date: 2023-05-31
Group: Individual Submission
Pages: 20
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt>
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/<https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/>
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format<https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format>
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01<https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01>

Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat


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

[DNSOP] Clarifying motivation for Compact DoE

[Ben Schwartz]

Hi DNSOP,

draft-ietf-dnsop-compact-denial-of-existence currently says the following about 
RFC 4470:

   The response for a non-existent name requires up to 2 signed NSEC
   records or up to 3 signed NSEC3 records (and for online signers, the
   associated cryptographic computation), to prove that (1) the name did
   not explicitly exist in the zone, and (2) that it could not have been
   synthesized by a wildcard.

However, it seems to me that the wildcard response is extremely cacheable, so 
in practice online signing with RFC 4470 only requires one signature (even 
during a cache-busting attack), i.e. the same computational cost as 
draft-ietf-dnsop-compact-denial-of-existence.  This leaves response packet size 
as the primary advantage over RFC 4470.  Is this a fair assessment?

If this is correct, then I'm not sure the complexity of solving the ENT problem 
is worthwhile.  Consider the camel [1], and think carefully before defining new 
mechanisms to solve minor problems.  We have many other options, like changing 
the status to Informational and simply documenting existing practice, or 
declaring that zones using this strange mechanism must never return NXDOMAIN at 
all.

--Ben Schwartz

[1] https://blog.apnic.net/2018/03/29/the-dns-camel/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Questions on DNS HTTPS/SVCB spec and deployment

[Ben Schwartz]

Hi Hongying,

  1.  I don't think that synchronization between the A/ and 
ipv4hint/ipv6hint is very important.  As long as all the listed addresses are 
valid and reasonably appropriate, everything will work fine; there's no need 
for them to be the same.  However, the draft does imagine that there is a risk 
of the IP hints being less carefully selected or out of date.
  2.  Using the hints is beneficial when (1) TargetName was not predicted (i.e. 
"." for HTTPS normally) and (2) its A/ records are not already known to the 
client (and (3) the resolver does not provide the followup query optimization). 
 In the absence of hints, the client would have to perform its own followup 
query and wait for an answer before initiating the connection attempt, 
resulting in delayed connection establishment.
  3.  Correct, "locally available" normally means "already in the local DNS 
cache".
  4.  Correct, the intention is that authoritative servers should stop 
including IP hints once most recursive resolvers become Section 4-compliant.
  5.  I have heard that Akamai CacheServe implements the optimization today.  I 
don't know if there are other implementations.
  6.  I don't know much about the state of client implementations.

--Ben Schwartz

From: DNSOP  on behalf of Hongying Dong 

Sent: Monday, July 24, 2023 1:13 PM
To: dnsop@ietf.org 
Subject: [DNSOP] Questions on DNS HTTPS/SVCB spec and deployment

Hello,We are researchers at the University of Virginia studying some aspects of 
the DNS HTTPS/SVCB specification and how it is deployed in practice. We had a 
few questions we are hoping you can provide the answers to. Primarily we are 
examining

Hello,We are researchers at the University of Virginia studying some aspects of 
the DNS HTTPS/SVCB specification and how it is deployed in practice. We had a 
few questions we are hoping you can provide the answers to. Primarily we are 
examining HTTPS right now, but if the answers can be generally provided for 
SVCB too, that would be great.* IPv4 and IPv6 hints.
The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to 
reach the service.  If A and  records for TargetName are locally available, 
the client SHOULD ignore these hints. Otherwise, clients SHOULD perform A 
and/or  queries for TargetName as in Section 3, and clients SHOULD use the 
IP address in those responses for future connections.  Clients MAY opt to 
terminate any connections using the addresses in hints and instead switch to 
the addresses in response to the TargetName query.  Failure to use A and/or 
 response addresses could negatively impact load balancing or other 
geo-aware features and thereby degrade client performance.
It seems to us that unless the IPv4 and IPv6 hints are kept diligently in sync 
with the actual addresses in the A and  records, this could easily pose 
operational problems in the field. The draft appears to concur and says clients 
should see if they are "locally available", and otherwise "SHOULD" perform 
A/ address lookups. If so, under what circumstances is it beneficial for an 
implementation to follow the "MAY" instruction of the first line in the above 
quoted paragraph and use the hints?Also what does "If the A and  records 
for Targetname are _locally available_" mean? Is the expectation that HTTPS 
client applications run a local DNS cache from which this information could be 
extracted?The  answer to the "MAY use hints" is suggested later on in this 
paragraph:
These parameters are intended to minimize additional connection latency when a 
recursive resolver is not compliant with the requirements in Section 4, and 
SHOULD NOT be included if most clients are using compliant recursive resolvers.
First, how would a client application generally know that a recursive server is 
compliant with Section 4 (i.e. proactively fetching the A and  records for 
the HTTPS Targetname and providing them in the response)? Is there a proposed 
DNS API function that provides this information, or are clients expected to 
write custom code to parse the full response from a recursive server to figure 
this out? Second, how would a service operator publishing HTTPS records know if 
most of their clients are using compliant recursive servers to help them make a 
decision about including IP hints? Or does this statement imply that everyone 
should deploy IP hints until the ecosystem has gained a critical mass of 
recursive servers that are compliant?What recursive servers today support this 
optimization? We've examined several of the public DNS resolvers (Google, 
Cloudflare, Quad9, and OpenDNS) and none of them appear to. We haven't looked 
at the open source implementations yet, but if anyone can answer that would be 
appreciated too.Client implementation behavior in the field: What do existing 
web 

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-svcb-dane-01

[Ben Schwartz]

Thanks for this close review, Patrick.  I've copied your notes into the draft's 
issue tracker so we don't forget to address them: 
https://github.com/bemasc/svcb-dane/issues/8.

--Ben Schwartz

From: DNSOP  on behalf of Patrick Mevzek via 
Datatracker 
Sent: Wednesday, July 12, 2023 7:18 PM
To: dns...@ietf.org 
Cc: dnsop@ietf.org ; draft-ietf-dnsop-svcb-dane@ietf.org 

Subject: [DNSOP] Dnsdir early review of draft-ietf-dnsop-svcb-dane-01

!---|
  This Message Is From an External Sender

|---!

Reviewer: Patrick Mevzek
Review result: Ready with Nits

I have been selected as the DNS Directorate reviewer for this draft
draft-ietf-dnsop-svcb-dane-01
The DNS Directorate seeks to review all DNS or DNS-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the ADs.
For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

This is an early review, and the document seems mostly ready to ship,
with some nits in formatting or presentation, and nothing specifically
related to DNS.

There are no changes or consequences on DNS operations based on this draft,
outside what is already defined in the specifications for TLSA and SVCB/HTTPS
records.

My points below are just in chronological order of reading it.

*

It updates 6698, but it also focuses mostly on operational issues/guidance,
which is what 7671 is about, so maybe it should also be marked as updating 7671
in addition of 6698?

*

Section 1.

— Nit: `_8080._tcp.example.com.` does not appear in specific “code” font in
HTML output of draft, while other names later in document do, so I guess just a
formatting change.

— Potentially use “TLSA records” (plural) in various places instead of “the
TLSA record” as this gives the impression there can be only one.

— Introduction says the document does two things: giving details using DANE
with SVCB and also how to use DANE with QUIC. However, neither the document
title nor the abstract of it mention QUIC, only SVCB is mentioned. If the
document does both, perhaps both points should be clearly listed early on
(title + abstract), or otherwise (as SVCB and QUIC are fairly distinct things
in my view), it should be split in two documents, each one focusing on one
point only.

*

Section 3

— name of section: I would suggest using SVCB specifically instead of Service
Bindings Same for title and abstract of document in fact.

— s/This draft applies/This document applies/ (or specification, or other
terms, but not “draft”) Maybe other occurrences of “draft” later on should be
replaced as well.

— “if SVCB resolution was entirely secure” : maybe mentioning it once that
secure here means with DNSSEC along all the paths (DNS answers) taken? Or
pointing to somewhere where secure is defined (maybe: §4.1 of RFC6698?)

— “In usage modes other than DANE-EE(3)”: shouldn't that also include DANE-TA
case at same level than DANE-EE?

— section 3
“Section 6 of [RFC7671] says:” (present)
vs section 4
“Section 3 of [RFC6698] defined the protocol prefix used for constructing TLSA
QNAMEs, and said:” (past)

I suggest using either present or past tense in both cases, as the intent is
the same (redefining something coming from elsewhere)

*

Section 4

— name of section: I would make sure to list QUIC explicitly, otherwise seems
too generic

— “this draft Updates the above sentence as follows:”

Replace “draft” by document or equivalent and lowercase “Updates”.

— “udp” (DTLS [I-D.draft-ietf-tls-dtls13])
Shouldn't that instead reference by RFC9147 “The Datagram Transport Layer
Security (DTLS) Protocol Version 1.3”?

*

Section 5.1

— Please replace examples of `alias.net`, `provider.com` with things under
`.example` TLD.

— “TLSA  ” Why plural? Possibly just ellipse the whole <> part,
as it could be a hash too, etc.

— “Service consumers are expected to use CNAME or SVCB AliasMode”, yet the
example given is using only HTTPS record and not SVCB record. Maybe use
multiple examples?

— Perhaps add that this works mostly for DANE-EE and DANE-TA use cases?

*

Section 6

— “might use DANE for some conection” => connection

— While not having actual element to provide, I feel the section to be a little
too simple and specially the last paragraph, saying basically “insecurely
resolved is not safe”, without giving guidance or at least detailing the
tradeoffs between various possible scenarios (ignoring unsecure results,
continue, etc.)

*

Section 7

— make sure all examples use IETF reserved names for hostnames (ex:
`example-cdn.com` => `cdn-foobar42.example`)

— “7.3. QUIC and CNAME”, not sure what the record on `http://www.example.com ` 
is
useful for? Or the URI should be `https://www.example.com/`?

— “7.7. DNS ServiceMode”: perhaps

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Ben Schwartz]

Thanks!  I think making it clear that auth servers are allowed to send TC to 
force TCP upgrade is a nice compromise.

From: DNSOP  on behalf of Roy Arends 
Sent: Monday, July 10, 2023 4:04 PM
To: Ben Schwartz 
Cc: Benno Overeinder ; DNSOP Working Group 
; DNSOP Chairs 
Subject: Re: [DNSOP] Working Group Last call for 
draft-ietf-dnsop-dns-error-reporting

!---|
  This Message Is From an External Sender

|---!

Ben,

Thanks for this! Comments inline.

> On 23 Jun 2023, at 02:27, Ben Schwartz  
> wrote:
>
> I want this draft to move forward, but upon review I noted with concern the 
> security section text:
>
>DNS error reporting is done without any authentication between the
>reporting resolver and the authoritative server of the agent domain.
>Authentication significantly increases the burden on the reporting
>resolver without any benefit to the monitoring agent, authoritative
>server or reporting resolver.
>
> Strong authentication (e.g. to a zone identity with DNSSEC) is probably 
> excessive, but the current draft appears to have no defense against even 
> trivial IP spoofing.  Anyone in the world who can spoof IP addresses can 
> impersonate a reputable resolver and pollute the error reports sent to 
> authoritative servers.  As an authoritative server operator, I would place a 
> lot more trust in reports from reputable resolvers than from unrecognized 
> sources.

Ack

> I think the draft should probably say something like: "To defend against 
> spoofing of source IP addresses used for error reports, reporting resolvers 
> MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC 7873], or another procedure 
> that defeats IP address spoofing."

I’ve added language to this extend. However, I’ll won’t go as far as MUST. I’ve 
made this is a SHOULD (for both TCP and cookie), while the authoritative server 
SHOULD respond with TC bit set to force a re-query over TCP.

Hope this suffices.

Warmly,

Roy


> --Ben SchwartzFrom: DNSOP  on behalf of Benno 
> Overeinder 
> Sent: Thursday, June 8, 2023 5:59 AM
> To: DNSOP Working Group 
> Cc: DNSOP Chairs 
> Subject: [DNSOP] Working Group Last call for 
> draft-ietf-dnsop-dns-error-reporting
>  !---|
>   This Message Is From an External Sender
>
> |---!
>
> Dear DNSOP WG,
>
> The authors and the chairs feel this document has reached the stage
> where it's ready for Working Group Last Call.
>
> This starts a Working Group Last Call for:
> draft-ietf-dnsop-dns-error-reporting.
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/  .
>
> The Current Intended Status of this document is: Standards Track.
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please
> speak out with your reasons.
> Supporting statements that the document is ready are also welcome.
>
> This starts a two week Working Group Last Call process, and ends on:
> June 22nd, 2023.
>
> Thanks,
>
> -- Benno
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


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

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

[Ben Schwartz]

I think firmware size is a perfectly reasonable and sufficient motivation for 
this draft, but I don't think it can be described as "performance".

--Ben Schwartz



From: Christian Amsüss
Sent: Wednesday, July 5, 2023 12:17 PM
To: Ben Schwartz
Cc: Martine Sophie Lenders; c...@ietf.org; 
draft-ietf-core-dns-over-c...@ietf.org; dnsop; DNS Privacy Working Group
Subject: Re: [DNSOP] Next steps: draft-ietf-core-dns-over-coap

Hello Ben,

picking one of the points in the thread and leaving the rest to another
subthread:

> > 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].
>
> This paper appears to be focused on DNS performance, but DNS is
> usually only a small component of overall system performance.

In this context, I think a relevant performance metric is firmware size
(or, equivalently, network load from firmware updates) -- a metric that
is covered in the latest preprint[1] of the same work. While a CoAP plus
OSCORE stack is marginally larger in firmware that a DNS plus DTLS stack
(and admittedly that's not even accounting for EDHOC that'd also be
needed if the DNS server is authenticated with public key cryptography),
that is text the application already pulls in, whereas the DTLS
component of DNS over DTLS alone already weighs another 20KiB of
firmware size. That represents a significant portion of the flash memory
available on the relevant microcontrollers.

Software complexity (both in terms of LoC and in terms of items on an
SBOM) is a factor that improves in parallel to the binary size savings.

BR
Christian

[1]: https://arxiv.org/abs/2207.07486v2

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOPReminder: Please review draft-ietf-dnsop-svcb-dane

[Ben Schwartz]

From: DNSOP  on behalf of Viktor Dukhovni 


Quoting from the draft:
...
>   If the initial TLSA base domain is the start of a secure CNAME chain,
>   clients MUST first try to use the end of the chain as the TLSA base
>   domain, with fallback to the initial base domain, as described in
>   Section 7 of [RFC7671].
...
If we don't expect prolific use of SVCB or HTTPS targets that are in
turn CNAMEs, perhaps it is time to reconsider the advice in 7671 which
was written when operational experience was still evolving.
As an interim step, what do you think about this addition: 
https://github.com/bemasc/svcb-dane/pull/6/files ?

My hope is that this gives us room to make a change like you're imagining in 
the future, while also ensuring that a client for this draft can be implemented 
entirely as a wrapper around an existing, non-SVCB-aware DANE implementation.

>   If a TLSA RRSet is securely resolved, the client MUST set the SNI to
>   the TLSA base domain of the RRSet.  In usage modes other than DANE-
>   EE(3), the client MUST validate that the certificate covers this base
>   domain, and MUST NOT require it to cover any other domain.

Note that after 7671 was published it was pointed out by Richard Barnes
in https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00  that
not verifying the server name with DANE-EE(3) is problematic in the
web browser use-case, because it can lead to cross-origin issues that
are absent in protocols such as SMTP.
FWIW, I believe that draft overlooks the defense against misdirected requests 
in HTTP: 
https://datatracker.ietf.org/doc/html/rfc9110#name-rejecting-misdirected-reque. 
 I believe that UKS attacks are not possible from HTTP/1.1 onwards.

Therefore, barring specific knowledge that the application protocol in
question faces no similar issues, the certificate name should by default
always be checked.  This is reflected in the OpenSSL DANE
implementation, which requires a non-default flag to turn off name
checks when validating a peer via a matching DANE-EE(3) TLSA record.
I don't think it helps to check the certificate against the TLSA base domain, 
if (as here and in SRV) the TLSA base domain is independent of the original 
QNAME.  Perhaps you mean to check it against the original QNAME, but this seems 
extremely limiting, as it would prevent a CDN from publishing a single TLSA 
record for use by numerous customers.

How about this text on the topic: https://github.com/bemasc/svcb-dane/pull/7 ?

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

Re: [DNSOP] DNSOPReminder: Please review draft-ietf-dnsop-svcb-dane

[Ben Schwartz]

From: Wes Hardaker 

Ben Schwartz  writes:

A few comments:

1. the MUST NOT in the first paragraph in 5.2 really feels like it should
be a SHOULD NOT.  Though its not wise, there could be scenarios where
someone really wants to do it and if they feel it's operationally
possible then they should be allowed to.
In general, my view is that compliance with the mandatory requirements should 
be sufficient for interoperability.  If this requirement is not mandatory, that 
creates an interoperability problem with the next paragraph's rule that 
"service operators MAY reject TLS connections whose SNI does not correspond to 
an approved TLSA base domain".
[I had a really hard time
writing this, as I think you're right about the importance, but we do
try to opt for SHOULD NOTs unless it always breaks something]
Personally, I tend to think that things that reliably break in some visible way 
don't really need normative language, because implementors will figure out that 
it's broken.  "MUST NOT" is most important when the problem is subtle, 
systemic, or delayed, as in this case.

Also, note that there is an escape hatch here ("unless they have an explicit 
arrangement ..."), so this is really not a technical requirement, and what 
constitutes such an arrangement is open to interpretation.
2. in the security considerations, the first sentence in the second
paragraph seems like it should have a solid requirement in it.  Maybe
"The SVCB and associated TLSA records MUST be validated by DNSSEC."  And
this is one of those cases where the MUST feels right as it
significantly degrades the security of the protocol if only a SHOULD is
used.  As such, I'd drop the rest of the paragraph.
We avoided this requirement for two reasons, both somewhat related to ADoT:

  1.  Unsigned TLSA records do exist (e.g. 
dns:_853._tcp.a.ns.facebook.com?type=TLSA) and provide some security benefit in 
situations where (a) full authentication is not well-defined or widely deployed 
and (b) the attacker is on the application path but not on the DNS path.
  2.  There have been some Authenticated ADoT proposals that rely at least in 
part on transport security rather than DNSSEC.  We used the phrase "resolved 
securely" to avoid prejudging that discussion.

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

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

[Ben Schwartz]

On 6/28/23, 10:24 AM, "Martine Sophie Lenders"  wrote:
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].

This paper appears to be focused on DNS performance, but DNS is usually only a 
small component of overall system performance.

BTW, this reminds me that referring to OSCORE as “end-to-end” in this context 
is confusing, since the logical “endpoints” are the stub resolver and the 
authoritative nameserver.

> ...
>
> 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.

That’s fine with me.

> 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]).

I think this explanation should be included in the draft.

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?

The DNS protocol is role-independent, so a DoC server could (in principle) be a 
recursive resolver, a forwarder, or an authoritative nameserver.  If it is a 
forwarder, it could use DoH, DoC, or any other transport of its choice to reach 
its upstream resolver.

Best
Martine

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

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

Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

[Ben Schwartz]

On 6/29/23, 1:11 PM, "John R Levine"  wrote:

If you're running 8.8.8.8 your logs have a whole lot of PII, but if you're
running resolvers in front of industrial networks and using PDNS to look
for malfunctioning or compromised IoT boxes, there's no PII at all.

Yes, but since the format doesn’t carry client IPs, it’s not very friendly for 
this IoT use case.  We could fix that!

> As it stands, I think this format is something of a privacy footgun.  It 
> looks reasonably deidentified, but in the DPRIVE threat model (see e.g. RFC 
> 7626) it is highly reidentifiable.

I completely agree that we need to document the security and privacy
issues and suggest ways both to understand what they are, and how to
mitigate them.  But if we imagine that we are smarter than the people who
use our specs, well, we aren't.

If the IETF says “deidentified DNS logs are basically anonymous” vs. 
“deidentified DNS logs are basically PII”, I believe that makes a big 
difference in the world.  Expert practitioners might already understand the 
nuance here, but our audience is broader than that.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

[Ben Schwartz]

On 6/28/23, 12:49 PM, "John Levine"  wrote:

!---|
  This Message Is From an External Sender

|---!

It appears that Ben Schwartz   said:
>-=-=-=-=-=-
>As noted in RFC 8499, "Passive DNS" raises some significant privacy concerns.  
>This is true even when client IP addresses are omitted.
>For example, the proposed format includes timestamps.  An adversary who can 
>record encrypted DNS traffic and can acquire corresponding
>Passive DNS logs could "join" the two datasets to break the protection offered 
>by encrypted DNS.
>
>I hope the working group will weigh the privacy considerations carefully when 
>deciding how to proceed.

I take your point, but I hope we agree that omitting timestamps from the spec
won't make them go away.  It's fine to describe the security issues, but let's
not make the NAT mistake and imagine that not documenting it will make people
stop using it.

When the IETF documents something, that is unavoidably an endorsement.  We 
should be cautious about what we endorse.

An interesting comparison here is the draft on SSLKEYLOGFILE: 
https://datatracker.ietf.org/doc/html/draft-thomson-tls-keylogfile-00.  The 
Security Considerations are extensive and pointed.  It helps that the risks are 
obvious.

In this case, the risks may be less obvious, and we should work to make them 
more obvious.  For example, we could decide to add a mandatory client IP field. 
 This would help to emphasize that the data is in fact highly sensitive, and 
must be treated with the same level of caution as other PII logs.  (It would 
also make the logs more useful in contexts where they are safe to use.)

As it stands, I think this format is something of a privacy footgun.  It looks 
reasonably deidentified, but in the DPRIVE threat model (see e.g. RFC 7626) it 
is highly reidentifiable.

As a matter of process, I would like to see input from DPRIVE if this proceeds.

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

Re: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

[Ben Schwartz]

As noted in RFC 8499, "Passive DNS" raises some significant privacy concerns.  
This is true even when client IP addresses are omitted.  For example, the 
proposed format includes timestamps.  An adversary who can record encrypted DNS 
traffic and can acquire corresponding Passive DNS logs could "join" the two 
datasets to break the protection offered by encrypted DNS.

I hope the working group will weigh the privacy considerations carefully when 
deciding how to proceed.

--Ben Schwartz

From: DNSOP  on behalf of Tim Wicinski 

Sent: Friday, June 23, 2023 4:18 PM
To: dnsop 
Cc: dnsop-chairs 
Subject: [DNSOP] draft-dulaunoy-dnsop-passive-dns-cof

All Draft-dulaunoy-dnsop-passive-dns-cof was originally submitted back in 2014, 
and has had 10 revisions since then. https: //datatracker. ietf. 
org/doc/draft-dulaunoy-dnsop-passive-dns-cof/ Note that the format is now 
fixed, and there are several
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

All

Draft-dulaunoy-dnsop-passive-dns-cof was originally submitted back in 2014, and 
has had 10 revisions since then.

https://datatracker.ietf.org/doc/draft-dulaunoy-dnsop-passive-dns-cof/<https://datatracker.ietf.org/doc/draft-dulaunoy-dnsop-passive-dns-cof/>

Note that the format is now fixed, and there are several implementations.

We had asked DNSOP (in the poll we held)to help us assess the level of interest 
in it, and the responses  largely put it moderately high  ("Adopt, but not 
now"). It would be helpful to find out if this is still the case, as things 
have progressed since then: the format is now widely used, and so the format 
itself is basically fixed. As an example, the format is being used within the 
US government agencies for event logging and incident response[0].


One of two things could happen:

1: DNSOP decides that they are really interested, adopts and improves the 
justification / operational / supporting text, and the draft gets published as 
an IETF RFC; or


2: DNSOP says "No thanks, but we don't actively object". In which case the ISE 
(and Warren!) has a much easier time explaining why it's being published as an 
RFC on the Independent stream. . We will also ask for a DNS Directorate review.


Feedback Welcome

tim

[0]: Because the draft had expired, and the USG cannot (realistically) point at 
expired IDs, they had to copy and paste it into an internal document: 
https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf<https://www.whitehouse.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf>
  Page 15 is the table where they defined the Passive DNS Log fields.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ben Schwartz]

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.
...
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.
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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Ben Schwartz]

I want this draft to move forward, but upon review I noted with concern the 
security section text:


   DNS error reporting is done without any authentication between the
   reporting resolver and the authoritative server of the agent domain.
   Authentication significantly increases the burden on the reporting
   resolver without any benefit to the monitoring agent, authoritative
   server or reporting resolver.

Strong authentication (e.g. to a zone identity with DNSSEC) is probably 
excessive, but the current draft appears to have no defense against even 
trivial IP spoofing.  Anyone in the world who can spoof IP addresses can 
impersonate a reputable resolver and pollute the error reports sent to 
authoritative servers.  As an authoritative server operator, I would place a 
lot more trust in reports from reputable resolvers than from unrecognized 
sources.

I think the draft should probably say something like: "To defend against 
spoofing of source IP addresses used for error reports, reporting resolvers 
MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC 7873], or another procedure 
that defeats IP address spoofing."

--Ben Schwartz

From: DNSOP  on behalf of Benno Overeinder 

Sent: Thursday, June 8, 2023 5:59 AM
To: DNSOP Working Group 
Cc: DNSOP Chairs 
Subject: [DNSOP] Working Group Last call for 
draft-ietf-dnsop-dns-error-reporting

!---|
  This Message Is From an External Sender

|---!

Dear DNSOP WG,

The authors and the chairs feel this document has reached the stage
where it's ready for Working Group Last Call.

This starts a Working Group Last Call for:
draft-ietf-dnsop-dns-error-reporting.

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ .

The Current Intended Status of this document is: Standards Track.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please
speak out with your reasons.
Supporting statements that the document is ready are also welcome.

This starts a two week Working Group Last Call process, and ends on:
June 22nd, 2023.

Thanks,

-- Benno

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

[DNSOP] Reminder: Please review draft-ietf-dnsop-svcb-dane

[Ben Schwartz]

I wanted to remind DNSOP to take another look at draft-ietf-dnsop-svcb-dane 
[1], which is intended as a straightforward clarification of how DANE interacts 
with SVCB/HTTPS records (and QUIC/HTTP/3).  I don't think this document is 
controversial, and I'd like to proceed to WGLC soon.

Thanks,
Ben

[1] https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-dane/

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

Re: [DNSOP] Private-use underscored DNS node name

[Ben Schwartz]

Hi Jeremy,

This is an interesting idea, but I think it's difficult to understand in
the abstract.  Could you provide some example zone files for the use case
you're considering?

It sounds like you're concerned about the possibility that non-underscored
names could be misconstrued as host names, even though they don't hold any
address records.  However, I don't believe there is any general expectation
that DNS names must be the names of hosts just because they are
syntactically valid hostnames.

Thanks,
Ben

On Thu, Dec 8, 2022 at 6:39 PM Jeremy Saklad  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> BCP 222 sets out guidelines for using underscored DNS node names, which
> are important for any record that should not be mistakenly interpreted as
> an actual host. However, it doesn’t seem to set aside a name for private
> use, which would be particularly helpful for deduplicating RRsets.
>
> As an example, draft-ietf-dnsop-svcb-https-11 suggests using AliasMode
> HTTPS records to maintain a separation of concerns. I’ve found this helpful
> myself, as it allows me to have the configuration for a web server and
> single onion service in one RRset, with each of the served hostnames
> aliasing to that.
>
> However, that suggestion recommends using non-underscored TargetNames,
> which have the side-effect of incorrectly stating that the TargetName is
> itself an origin. It would make much more sense to alias to an underscored
> node name for this.
>
> Upon looking into my options, however, I can’t find any
> standards-compliant way of actually doing that. The closest option is
> “_example”, which doesn’t seem meant for actual use. Am I missing
> something, or is it outright impossible to name arbitrary DNS records
> without the possibility that future specifications ascribe unwanted meaning
> to it?
>
> If I am in fact not missing anything, I propose registering “_private” as
> a reserved node name for all RRTypes.
> -BEGIN PGP SIGNATURE-
>
> iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY5J1DVYYJ2h0dHBzOi8v
> b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw
> NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIG1hwAP9fQoJv
> UrWZA8GnQWK+sStyneA4t5IsTOmOSdto4wcziQD/ajah2eIyUr8rOkRoM2DveTQF
> bl6EvRxLsQR2TjCmBQc=
> =xghv
> -END PGP SIGNATURE-
> ___
> 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

Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition

[Ben Schwartz]

I agree; this is about utility, not necessity.  For example,  records
are almost never "necessary" in glue, but they are useful, so they are glue.

On Fri, Nov 4, 2022 at 7:24 AM libor.peltan  wrote:

> Hi,
>
> regarding the question of "necessary" versus "useful". I apologize, but
> I must kind-of undermine the question.
>
> Imagine that a delegation is supplemented with an SVCB record that
> describes how to connect securely (with TLS) to the delegated
> nameserver. (Dunno if this really can happen today, but it's an
> imaginable situation in general.)
>
> Then the SVCB is not necessary for the DNS resolution per se, but it is
> necessary for the resolution to proceed securely. If the client's policy
> is "privacy or nothing", then they will not proceed with the resolution
> unless the SVCB is returned. As a consequence, the record is not
> necessary to some clients (but may still be useful), but necessary to
> others. Thus, the term necessary is relative and it can hardly be used
> in the definition of glue.
>
> Thank you for considering my comment :)
>
> Libor
>
> Dne 03. 11. 22 v 22:48 Benno Overeinder napsal(a):
> > Dear WG,
> >
> > With the DNSOP rfc8499bis interim in September, we had the action
> > point to send two questions to the DNSOP WG to find consensus on the
> > bailiwick and glue discussion.
> >
> > You can find the interim meeting material here
> > https://datatracker.ietf.org/meeting/interim-2022-dnsop-02/session/dnsop
> > and the recording of session here https://youtu.be/wY7-f40lDgU.
> >
> > This is the second email to the WG, focussing on the definition of glue.
> >
> > Questions:
> >
> > 2. Definition of Glue provided by Duane Wessels on the DNSOP WG mailing
> >list:
> >
> >"Glue is non-authoritative data in a zone that is transmitted in the
> >additional section of a referral response on the basis that the data
> >might be necessary for resolution to proceed at the referred name
> >servers."
> >
> >On the mailing list, we have seen a discussion about "necessary"
> >versus "useful".  In this context glue is defined to be exclusively
> >A/ records (traditional understanding), or do we also consider
> >other RRtypes to be glue, e.g. SCVB/HTTPS or DS records? Concern is
> >that "useful" may lead to a definition that is too broad.
> >
> > Taking the last point a step further: if the definition is expanded
> > and glue-is-not-optional becomes a requirement then responses may grow
> > in size and exceed fragmentation/truncation thresholds and lead to
> > more TCP.
> >
> > Remark by WG during interim meeting: One might need a registry for
> > RRtypes being glue (in the future).
> >
> > Thanks,
> >
> > -- Suzanne, Tim and Benno
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> 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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Mon, Oct 24, 2022 at 6:13 PM Timothy Mcsweeney 
wrote:

>
> > On 10/24/2022 10:17 AM EDT Ben Schwartz  40google@dmarc.ietf.org> wrote:
> >
>
> > >- How might or should this be reflected in the browser bar?
> > >
> > > Personally, I would treat an "x+y://" scheme as unrelated to "x://",
> and
> > make the distinction clear to users
> >
> > >
>
>
> Does the foo+alt:// uri only go to the .alt non-dns namespace?  or does it
> go to both dns and non-dns namespces at the same time?
>

My feeling was that "foo+alt:" does whatever the "foo+alt" URI handler
wants.  "alt" means "escape from the standards process at this point", so
while this scheme might be analogous to "foo:" in some fashion, the nature
of the analogy is not standardized.  (As Eliot pointed out, this may not be
the best way to make use of scheme extensions.)

My main point is: the TLD isn't the only place we can put an escape hatch.
(Brian Dickson identified yet another.)  I think that gives us the freedom
to be more prescriptive about what ".alt" is for.  It doesn't have to be a
universal escape hatch.

My favorite idea for ".alt", as mentioned earlier, is to say something like
"this is the system's alternate DNS root".  Names under .alt SHOULD act
entirely like DNS names, except that they are not directed to the system's
main DNS root (which IANA fans will hope is the IANA root).  This doesn't
cover all the potential use cases, but it covers a lot of them, and
preserves some degree of technical uniformity across the DNS namespace.


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Mon, Oct 24, 2022 at 12:47 PM Timothy Mcsweeney 
wrote:
...

> You can't use the "+" in the scheme component of the uri scheme.  It's a
> reserved sub-delim.
>

RFC 3986, Section 3.1:

   Scheme names consist of a sequence of characters beginning with a
   letter and followed by any combination of letters, digits, plus
   ("+"), period ("."), or hyphen ("-").

Worked example: https://www.rfc-editor.org/rfc/rfc8323.html#section-8

I'm not a URI expert but that seems pretty clear.


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

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

[Ben Schwartz]

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 <
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/
> [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 Addi

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Sun, Oct 23, 2022 at 4:31 AM Eliot Lear  wrote:

> Hi Ben and Wes,
> On 21.10.22 20:45, Ben Schwartz wrote:
>
>
> Rather than placing "alt" in the TLD position, I think it might be better
> as a scheme modifier: https+alt://...  This is a common pattern  for
> modifications to URI schemes (c.f. git+ssh://), and informs the software
> that this URI is special without overloading the DNS namespace.
>
> How would this work in practice?
>
Thinking about this more, I can imagine having both "+alt" and ".alt".  In
this world, ".alt" would be for "the system's alternate DNS root",
providing DNS-equivalent functionality but not in IANA-controlled space.
"+alt" would be for "the system's alternative interpretations of URI
schemes", with no further requirement that the authority be domain-shaped
at all.

>
>- Would this require a re-registering of each and every URI scheme
>with +alt, and monitoring the URI scheme registry for new ones?
>
>  I don't think so.  We could define it as a universal scheme modifier.

>
>-   (I'll note that git+ssh isn't registered.)
>
> Unfortunately, most URI schemes outside of the RFC process are not
registered.  I think there's a general lack of awareness that registration
is required or easy.

>
>- What is the value of +alt at this point?  Why not use +gns or +onion
>or +eliotsfavoritenamespace?
>
> That sounds like a very intriguing idea, and might be better than +alt.

>
>- How might or should this be reflected in the browser bar?
>
> Personally, I would treat an "x+y://" scheme as unrelated to "x://", and
make the distinction clear to users

>


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Fri, Oct 21, 2022 at 3:03 PM Wes Hardaker  wrote:

> Ben Schwartz  writes:
>
> > Rather than placing "alt" in the TLD position, I think it might be
> better as a
> > scheme modifier: https+alt://...  This is a common pattern  for
> modifications to
> > URI schemes (c.f. git+ssh://), and informs the software that this URI is
> special
> > without overloading the DNS namespace.
>
> I suspect many of us would agree that's the best ideal way forward,
> except that the proponents of the alternate names want their names to be
> as DNS-like as possible so it works with *all* applications.  All new
> ones may support extensions and URIs, etc.  I'm not sure telnet, nntp
> readers, etc do/will.  I don't even know how to enumerate all the places
> where a domain name is expected (endless GUIs) that don't have an
> appropriate name space selector option.  Certainly a "too bad for you"
> approach for situations like that, but I suspect that's going against
> what the alternate name space proponents want: minimal upgrades to
> existing software [right or wrong as that may be -- no judgment here].


I think this mindset is based on what I'll call the "getaddrinfo
assumption", that DNS provides a name->IP mapping interface whose
implementation can be replaced.  This assumption can fail on both ends:

1. Many altname schemes (e.g. .onion, IPFS) do not represent IP addresses
at all.
2. Existing DNS-reliant applications increasingly rely on
beyond-getaddrinfo capabilities (e.g. SRV, HTTPS-records, stub DNSSEC,
etc.) or implement their own stub resolvers for performance reasons.

The .alt draft seems to be based on this assumption, although it doesn't
say so.  If this assumption fails, it's hard for me to see how .alt helps.

Conversely, I think an alternate URI-scheme is actually _more_ likely to
have good compatibility with non-alt-aware software.  For example, if a
non-alt-aware web browser encounters an unknown URI scheme, it will
generally defer to the operating system for how to handle it.  This means a
user can (today!) install a system-wide "https+alt://" handler, and expect
to be able to open such URIs if they're encountered in the browser, mail
client, etc.


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Fri, Oct 21, 2022 at 2:31 PM Paul Hoffman  wrote:

> >> .alt will be treated like any other pseudo-TLD regardless of the
> context.
> >
> > Sorry, I don't understand.  I believe "pseudo-TLD" here means "a name
> that resolves to NXDOMAIN".
>
> It is defined in this very document as "A label that appears in a
> fully-qualified domain name in the position of a TLD, but which is not part
> of the global DNS."
>
> >  Most URI schemes are pretty clear about what happens in this case: the
> resource cannot be accessed.
>
> That seems like the right thing for them to specify.
>
> >> If you think that URIs that have names that are not part of the global
> DNS should be treated differently by URI consumers, by all means write a
> draft about it.
> >
> > This is not about "global DNS" vs. some view of the DNS.
>
> It really is. See the definition in the draft.


Firstly, I don't think it makes sense to define "DNS context" as limited to
the IANA root.  I would prefer a term like "non-IANA-root context".

Secondly, the draft contradicts itself.  For example, it says ".alt is
always used to denote names that are to be resolved by non-DNS protocols".
But surely one can speak to non-IANA DNS roots using the DNS protocol?

Rather than placing "alt" in the TLD position, I think it might be better
as a scheme modifier: https+alt://...  This is a common pattern  for
modifications to URI schemes (c.f. git+ssh://), and informs the software
that this URI is special without overloading the DNS namespace.


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

Re: [DNSOP] [Ext] Possible alt-tld last call?

[Ben Schwartz]

On Wed, Oct 19, 2022 at 9:31 PM Paul Hoffman  wrote:
...

> On Oct 17, 2022, at 1:16 PM, Ben Schwartz  40google@dmarc.ietf.org> wrote:
> >
> > While we're talking about this draft, I would like to suggest that the
> draft discuss the interpretation of URIs containing ".alt" hostnames.  I
> have great difficulty understanding what "https://example.foo.alt/; means
> ... but most of the interest in alternative naming systems seems to be
> based on the idea that this sort of URI is meaningful.
>
> .alt will be treated like any other pseudo-TLD regardless of the context.


Sorry, I don't understand.  I believe "pseudo-TLD" here means "a name that
resolves to NXDOMAIN".  Most URI schemes are pretty clear about what
happens in this case: the resource cannot be accessed.


> If you think that URIs that have names that are not part of the global DNS
> should be treated differently by URI consumers, by all means write a draft
> about it.


This is not about "global DNS" vs. some view of the DNS.  This is about
"resolvable names" vs. "non-resolvable names".  Every URI scheme I'm aware
of relies on "name resolution" of any hostname specified in the authority
section.  But "name resolution" is not defined except within "the DNS".  If
.alt names are "not DNS names", then they are not subject to "name
resolution".  I conclude that they cannot be used in any existing URI
scheme.

If you agree, that should go in the draft.  If not ... personally I think
you'll need to add some text, and possibly update some RFCs.

As a practical matter, I see three types of "pseudo-TLDs":
1. Alt-root names: Those that actually _are_ DNS names, offering the same
set of RR types but resolving to an alternate DNS root.  (Example:
Handshake "HNS")
2. New class names: These come with their own new universe of URI schemes,
and cannot be used with existing schemes that assume name resolution.
(Example: dweb://)
3. Retrofit names: These names reuse some existing scheme strings but
substantially modify the interpretation of the scheme.  (Example: https:
and .onion).

I would like the draft to be a lot clearer about which of these are
in-scope for .alt.


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

Re: [DNSOP] Possible alt-tld last call?

[Ben Schwartz]

While we're talking about this draft, I would like to suggest that the
draft discuss the interpretation of URIs containing ".alt" hostnames.  I
have great difficulty understanding what "https://example.foo.alt/; means
... but most of the interest in alternative naming systems seems to be
based on the idea that this sort of URI is meaningful.

Personally, my intuition is that there is a big difference between naming
systems that essentially reuse the DNS RR types, and perhaps can thereby
reuse DNS-bound URI schemes (via a new "virtual DNS interface"), and those
that do not and cannot.  For the latter, new URI schemes would be needed.
This seems to be the essential logic behind the W3C DID effort, which
starts from a new URI scheme.


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

Re: [DNSOP] Proposal for Namespaced Service Names

[Ben Schwartz]

I think the right approach here would be for us (especially relevant chairs
and ADs) to reach out to the squatters and try to get them to join the
process.  We can also try to make this process easier.  (Why isn't there a
"request entry" button next to each IANA registry?)  We should emphasize
the "early allocation" process for work in progress.

For SVCB, the prefixes are generally expected to be URI schemes, so the
first step would be to register your scheme [1].  This registry is
First-Come-First-Serve so the barrier to entry is very low.  Once you have
a scheme, the next step would be to place it in the Attrleaf registry [2].
This requires a stable "reference" (i.e. a SVCB "mapping document") owned
by an organization, but that document does not have to be an IETF
specification.  Indeed, it is possible to do all of this without
interacting with the IETF at all!

I don't think we should try to encode the owner of each service type into
the name of the service type.  If an experimental protocol becomes widely
used, we don't want to be stuck with the owner-encoding name.  This could
also create significant security, performance, and reliability concerns,
e.g. if the original owning entity ceases operation.

--Ben Schwartz

[1] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[2]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

On Mon, Oct 3, 2022 at 9:05 AM Jeremy Saklad  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> My thinking is that people are reluctant to engage with the process for
> experimental or extremely niche applications, for better or for worse. Or
> simply because it is meant for personal or internal use: if a company
> initially wants to use it on their own machines alone, they may not want to
> reserve a public name for it. On the other hand, there’s another reason to
> provide a separate namespace for this: self-documentation.
>
> My idea is that a new .well-known directory could be set aside for this,
> which would provide a place to (optionally) self-publish specifications for
> how to use the namespaced service with standards like SBVC. There’d be a
> few constraints on doing this unilaterally, of course: you wouldn’t be able
> to define new service parameters, unless a method of avoiding overlap with
> the registry were devised. But it would be a considerable improvement on
> the current state of affairs.
>
> Take the following record:
>
> > _newservice.example.com._service._tcp.server.example. 86400 IN
> SRV 0 0 1021 target.example.
>
> This tells a client that  offers the service “_
> newservice.example.com” (“newservice” as defined by the owner of <
> example.com>) at port tcp/1021 of . It also tells a human
> that relevant documentation may be found at <
> https://example.com/.well-known/service/newservice>.
> -BEGIN PGP SIGNATURE-
>
> iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCYzrdo1YYJ2h0dHBzOi8v
> b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw
> NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIGyHfAP9rY/0e
> Kqw1OcVrla+B4wODAM8xKcSngj0uGlZAmRlMOQD+OCRmILO/tRwgYASjX2074lKW
> DD6r+WPMatv7KYwWhwo=
> =NJWR
> -END PGP SIGNATURE-
> ___
> 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

Re: [DNSOP] Question regarding draft-ietf-dnsop-svcb-https-10 sections 4.1 and 6

[Ben Schwartz]

The answer is #2: the same as the QTYPE.

The "compatible" RR types have the same RDATA format and processing logic,
but they do not interact with each other.


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

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

[Ben Schwartz]

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

On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders <
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
>  
> 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 <
> 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.  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 populat

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

[Ben Schwartz]

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 <
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.  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 

Re: [DNSOP] [Ext] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

[Ben Schwartz]

Regarding a presentation format for OPT, note that the EDNS options have
essentially the same wire format as SVCB SvcParams, so it may be possible
to share the SvcParams parsing logic.

On Wed, Sep 14, 2022 at 11:57 AM Paul Hoffman 
wrote:

> On Sep 14, 2022, at 8:54 AM, Petr Špaček  wrote:
> > I agree that full structured JSON is lots of work, and honestly I don't
> see the need for it.
> >
> > From my perspective more useful is to standardize unambiguous
> presentation formats for all EDNS options first. Maybe we will find out
> that it is enough. Or maybe not, but the presentation formats could be a
> corner stone, and are useful by itself.
>
> +1. As I said yesterday, even a "full structured JSON" cannot be useful to
> everyone. Unambiguous presentation formats can be.
>
> --Paul Hoffman
>
> ___
> 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

Re: [DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

[Ben Schwartz]

I believe the proposed change here is moot.  The point of the current "MUST
NOT" is just a reminder that this logic does not require doing anything
unsafe.  A DNSSEC signature on the HTTPS record would not enable any
substantial improvements to the pseudo-HSTS upgrade.

Also, HTTP specifications generally do not rely on DNSSEC.  If there is
appetite for exploring possible enhancements to HTTP that rely on DNSSEC, I
think this would be better addressed in a general "DNSSEC-Enhanced HTTP"
document.  (However, I think it would not be wise to publish such a
document until such time as end-to-end DNSSEC is reasonably prevalent in
the HTTP ecosystem.)

On Wed, Aug 31, 2022 at 6:40 PM Eric Orth  wrote:

> Does any HTTP client not follow 307 redirects if received over cleartext?
> This feels to me like a purely theoretical situation.  I'm not opposed to a
> bis making the trust in the HSTS feature be treated more similarly to
> receiving the 307 over HTTPS when DNS is protected, but I also wouldn't
> consider this important enough on its own to adopt a bis.
>
> On Wed, Aug 31, 2022 at 6:22 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, Aug 31, 2022 at 10:43 AM Eric Orth > 40google@dmarc.ietf.org> wrote:
>>
>>> I'm not sure what exactly is being changed or clarified with this
>>> suggestion.  Section 9.5 already applies at SHOULD-level, whether
>>> cryptographically protected or not and whether the received records were
>>> AliasMode or ServiceMode.
>>>
>>
>> The text in 9.5 has some language that is actually NOT at the SHOULD
>> level:
>>
>>Because HTTPS RRs are received over an often-
>>insecure channel (DNS), clients MUST NOT place any more trust in this
>>signal than if they had received a 307 (Temporary Redirect) response
>>over cleartext HTTP.
>>
>>
>> That's what the suggestion is making an effort to strengthen, under
>> specific conditions (e.g. cryptographically protected HTTPS records
>> received).
>>
>> The current 9.5 text quoted above, is placing MUST NOT guidance,
>> independent of whether the records were cryptographically protected.
>>
>> I'm thinking it would be better to fix the quoted language above, in a
>> -bis document, if the suggested text isn't acceptable as an update to the
>> about-to-be-published draft.
>>
>> The logic used to reach that MUST NOT is suspect, IMHO.
>> The main non-requirements on DNSSEC (i.e. that HTTPS does not require it)
>> are then turned into an "assume all DNS responses are not cryptographically
>> protected" inferentially.
>>
>> It would be better guidance to instruct clients to use appropriate levels
>> of trust, on signed vs unsigned DNS, and/or DNS received over encrypted
>> transports.
>>
>> I also think the guidance would be more precise if the encrypted
>> transport were not lumped together with the signed content.
>> Also something for a potential -bis or best practice document.
>>
>> Brian
>>
>>
>>> On Wed, Aug 31, 2022 at 5:43 AM Martin Thomson 
>>> wrote:
>>>
 On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote:
 > One additional suggested addition to the end of section 3.1 is:
 >>If DNS responses are cryptographically protected, and at least
 >>one HTTPS AliasMode record has been received successfully,
 >>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
 >>even when reverting to non-SVCB connection modes. Clients
 >>also MAY treat resolution or connection failures subsequent
 >>to the initial cryptographically protected AliasMode record
 >>as fatal.
 > [Brian's note: this last would provide some guidance to implementers
 of
 > clients: a signed HTTPS AliasMode record is a strong signal that the
 > DNS operator is discouraging fallback, albeit at a "MAY" level.]
 >
 > NB: The 2.4.3 change could be removed as it is mostly independent, as
 > could the last addition to 3.1.
 > The 1.2 change is very minor, is not too important but presents a
 > succinct clarification on the hostname vs domain name thing.
 > The 2.4.2 change and section 3 changes together are fixes for the
 > prefix/no-prefix issue (which was basically a scrivener's error, and
 > does not change the semantics at all.) They should stay or go as one
 > unit.

 I somewhat like this change, but I would generalize to receiving any
 signed HTTPS record during resolution, rather than limiting it to 
 AliasMode.

 That said, it is somewhat gratuitous.  I'd want it standardized if that
 was what was expected, but I'd prefer to defer that to an
 extension/follow-up.

 (In case you hadn't guessed, I tend to agree with those arguing for no
 change to the spec.)

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

>>> ___
>>> DNSOP mailing 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Ben Schwartz]

On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni 
wrote:

> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>
> > Relatedly, the results presented by EKR [1] at the most recent DNSOP
> > meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> > records through their local resolver.  To me, this implies that
> functional
> > origin endpoints are likely to be required even if client software gains
> > SVCB/HTTPS support.
>
> This is why my suggested client behaviour was cognisant of this impediment.
>
> - If the client's *initial* SVCB lookup succeeds, *then* fallback is
>   no longer an option.
>
> - If initial SVCB resolution fails (SERVFAIL, timeout, ...)
>   then the client behaves as though the SVCB record does not exist.
>
> This results in more predictable behaviour, without optimising for
> failure.


I don't think "more predictable" is really a desirable or achievable
outcome in this case.  Sophisticated clients (e.g. web browsers for HTTP,
iterative resolvers for DNS) tend to develop highly tuned heuristics and
state machines in pursuit of performance and reliability within their
particular constraints.  I think an instruction not to fall back in this
case would likely be ignored.  It also strikes me as questionable from a
standards perspective: if SVCB itself is optional, surely the client always
has the right to change its mind and disable its support for SVCB?


>   If the origin zone directs the service elsewhere, and there
> are no last-mile DNS lookup roadblocks, then the protocol becomes
> "reliable" (optimises for success and predictability, over fallback
> recovery leading to potentially/eventually undesirable outcomes).
>
>
> > I believe this balance could be revisited in several years' time, if
> "HTTPS
> > Record" support becomes sufficiently universal.
>
> Indeed it is a possible position to say that the Internet is not yet
> ready for semantically distinct services seen by SVCB-aware and legacy
> clients.


In addition to the deployment concerns I've mentioned earlier, a deployment
of this kind would be intrinsically insecure: a hostile intermediary could
override the choice of which semantically distinct service is seen by the
client.  That's another reason why this configuration is not permitted.

  But I think that latching on success of the initial lookup
> largely addresses the present impediments to reliance on SVCB.
>

The same could have been said of EDNS0 fallback, but the IETF wisely did
not attempt to leap straight to that configuration in the initial RFC.
Instead, we gave client implementors plenty of room to tune their own
fallback behaviors, and came back to tighten the system up much later when
it became safe to do so.

> Viktor notes with concern that AliasMode is a "non-deterministic
> > redirect".  Instead, the draft attempts to model the client behavior as a
> > preference ordered stack of endpoints:
> >
>
> I also noted an issue around the initial $QNAME having prefix labels (in
> the case of SVCB rather than HTTPS), and so this is likely not the name
> you want appended as a fallback to the target list.
>

Indeed, I think this is a clarity/precision problem that we should
correct.  Specifically, this "final value of $QNAME" endpoint is only used
if it is not the initial value of $QNAME (i.e. if an AliasMode record was
found).

Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
> preclude publishing A/ records there, making some of the example
> configurations in the draft impractical.
>

I don't agree with this reading of RFC 1123.  There is no requirement that
address records only be placed on hostnames, and there is no requirement
that TargetName be a hostname.  If I were making an argument here, it might
be about compatibility with RFC 8553 (Attrleaf), but hopefully this is
mostly moot per the above.


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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Ben Schwartz]

Thanks to Brian, Viktor, and others for the very close review, as always.
While I disagree with many of the claims made here, it's clear that some of
the text has proven confusing.  I'm not familiar with the process rules
given the draft's current state, but perhaps we can improve clarity with
some modest revisions.  I'll try to keep that discussion separate.

The key text for this discussion is in Section 3:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client now attempts to use non-SVCB
   connection modes.

I believe most reviewers correctly understood this to mean that, if all
else fails, you can connect to https://www.example.com/ using the  or A
records on www.example.com, as usual.  The logic is simple: this draft does
not make "HTTPS Record" support mandatory for HTTP clients.  Thus, HTTP
servers are still required to publish functional address records on the
origin hostname, as usual.  (Similar logic applies to any other
pre-existing protocol that may be used with SVCB.)  Since these records are
required to be present and working, we can hardly forbid clients from using
them.

Relatedly, the results presented by EKR [1] at the most recent DNSOP
meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
records through their local resolver.  To me, this implies that functional
origin endpoints are likely to be required even if client software gains
SVCB/HTTPS support.

Brian proposes a use case of serving only a warning message on the origin
endpoint, in order to minimize the load on IP addresses that are likely
hardcoded into a customer's zone.  I understand the appeal of this
configuration, but for the above reasons it is deliberately not supported
in this draft.  Instead, the draft attempts to ensure that deploying and
implementing the HTTPS record "does no harm", by giving participating
clients no worse reliability than legacy clients.  (Also, Brian's analysis
indicates that the origin hostname's address record TTL would bias the
endpoint selection, but this is not correct.)

I believe this balance could be revisited in several years' time, if "HTTPS
Record" support becomes sufficiently universal.  For example,
post-deployment data from browsers may show that we could eliminate the
final fallback without reducing reliability.  For now, I think it's better
to keep the current guidance, in order to minimize the risk of disruptions
as these new RR types begin to be deployed.

Viktor notes with concern that AliasMode is a "non-deterministic
redirect".  Instead, the draft attempts to model the client behavior as a
preference ordered stack of endpoints:

1. Basic: the origin endpoint (status quo ante)
2. Better: the endpoint at the end of the AliasMode chain
3. Best: the ServiceMode records

I think it's best to think of AliasMode as an alias that is optional when
SVCB is optional, and mandatory when SVCB is mandatory.  This seems natural
enough to me, and allows it to be used in environments like the web where
"fail fast" is not an appealing option.

--Ben Schwartz


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

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

[Ben Schwartz]

On Tue, Aug 16, 2022 at 10:15 PM Schanzenbach, Martin <
mschanzenb...@posteo.de> wrote:

> Hi,
>
> > On 16. Aug 2022, at 16:32, David Conrad  wrote:
> >
> > Signed PGP part
> > On Aug 15, 2022, at 7:07 PM, Stephen Farrell 
> wrote:On 16/08/2022 03:01, John Levine wrote:
> >>> Right. If it's FCFS, I am sure I am not the only person who will be
> >>> waiting at the gate with thousands of preemptive registrations.
> >> Why?
> >
> > Because they believe (or are convinced) there is or will be profit in
> it. My experience has been that the majority of folks who are getting
> Unstoppable Domains TLDs haven’t the slightest clue what they are or why
> they’re not particularly useful.  And they’re paying actual money, not
> merely (say) copying a document and changing a few words or wading through
> mind-numbing technical process. They are speculators and if the cost of
> obtaining the “asset” is below what the projected/potential value may be,
> then they’ll “invest”.
> >
>
> That is exactly why IMO the namespaces under .alt must have a technical
> merit and this merit gives the protocol a shot at a (or a few based on the
> technical design) (free) name under .alt.
> It should not be possible to get such a name in the registry without a
> technical justification (e.g. a spec that proposes a new way of doing name
> resolution). No political or policy considerations necessary.
> And this is why there must be a registration policy and process.
>

What you are describing does not resemble draft-ietf-dnsop-alt-tld, which
would define the "alt" SUDN.  That document says:

   There is no IANA
   registry for names under the ALT TLD - it is an unmanaged namespace,
   and developers are responsible for dealing with any collisions that
   may occur under .alt.

If you want a SUDN for technically meritorious non-DNS names, perhaps you
should distinguish that proposal from .alt.

This merit needs to be established, yes. And I think it should be done
> through review by the IETF or the ISE.
> And yes, there is a reason why this sounds a bit like a RFC6761 SU-TLD,
> because the motivation makes sense to me.
>

In this case, the path forward is clear: propose GNS as a standards-track
RFC, proceed through to publication, and use the RFC 6761 process to claim
a SUDN for it.  Publication of a standards-track RFC is the IETF's sole
mechanism for indicating support for the merit of a technical proposal, and
is also the threshold for use of RFC 6761.

However, if the IETF does not have consensus to adopt GNS as a standard,
then it is difficult to see why the IETF would allocate a portion of the
namespace for it.


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

Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-09: (with DISCUSS and COMMENT)

[Ben Schwartz]

On Mon, May 23, 2022 at 8:01 AM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:

> --
> DISCUSS:
> --
>
> Thank you for the work on this document.
>
> Many thanks to Cullen Jennings for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.
>
> Thank you for addressing my previous DISCUSS and COMMENTs. I have reviewed
> v-09
> and I noticed 4 points were not addressed (or I missed them). Do let me
> know if
> you think no further clarifications were necessary - just making sure these
> were not missed, as I have not seen any answers to them.
>
> Re: the use of SHOULD - thank you for adding context to most of them. I
> did not
> see any added context to these following two SHOULDs:
>

OK, I've proposed adjustments to those two SHOULDs at
https://github.com/MikeBishop/dns-alt-svc/pull/392

...

> --
> COMMENT:
> --
>
> 4. -
>
>  The value is then
>validated and converted into wire-format in a manner specific to each
>key.
>
> FP: Section 15.3.1 states
>
>registration policy ([RFC8126], Section 4.5).  The designated expert
>MUST ensure that the Format Reference is stable and publicly
>available, and that it specifies how to convert the SvcParamValue's
>presentation format to wire format.
>
> This covers the conversion, but does not cover the validation mentioned
> above.
> (This could be really easily addressed by making sure that not only it
> specifies how to convert but also how to validate).
>

I don't think this text change is necessary, because any specification of
the conversion necessarily also covers validation.  A "conversion" in this
context is an algorithm that accepts one input (an octet sequence) and
produces one output, which is either an octet sequence or a failure
indication.  If the conversion fails, we say that the input was invalid.

10. -
>
> Table 1
>
> FP: The table reports that
>
>| 65280-65534 | N/A | Private Use| (This document) |
>
> But that is not specified in the text above, that only talks about expert
> review registration policy. That should be made consistent.
>

This text was slightly adjusted in -09 based on your comment.   It now
reads "_New_ entries in this registry are subject to an Expert Review
registration policy" (emphasis mine).  This is consistent with the example
given in RFC 8126 Section 2.2.

I believe the source of confusion here is that RFC 8126 defines "Private
Use" twice, with incompatible meanings: Section 4.1 describes it as a
Registration Policy, whereas Section 6 defines it as a Registration
Status.  This registry is using the latter definition.


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-09.txt

[Ben Schwartz]

Internet-Drafts "expire" but they never go away.  The IETF makes them
publicly accessible on an "archival" basis.  RFC 8447 is an example of an
RFC that lists them specifically as a suitable specification form, without
limitation.  My impression is that the WG consensus was for this draft to
do the same.

I don't think this allowance serves a specific purpose beyond making it
very easy to acquire registrations, which is something that several working
group members voiced support for.  It is not limited to experimental usage.

I believe the underlying logic is that parameter registrations are harmless
because unrecognized parameters can safely be ignored, and the codepoint
space is not at risk of exhaustion.

On Mon, May 9, 2022 at 6:25 PM Murray S. Kucherawy 
wrote:

> On Mon, May 9, 2022 at 3:12 PM Ben Schwartz  wrote:
>
>> Yes, that's covered in the description:
>>
>> The designated expert MUST ensure that the Format Reference is stable and
>> publicly available, and that it specifies how to convert the
>> SvcParamValue's presentation format to wire format. The Format Reference
>> MAY be any individual's Internet-Draft, or a document from any other source
>> with similar assurances of stability and availability.
>>
>
> Yes, I saw that text, but that sentence doesn't make it clear to me why an
> auto-expiring document is acceptable as a possibly-permanent format
> reference, so I thought I'd double check.
>
> -MSK
>


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

Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec

[Ben Schwartz]

I support adoption of this draft.

I appreciate that it acknowledges that deployment has been lower than some
advocates hoped, but I think the text following that is misplaced:

   However, this low level of implementation
   does not affect whether DNSSEC is a best current practice; it just
   indicates that the value of deploying DNSSEC is often considered
   lower than the cost.

I would suggest a different caveat, perhaps:

Nonetheless, the majority deployment of DNSSEC within certain major
registries [1], and near-universal deployment across Top-Level Domains [2],
demonstrate that DNSSEC is suitable for implementation by both ordinary and
highly sophisticated domain owners.

[1] https://stats.sidnlabs.nl/en/dnssec.html
[2] https://stats.research.icann.org/dns/tld_report/

On Fri, Mar 25, 2022 at 6:37 AM Paul Wouters  wrote:

> On Mar 25, 2022, at 00:08, Tim Wicinski  wrote:
> >
> > If you attended the most recent DNSOP session, you've heard Warren speak
> about creating a BCP for DNSSEC, including  all of the DNSSEC related RFCs,
> in order to make life easier for implementers and DNS operators.
>
> Please do. As an author and reviewer, I have ran into issues and then
> inconsistencies on how to normatively reference DNSSEC.
>
> Paul
> ___
> 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

Re: [DNSOP] On removing a pargraph in RFC4035

[Ben Schwartz]

If we assume the existing install base of resolvers isn't going away, then
I don't see how we could relax the requirement.  There are already deployed
resolvers enforcing it.  You would need a "flag day" to deprecate them,
which could not happen for many years.

This seems a lot harder than just telling your next DNS provider that you
can't do business with them until they implement another one of the (very
small number of) widely implemented algorithms.

Of course, I've personally argued for essentially the opposite of this
proposal [1].  Until DNSSEC has algorithmic agility without sacrificing
compatibility or security, it's only usable as "extra" security.

[1]
https://www.ietf.org/archive/id/draft-schwartz-dnsop-dnssec-strict-mode-00.html

On Mon, Mar 21, 2022 at 12:06 PM Ulrich Wisser  wrote:

> Hi Ben,
>
> The proposal is not to remove the possibility of double signatures, but to
> relax the requirement so that other use cases become possible.
>
> Our use case is the transition from one dns provider to another without
> going insecure. If both use the same algorithm you can use the multi-signer
> dnssec to do this. But if the signers only support a distinct set of
> algorithms you are out of luck.
>
> As Libor pointed out, there are some implications to validation that must
> be considered.
>
> I would say, there are no obvious or easy solutions. But I think/hope that
> DNSOP will be able to come up with some ideas that we can explore.
>
>
> /Ulrich
>
>
> On 21 Mar 2022, at 10:32, Ben Schwartz  wrote:
>
> I'm concerned about this.  Concretely, this seems like it would raise a
> major barrier to rolling out new algorithms.  For example, any zone that
> offers ECDSA and RSA signatures would be insecure for any RSA-only
> resolvers.  It's hard to see how new algorithms could be adopted at scale
> if this rule were in place.
>
> On Sun, Mar 20, 2022 at 4:42 PM libor.peltan  40nic...@dmarc.ietf.org> wrote:
>
>> Hi Ulrich, dnsop,
>> thank you for your effort in improving DNS.
>>
>> This is a follow-up to your proposal on easing the requirements by
>> RFC4035, which say, in short, that if there's a DS of an algorithm,
>> there must be a complete DNSKEY set of that algorithm, and if there is a
>> DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that
>> algorithm.
>>
>> The counter-proposal is to only require at least one valid
>> DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this
>> would enable multi-signer setups with the signers supporting different
>> algorithms, which in turn is beneficial to enable smooth transitions
>> between such signers.
>>
>> Let's suppose we go this way. How do we specify the validator behaviour
>> when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and
>> the validator only understands algorithm A, but not B? I guess BOGUS
>> will be no longer proper here, we would probably stick at INSECURE. Am I
>> correct?
>>
>> Now a different scenario. There are algorithm A and B DNSKEYs, the whole
>> zone is also signed by both alg A and B RRSIGs, and the validator only
>> understands alg A. Some man-in-the-middle attacker intercepts the
>> answers by fiddling with the records, while removing algorithm A RRSIGs
>> from the packets. The validator ends up with INSECURE and lets the
>> attacker poison some cache...
>>
>> With current DNSSEC requirements, it is enough for security if there is
>> any intersection between the algorithms which the zone is signed by, and
>> the algorithms supported by the validator, respectively. With your
>> proposal, it would be required that the validator supports all the
>> algorithms, which the zone is signed by.
>>
>> I agree that in case the zone is signed by just one algorithm
>> (occasionally being rolled-over to just one different one), these
>> conditions are equivalent. Fortunately, it did not happen yet (or I'm
>> not aware of), that the existence of different validators with distinct
>> sets of supported algorithms forced signers to permanently sign zones
>> with two algorithms in parallel. The question is, if it remains so for
>> the future. I can't imagine what would happen in case of a "post-quantum
>> apocalypse", maybe it wouldn't be a problem, but it might.
>>
>> It would also cause the paradox and indeed creepy security quirk, that
>> if you sign your zone with one more algorithm, which is
>> cryptographically strong but poorly adopted (perhaps experimental), it
>> will result in _less_ security. Hardly anyone does this, but if they do,
>> they will be surprised, I think.
>>

Re: [DNSOP] IANA Policy for SVCB

[Ben Schwartz]

On Mon, Mar 21, 2022 at 6:33 AM Paul Wouters  wrote:

> On Mon, 21 Mar 2022, Ben Schwartz wrote:
>
> > This leaves us with several possible options:
> > 1. Change the MUST to SHOULD, or otherwise indicate that IANA is not
> expected to enforce anything about the contents of the format
> > reference.  Registrations might appear without a suitable format
> reference, resulting in keys that are difficult to parse and
> > serialize interoperably (e.g. same zone file produces different results
> in different authoritative server implementations).
> > 2. Change the registration policy to Expert Review, relying on the
> designated expert to enforce this rule.  Registrations might be
> > processed more slowly.
> > 3. Change the registration policy to Specification Required.  This is
> similar to #2 but incorporates formal guidance about what kinds
> > of documents qualify as a "specification" (e.g. must be "permanent and
> readily available").  Note that this is not "RFC Required":
> > any individual I-D is considered a qualified specification as soon as
> it is uploaded to the Datatracker.
>
> I favour #2, especially as this intersects the DNS protocol with other
> protocols, and those requesting SVCB might not be DNS experts. Having
> a DNS expert to verify things make sense seems good. Although I would
> hope the Expert would also want a Specification Required as their
> input.
>

Note that Specification Required is a superset of Expert Review: "This
policy is the same as Expert Review, with the additional requirement of a
formal public specification." (
https://datatracker.ietf.org/doc/html/rfc8126#section-4.6)


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

Re: [DNSOP] On removing a pargraph in RFC4035

[Ben Schwartz]

I'm concerned about this.  Concretely, this seems like it would raise a
major barrier to rolling out new algorithms.  For example, any zone that
offers ECDSA and RSA signatures would be insecure for any RSA-only
resolvers.  It's hard to see how new algorithms could be adopted at scale
if this rule were in place.

On Sun, Mar 20, 2022 at 4:42 PM libor.peltan  wrote:

> Hi Ulrich, dnsop,
> thank you for your effort in improving DNS.
>
> This is a follow-up to your proposal on easing the requirements by
> RFC4035, which say, in short, that if there's a DS of an algorithm,
> there must be a complete DNSKEY set of that algorithm, and if there is a
> DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that
> algorithm.
>
> The counter-proposal is to only require at least one valid
> DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this
> would enable multi-signer setups with the signers supporting different
> algorithms, which in turn is beneficial to enable smooth transitions
> between such signers.
>
> Let's suppose we go this way. How do we specify the validator behaviour
> when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and
> the validator only understands algorithm A, but not B? I guess BOGUS
> will be no longer proper here, we would probably stick at INSECURE. Am I
> correct?
>
> Now a different scenario. There are algorithm A and B DNSKEYs, the whole
> zone is also signed by both alg A and B RRSIGs, and the validator only
> understands alg A. Some man-in-the-middle attacker intercepts the
> answers by fiddling with the records, while removing algorithm A RRSIGs
> from the packets. The validator ends up with INSECURE and lets the
> attacker poison some cache...
>
> With current DNSSEC requirements, it is enough for security if there is
> any intersection between the algorithms which the zone is signed by, and
> the algorithms supported by the validator, respectively. With your
> proposal, it would be required that the validator supports all the
> algorithms, which the zone is signed by.
>
> I agree that in case the zone is signed by just one algorithm
> (occasionally being rolled-over to just one different one), these
> conditions are equivalent. Fortunately, it did not happen yet (or I'm
> not aware of), that the existence of different validators with distinct
> sets of supported algorithms forced signers to permanently sign zones
> with two algorithms in parallel. The question is, if it remains so for
> the future. I can't imagine what would happen in case of a "post-quantum
> apocalypse", maybe it wouldn't be a problem, but it might.
>
> It would also cause the paradox and indeed creepy security quirk, that
> if you sign your zone with one more algorithm, which is
> cryptographically strong but poorly adopted (perhaps experimental), it
> will result in _less_ security. Hardly anyone does this, but if they do,
> they will be surprised, I think.
>
> Just to be clear, I don't want to fight against your ideas. I'm just
> pointing at possible problems that could emerge.
>
> Thanks,
> Libor
>
> ___
> 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

Re: [DNSOP] Martin Duke's No Objection on draft-ietf-dnsop-svcb-https-08: (with COMMENT)

[Ben Schwartz]

On Tue, Mar 1, 2022 at 10:52 AM Martin Duke via Datatracker <
nore...@ietf.org> wrote:

> --
> COMMENT:
> --
>
> To this DNS non-expert, I found it hard to follow the motivation for
> AliasMode.
> In particular, I asked myself the following questions that could have been
> answered in the Introduction or in (2.4.2):
>
> - Why is it not OK for a CNAME to alias the apex, but OK for AliasMode to
> do
> so? [having asked around, it's because CNAME aliases all the record types,
> which is nonsensical for the apex, and AliasMode does not]
>

OK, we can add or cite an explanation (
https://github.com/MikeBishop/dns-alt-svc/issues/373).

- For non-apex domains, under what conditions would I use AliasMode instead
> of
> a CNAME? Is it just when I don't want to bring along record types besides
> A,
> , and SVCB?
>

A SVCB record is always for a single "origin" (scheme, host, and port).  A
CNAME is for an entire name.  I would say that's the dispositive factor in
determining which one you want to use.


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

Re: [DNSOP] Francesca Palombini's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)

[Ben Schwartz]

On Wed, Mar 2, 2022 at 5:13 PM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:

>
> --
> DISCUSS:
> --
>
> Thank you for the work on this document
>
> Many thanks to Cullen Jennings for his ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/CfAGYlDfw5kPjlhbujmikX43J6Q/.
>
> I am concerned by the use of SHOULD in this document. In several places
> (see 1.
> below for what I identified as problematic SHOULDs) the document lacks text
> about why these are SHOULD and not MUST or MAY.


OK.  I've noted the instances you've identified at
https://github.com/MikeBishop/dns-alt-svc/issues/355

...

> I also have a number of non blocking comments and questions. I will
> appreciate
> answers to my questions, to improve my understanding. If any clarification
> comes out of it, I hope it will help improve the document.
>

I've attempted to answer questions inline, and tracked the other comments
at https://github.com/MikeBishop/dns-alt-svc/issues/372.

...

> --
> COMMENT:
> --
>
>
> 2. -
>
>This subsection briefly describes the SVCB RR in a non-normative
>manner.  (As mentioned above, this all applies equally to the HTTPS
>RR which shares the same encoding, format, and high-level semantics.)
>
> FP: I am not sure about why this section is described as non-normative but
> does
> define requirements etc. Maybe it is normatively described somewhere else?


Yes, this section highlights some requirements but does not include any
normative language.  Any normative requirements mentioned in this section
are defined normatively elsewhere in the document.


> Then
> a pointer to that makes sense.


OK, we can add more forward references to this section.  (Tracked at
https://github.com/MikeBishop/dns-alt-svc/issues/371.)


> Also why does this mention encoding and format
> but there is no encoding specified.
>

This section of the introduction is just an overview, for a reader who is
not familiar with SVCB.  The detailed specification of encodings, formats,
and other requirements is later in the document.


> 5. -
>
>SvcParams in presentation format MAY appear in any order, but keys
>MUST NOT be repeated.
>
> FP: Seems to contradict
>
>SvcParamKeys SHALL appear in increasing numeric order.
>

Ordering is unspecified in presentation format, but must be sorted in wire
format.

6. -
>
>If the client has an in-progress TCP connection to
>[2001:db8::2]:1234, it MAY proceed with TLS on that connection using
>ech="222...", even though the other record in the RRSet has higher
>priority.
>
> FP: I believe this is descriptive of the example and should not use BCP 14
> MAY.
>

This "MAY" is intended as an exception to "Clients SHOULD try
higher-priority alternatives first" in Section 3.

7. -
>
>For example, the following is a valid list of SvcParams:
>
>ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech
>
> FP: I expected this to be a comma separated list.
>

Section 2.1 notes that "SvcParams are a whitespace-separated list".  The
SvcParamValue for "mandatory" is a comma-separated list ("key65444,ech").

12. -
>
>All protocols employing "http://; or "https://; URLs SHOULD respect
>HTTPS RRs.  For example, clients that support HTTPS RRs and implement
>
> FP: I am not sure how the first sentence is supposed to be implemented,
> hence
> why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not
> be
> the clearest wording.
>

There are many protocols that are "layered on top" of HTTP in some fashion,
e.g. generating an HTTP URL and performing an HTTP connection as part of
some process.  This text was originally written for WebSocket (wss://), but
it could also potentially apply to something like MTA-STS, which generates
an HTTP URL to fetch information about a mail server.

The SHOULD applies primarily to implementers of such protocols, who may
need to configure their HTTP implementations appropriately.

I think the word "respected" was used because HTTPS-record support is
optional for HTTP in general.  The point here is that HTTPS records are
applicable to such "embedded" instances of HTTP, and should not be ignored
merely because HTTP is not the "top layer" protocol.


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

Re: [DNSOP] Erik Kline's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)

[Ben Schwartz]

On Thu, Mar 3, 2022 at 3:44 AM Erik Kline via Datatracker 
wrote:

> --
> DISCUSS:
> --
>
> [Appendix D.2]
>
> * Sorry to be super nitpicky/petty about this.
>
>   With respect to Figure 7: IPv4-mapped IPv6 addresses have a complicated
>   history (see RFC 4942 S2.2 for an amuse-bouche, as well as itojun's
>   draft-itojun-v6ops-v4mapped-harmful).
>
>   Unless there is something very useful to be gained by the inclusion of
> this
>   example (what?) I would strongly suggest removing it.  I fear it will
> only
>   cause confusion.
>

This example will be changed to present only the "IPv4-embedded syntax",
removing the reference to IPv4-mapped IPv6 (
https://github.com/MikeBishop/dns-alt-svc/pull/362).

--
> COMMENT:
> --
>
> [S2.3; comment]
>
> * "When a prior CNAME or SVCB record has aliased to a SVCB record, each
>RR shall be returned under its own owner name."
>
>   I think this could use some explanation and a reference to Section 11.
>   Perhaps something along the lines of
>
>   This is in account of the client resolution process [Section 3].
>   See also discussion in [Section 11.1].
>

 Noted at https://github.com/MikeBishop/dns-alt-svc/issues/370


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

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

[Ben Schwartz]

I like this definition.  However, I think it would be clearer to say
"useful" instead of "necessary".

On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane  wrote:

> Despite what the subject line says, I’d like to follow up on the
> discussion about glue from today’s interim meeting.
>
> First, I think the definition of glue given in RFC 2181 is problematic in
> a number of ways.  It is overly broad (e.g., "any record ... that is not
> properly part of that zone” and "any other stray data that might appear”).
> It essentially says that all non-authoritative data is glue, including NS,
> which is wrong IMO.
>
> If we can ignore what 2181 says, then the question is whether or not glue
> is limited only to addresses.  Historically it has only meant addresses,
> since those address RRs were required for zones with in-domain name
> servers.  There are some new proposals in DPRIVE to publish more record
> types in parent zones and have them considered as glue.  This has obvious
> implications server behavior given the glue-is-not-optional draft.
>
> On one hand I think it would be a lot simpler to just say that only
> address records can be glue.  But I’m not sure that is defendable given the
> directions things are going.  Here’s a definition of glue that I came up
> with:
>
> Glue is non-authoritative data in a zone that is transmitted in the
> additional section of a referral response on the basis that the data might
> be necessary for resolution to proceed at the referred name servers.
>
> I also feel like we might be heading in a direction where there would need
> to be a registry or some standardization of which RR types can be treated
> as glue.
>
> DW
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Ben Schwartz]

On Wed, Nov 10, 2021 at 11:18 AM Petr Špaček  wrote:
...

> 2. If the new option was present in query, then DNS responder sends back
> Extended DNS Errors option (EDE, RFC 8914) with INFO-TEXT field
> formatted according to structured JSON specified in this draft.
>

I like this idea a lot.  In fact, I don't even think we need a new option.
It's not as if INFO-TEXT is already widely used.  We can just declare
something like "if the INFO-TEXT is JSON, here's what it means".

This also allows us to remove the "access denied" emphasis, and broaden our
focus to explaining all kinds of resolution failures.

I also agree that requiring an HTTP URL seems out of place here.  I would
prefer an "ID" string of unspecified contents, so that operators can use
UUIDs, domain names holding TXT records, URIs, or whatever mechanism they
want to identify failure types.


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

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

[Ben Schwartz]

This text is a "SHOULD NOT" because there has been some discussion of
potential future uses for SvcParams in AliasMode.  If implementations
follow the current text, this kind of extension can be backwards-compatible.

I agree that the resulting behavior creates a typo hazard for zone
administrators.  Perhaps we could keep the "SHOULD NOT", but add a line
like "Zone file parsers MAY emit a warning"?


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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-svcb-https-07

[Ben Schwartz]

-last-call

Thanks for the detailed review, Dale.  I've posted a proposed change to
incorporate most of your comments:
https://github.com/MikeBishop/dns-alt-svc/pull/335

On Sat, Aug 14, 2021 at 7:34 AM Dale Worley via Datatracker <
nore...@ietf.org> wrote:

> Technical issues:
>
> Whereas SRV records have both a priority and weight field, SVCB
> records have only a priority field.  (This point is not addressed in
> section C.1.)


I've proposed some text on that point for section C.1, but I don't think we
need a Weight field.  As you noted, it doesn't seem to have been widely
used within SRV.

In SVCB, weighted load balancing can be added in the future as a SvcParam
if there is demand, so it seemed wise to exclude it from the base
specification for simplicity.


>
> 2.2.  RDATA wire format
>
>When the list of SvcParams is non-empty (ServiceMode)
>
> Actually, an AliasMode record can have a non-empty SvcParams, it
> simply SHOULD NOT.  The subtle case is whether an AliasMode record
> with non-empty SvcParams is governed by this section (which requires
> the SvcParams to be properly formatted and "If any RRs are malformed,
> the client MUST reject the entire RRSet") or by section 2.4.2 ("In
> AliasMode, ...  recipients MUST ignore any SvcParams that are
> present.")  I recommend stiffening the requirement so that AliasMode
> records MUST NOT have SvcParams (and having the zone file processor
> enforce it).
>

I've removed the confusing parenthetical, but otherwise I would prefer not
to change the normative requirements here.  While we don't have any clear
use case or semantics for AliasMode SvcParams, I think it's conceivable
that we could discover some in the future, and it might help if current
implementations just ignore them.


>
> 8.1.  Query names for HTTPS RRs
>
>Reusing the service name also allows ...
>
> I assume this means "Using one record for both HTTP and HTTPS allows ..."
>

No this is about using the same QNAME for HTTPS that we currently use for A
and .  Clarified.


>
> D.2.  ServiceForm
>
> Is this "ServiceMode"?
>

Yes, fixed.


> This section uses "vector" in three places where "form" or "example"
> would likely be better.
>

"Test vector" is a standard phrase in this context, e.g.
https://datatracker.ietf.org/doc/html/rfc6716#appendix-A.4


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-13.txt

[Ben Schwartz]

I think the "Privacy Considerations" section should probably mention QNAME
minimization, which ought to help a little.

I would also be interested in seeing some guidance about interaction
between the relative form (.alt) and good old-fashioned search domains.  It
seems to me that the interaction there is poor... perhaps bad enough to
recommend using the absolute form only.

On Mon, Jun 21, 2021 at 1:49 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title   : The ALT Special Use Top Level Domain
> Authors : Warren Kumari
>   Andrew Sullivan
> Filename: draft-ietf-dnsop-alt-tld-13.txt
> Pages   : 11
> Date: 2021-06-21
>
> Abstract:
>This document reserves a string (ALT) to be used as a TLD label in
>non-DNS contexts.  It also provides advice and guidance to developers
>developing alternative namespaces.
>
>[Ed note: Text inside square brackets ([]) is additional background
>information, answers to frequently asked questions, general musings,
>etc.  They will be removed before publication.  This document is
>being collaborated on in Github at: https://github.com/wkumari/draft-
>wkumari-dnsop-alt-tld.  The most recent version of the document, open
>issues, etc should all be available here.  The authors (gratefully)
>accept pull requests. ]
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-13
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

For those who prefer Github's UI, I've posted Dick's diff to a branch
commit in our repository [1].

The diff contains a number of editorial suggestions, such as removing use
of ABNF, which we can consider separately.  The key substantive change, as
discussed earlier in this thread, is to make comma-escape handling for
value lists happen during character-string escape parsing, instead of
afterward.

In the implementations I've worked on so far, this change would be highly
inconvenient to implement, as it conditionally modifies the core
character-string parsing loop that has thus far been entirely
RR-type-independent and shared by all zone-file parsing contexts.

The only way I can see to accommodate both of these implementation
perspectives is to allow implementors to avoid the offending special case,
which, as I've noted before, is not currently needed, and may never be
needed.  I have proposed a change [2] that would add this option (now
updated to avoid conditioning requirements on the IANA registry, in
response to feedback from Paul Wouters).

--Ben

[1]
https://github.com/MikeBishop/dns-alt-svc/commit/5d3d651230de06adce10625d0dfb70ce8e938a39
[2] https://github.com/MikeBishop/dns-alt-svc/pull/325/files

On Sat, May 22, 2021 at 12:58 PM Dick Franks  wrote:

> On Sat, 22 May 2021 at 17:06, Paul Hoffman  wrote:
> >
> > On May 22, 2021, at 1:58 AM, Dick Franks  wrote:
> >
> > > Please find attached the promised words to resolve the conflict
> > > between current draft and RFC1035.
> > >
> > > This is presented as a context diff.
> >
> > Where do we find the original Markdown file so we can evaluate the diff?
>
> https://github.com/MikeBishop/dns-alt-svc
>
> --Dick
>
> ___
> 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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

On Mon, May 17, 2021 at 2:46 PM Brian Dickson 
wrote:

> I re-read (several times) the current -05 version of the draft. I found it
> difficult to follow and understand several aspects of the "automatically
> mandatory", "mandatory", and mandatory usage in the document, both
> syntactically and semantically.
>

I'm sorry this wasn't clear.  The text at the top of Section 7 defines the
terminology

   In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the
   RR will not function correctly for clients that ignore this
   SvcParamKey.  Each SVCB protocol mapping SHOULD specify a set of keys
   that are "automatically mandatory", i.e. mandatory if they are
   present in an RR.

...

> Here are some specific suggestions, including incorporating the updated
> proposed encodings:
>
>- Use the term MTI (mandatory to implement)
>   - MTI parameters would be "alpn", (maybe) "no-default-alpn", and
>   (maybe) "port"
>   - The IANA table in 14.3.2 really needs an MTI column in addition
>   to the other columns
>
> In the HTTPS protocol mapping as presently defined, there are no MTI
parameters.  A compliant client implementation might not have any supported
parameters.  We could add a row for this in the table, but its value would
be "none".  (Future mappings may indeed have MTI parameters.)

As the table notes, the "automatically mandatory" parameters are
"no-default-alpn" and "port".  A client that doesn't support any parameters
would ignore any record that contains these parameters.

>
>- For each binding registry,
>
> Mapping documents are IETF-controlled, not IANA-controlled, so there isn't
a "registry" per se.

an additional table column specific to that registry should be
> included/added: "non-negotiable", i.e. MTI for this binding.


A "service binding" is a single SVCB RR; I presume you mean the "mapping",
a document that defines how to use SVCB in some context.

It sounds like "non-negotiable" is a synonym for "automatically
mandatory".  I'm certainly open to changing the draft's terminology.
"non-negotiable" might be clearer, although I'm not sure what negotiation
it's describing.

>
>- Replace the "mandatory" thing, with an "optional" flag to be
>optionally appended to any parameters that are not "non-negotiable".
>   - This also removes the need to have a sorted list of mandatory
>   attributes
>   - Each binding will have a list of non-negotiable attributes, which
>   can be used for validating the "optional" flag on both the authority 
> side
>   and the client.
>   - Any parameter that is not non-negotiable, but does not have the
>   optional flag, must be supported by the client for the parent HTTPS/SVCB
>   record to be accepted by the client.
>
> It sounds like this "optional" flag is exactly the inverse of the present
"mandatory" indication.  The present structure was chosen in part to
simplify the zone file and wire formats, by avoiding an additional mark
that must be written or parsed on every SvcParam.  Additionally, for
compatibility, it seems likely that the great majority of parameters will
either be automatically mandatory (as specified in the mapping document) or
optional (especially if they are introduced later), so making parameters
mandatory unless marked otherwise seems like the wrong default.

>
>- The binding tables then become lists of parameter sub-types that the
>specific binding uses, marked as optional-allowed or non-negotiable. The
>binding table incorporates all the MTI sub-types as well.
>
> I'm not sure what you're describing, but note that new parameters can be
defined over time, and we do not want every new parameter draft to Update
the SVCB RFC.  The proposed parameter registration policy is
first-come-first-served, with the understanding that clients will normally
ignore new parameters that they do not recognize.

>
>- The binding tables obviously still need default values (if
>appropriate), e.g. for ALPN.
>
> The HTTPS binding would then consist of:
>
>- Default ALPN of "http/1.1"
>- MTI of "alpn"
>
> Note that declaring alpn to be "MTI" would have no effect.  As presently
defined for HTTPS, the "alpn" SvcParamKey only adds advertised protocols.
If you prefer to stick to the default protocol (TLS over TCP), you can
"implement" the alpn parameter by ignoring it.

>
>- aNN of "port"
>- NN of "no-default-alpn"
>- Optional of "ecn"
>- Optional of "ip4hint"
>- Optional of "ip6hint"
>
> And an HTTPS referenced record (included by reference from record with
> SvcPriority between 1 and 127), would have the following rules:
>
>- Any "optional" parameter MUST be implemented by the client, UNLESS
>the "optional" flag is present in the HTTPS referenced record
>
> It seems you are drawing distinctions between "mandatory to implement",
"non-negotiable", "optional", and "flagged optional".  I don't believe this
is a simpler formulation than the current 

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

On Thu, May 13, 2021 at 3:56 AM libor.peltan  wrote:

> Hi all,
>
> just my comment:
>
> Perhaps complexity is subjective.  The important thing is that the
> standard be reasonably implementable.  I hope that the list of published
> implementations [3] will serve as convincing evidence that the current
> draft is sufficient in that regard.
>
> --Ben
>
> I agree that complexity is subjective. I have no problem implementing
> complex procedures. But more complexity means more probability for bugs
> (and even security issues).
>
> Currently, the authoritative server (while transforming presentation to
> wire format), MUST:
>
>  - sort the SvcParams by key
>  - verify their uniqueness
>  - deal with list of fields nested in other fields (this includes the
> discussed comma escaping)
>
> and the client MUST:
>
>  - verify that SvcParams are sorted and unique
>  - deal with list of fields nested in other fields (at least that various
> "lengths" match)
>
> In the concurrent proposal, the sorting and deduplication will be "for
> free", because DNS ensures this,
>
DNS only ensures that each entire record appears only once, which is
different from the current draft's requirement that each key appear only
once (to form a map).

> and each RData would consist on just one list of values, much easier to
> handle.
>
I'm not sure I understand.  Are you proposing that each record contains a
single value, or each record contains multiple values?  If the former, note
that you have a "set" of values, not a "list"; order is not preserved.  Any
value type that is actually an ordered list will have to complicate its
value format in order to express the ordering.  If you mean for each record
to contain multiple values, then you either have multiple layers of
redundant multiplicity (sets of lists), or you require that clients
validate the RRSet to ensure there are no duplicate keys.  Either way, you
have to consider who is responsible for preventing multiple values for
single-valued parameters, whereas in the current draft, this is essentially
inexpressible.

> On the other hand, the client would have to group several RData (already
> sorted) to get all info, and believe they're all there (as Brian pointed
> out, it has to anyway). And it would cost more bandwith due to DNS overhead
> -- repeated TTLs etc (thanks Ben and Vladimir for the lesson).
>
> Have I summarized the pros/cons of both approaches well enough?
>
I would also add the considerations for humans who are reading or writing
zone files.  Can they see bindings as a unit, with confidence?  Is the
syntax familiar and self-explanatory?  Is it excessively verbose?  Are
typos likely to be caught early, with helpful error messages?


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

On Tue, May 11, 2021 at 10:32 AM Joe Abley  wrote:

> On 11 May 2021, at 12:32, Ben Schwartz  wrote:
>
> > On Tue, May 11, 2021 at 9:20 AM Joe Abley  wrote:
> >> On 11 May 2021, at 12:08, Ben Schwartz  40google@dmarc.ietf.org> wrote:
> >> ..
> >>> * It saves at least 11 bytes of overhead per parameter by avoiding
> repetition of
> >>>   the name, type, class, TTL, and inter-pair binding ID.
> >
> > ... but it inflates response volume in the case where a separate
> SvcParams RRSet is able to be cached significantly longer than the SVCB
> RRSet.
> >
> > It sounds like you're proposing a design in which the information in one
> SVCB record is not just spread across multiple records in an RRSet, but
> actually across multiple RRSets.
>
> Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR
> becomes a pointer to a second RRSet with a different RRType. So the
> SvcParams information is spread across multiple records in a a different
> RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try
> again.
>
> Note that I'm not proposing a change to the spec, just illustrating that
> different design choices were possible that avoid the need for delimiters
> or escaping.
>

OK, thanks for helping me understand your thought process.


> While we're on the topic of RRSets and multiple RRTypes, the way that
> AliasMode and ServiceMode are distinguished is also a bit clunky; what are
> the implications of needing to remove all ServiceMode RRs in an RRSet in
> the event that one of them is found to be in AliasMode if we imagine that
> some consumers of these responses will get it wrong?


I think the recipient logic ("if there is an AliasMode record, just use
it") is simple, and not likely to be a source of confusion.  Given that
publishers SHOULD NOT publish mixed-mode RRSets, both sides would have to
be misbehaving for such a bug to be triggered.  If both sides are
noncompliant, presumably the recipient would attempt to connect using one
or more of the ServiceMode records, and succeed if they are usable.  This
doesn't seem problematic to me.  The purpose of this exclusion was mainly
to simplify analysis, avoid inefficient configurations, and maintain
parallelism with CNAME.


> Was there any thought given to an RR schema that prevented such
> ambiguities from being published?
>

This design choice, like many aspects of SVCB, was constrained by latency
and efficiency considerations.  However, note that the ambiguity is
limited: SvcPriority zero sorts to the top, so clients will naturally see
it first.

>  That is not just a variation on SVCB, but an entirely different proposal.
>
> I'm not sure how you think of those two things as different. Isn't every
> variation of something a new something?
>

I think the distinction might be useful as a matter of working group
process.

>>> * It provides a wire format whose structural nesting matches the
> logical scope
> >>>   of each key=value pair, and avoids requiring cross-RR reconstruction
> of
> >>>   bindings by the client.
> >>
> >> This seems like it is documenting a design choice rather than
> explaining it. The decision to include a list of key-value pairs in the
> SVCB RDATA is good because it avoids having to do something different?
> >
> > To restate this sentence, it is good because the concrete syntactical
> structure matches the abstract conceptual structure, and (relatedly)
> because it simplifies client implementation.
>
> What are the concrete syntactical structure and the abstract conceptual
> structures? If those are terms of art I apologise; I'm not familiar with
> them.
>

The concrete wire-format syntax is an octet sequence containing a
TargetName and some SvcParam key-value pairs.

The abstract structure is a "binding" comprising a TargetName and a
key-value map that is associated with that TargetName.

What are you comparing the client implementation to in your final comment?
> What other design option was found to be more complex to implement on the
> client side?
>

I was comparing it to designs where the TargetName and params are separated
into different RRs, or mixed into an RRSet with other bindings.  In such
designs, the client must perform additional work to fetch, associate, or
reconstruct these different components that are encoded or delivered
separately but are only usable as a unit.

I'm sure it feels frustrating to get all these questions at the last
> minute, and I apologise (as I think I said before) that I did not follow
> this work more closely, earlier.
>
>
> Joe
>


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

On Tue, May 11, 2021 at 9:41 AM Dick Franks  wrote:

> All,
>
> As part of a side discussion, I was admonished for my rather flippant
> approach to a significant security issue and failure to explain
> clearly how it manifests itself..
>
> On Sun, 9 May 2021 at 13:01, Dick Franks  wrote:
> >8
> >
> > Pre-processing of '\\,' into the RFC1035 standard '\,' is
> > superficially attractive, but also fraught with danger.
> >
> > A parser could have some fun with this one:
> >
> > $ORIGIN example.com
> > @   SVCB   1 foo
> > key6="\032\001\013\184\000\000\000\000\000\000\000\000,\000"
> > ; a.k.a.   ipv6hint=2001:db8::5c5c:2c00
> >
>
> Although a few sharp-eyed people recognised the security implications
> immediately, I realise that I should have included the broken result
> to illustrate the problem more clearly.
>
>  example.com.INSVCB( \# 38 0001 ; 1
> 03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
> 0006 000f 20010db85c2c00 )
>
> instead of the expected:
>
>  example.com.INSVCB( \# 39 0001 ; 1
> 03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
> 0006 0010 20010db85c5c2c00 )
>
> Observe that the IPv6 address is shortened to 15 octets.
>

I'm not sure what the concern is here, but Section 2.1 of the current draft
[1], which specifies the parsing behavior in this case, simply says that
the value in this form is a char-string.  There is no mention of commas
anywhere in that section, so any special handling of commas is clearly
incorrect.  (Previous versions of the draft have long specified the same
behavior, with only editorial adjustments.)

[1]
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html#name-zone-file-presentation-form


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

On Tue, May 11, 2021 at 9:20 AM Joe Abley  wrote:

> Hi Ben,
>
> On 11 May 2021, at 12:08, Ben Schwartz 
> wrote:
>
..

> * It saves at least 11 bytes of overhead per parameter by avoiding
> repetition of
>   the name, type, class, TTL, and inter-pair binding ID.
>
>
> ... but it inflates response volume in the case where a separate SvcParams
> RRSet is able to be cached significantly longer than the SVCB RRSet.
>

It sounds like you're proposing a design in which the information in one
SVCB record is not just spread across multiple records in an RRSet, but
actually across multiple RRSets.  That is not just a variation on SVCB, but
an entirely different proposal.

> * It provides a wire format whose structural nesting matches the logical
> scope
>   of each key=value pair, and avoids requiring cross-RR reconstruction of
>   bindings by the client.
>
>
> This seems like it is documenting a design choice rather than explaining
> it. The decision to include a list of key-value pairs in the SVCB RDATA is
> good because it avoids having to do something different?
>

To restate this sentence, it is good because the concrete syntactical
structure matches the abstract conceptual structure, and (relatedly)
because it simplifies client implementation.


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

On Thu, May 6, 2021 at 8:50 AM Dick Franks  wrote:

> On Tue, 4 May 2021 at 21:18, Ben Schwartz  wrote:
>
...

> >> For the sanity of all concerned, SVCB should adhere to the same
> >> standard RFC1035 escape conventions as the other 50+ RRTYPEs.
> >
> > I think that's a good description of why this arrangement was chosen.
>
> But that is precisely what you are NOT doing.
> You have assigned a special significance to the character sequence
> "\\," contrary to RFC1035.
>
> The language of RFC1035 is crystal clear that an escaped character is
> parsed as plain text, independently, without regard to context, and
> that any special meaning does not apply.
>
> Strict application of the RFC1035 rules causes string   "...\\,..."
> to be equivalent to "...\092,...".
>

I'm not sure what you're describing.  Those two inputs are universally
equivalent in zone files under the current draft.  They are both reduced to
{'\', '"'} by char-string parsing, which is applied uniformly and without
modification to all SvcParamValues.

Each SvcParamValue has its own input format.  For some SvcParamValues, '\'
and ',' may not be allowed characters.  For others, they may be ordinary
characters to be copied into the output, or they may have special
significance.

BIND, NSD, and Net::DNS are all able to arrive at implementations of
> SVCB using the RFC1035 standard escape conventions, which demonstrates
> beyond reasonable doubt that recognising "\\," is not an essential
> requirement.
>

I disagree: what you are proposing is a deviation from RFC1035 escape
conventions, and what the draft does is specifically to ensure that no such
deviation is required.  I have now encountered multiple codebases where
modifying the RFC1035 char-string parsing in the way that you suggest would
be prohibitively complex, and that complexity will only grow over time as
new SvcParamValues are defined.

The "value-list" format is a bit like a (much simpler) cousin of the SPF
macro language (https://tools.ietf.org/html/rfc7208#section-7.1).  In both
cases, the char-string decoder's output contains embedded commands that
allow the next processing stage to distinguish between delimiters (comma
and space, respectively) and escaped delimiters ("\," and "%_",
respectively).


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

On Tue, May 4, 2021 at 12:09 PM Dick Franks  wrote:

> The brutal reality is that the char-string parser has already
> obliterated the distinction between escaped and unescaped commas
> before the value-list parser is invoked.
>

Yes, hence the use of "\\," for embedded commas in value-list values.


> > If we use single-layer escaping, this arrangement is not possible.
> Instead,
> > (1) we would need to add complexity to the char-string parser that is
> shared by many RR types.
> > (2) we would need to integrate key-type-specific behavior into the
> tokenizer, complicating the interface between the parsing function and the
> SvcParams implementation.
>
> >
> > In the draft's arrangement, those implementation choices are allowed,
> but not required.
>
> By publishing test vectors including escaped escapes effectively makes
> these required,


To be clear, it is the text of the document, not the test vectors, that
creates this requirement.  The test vectors merely complement the normative
requirements, which already detail this arrangement.

...

> For the sanity of all concerned, SVCB should adhere to the same
> standard RFC1035 escape conventions as the other 50+ RRTYPEs.
>

I think that's a good description of why this arrangement was chosen.
Lifting comma-handling up into the char-string parser would result in SVCB
using a _different_ escape convention from all the other RR types.  This
arrangement ensures that, to the extent possible, SVCB uses the _same_
escaping as all the other RR types.  It also ensures that all the SvcParams
use the same basic parser.

Value-list parsing is a detail, not of SVCB, but of certain SvcParam types
within SVCB.  Consider a future SvcParam whose presentation value is
defined to be JSON.  Shall we require that the zone file parser switch to
JSON mode based on the key name, to parse jsonThing={"foo": "quote: \""}?
No, we will declare that this value is wrapped in a char-string as
jsonThing="{\"foo\": \"quote: \\\"\"}".  Yes, this is less convenient to
type by hand, but the alternative is to have a "char-string parser" that
mixes in all the syntaxes of all the SVCB value types.  That way lies
madness.


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

[Ben Schwartz]

Thanks for all the great input during WGLC.  Here's the changelog for the
latest draft:

* Specify interaction with EDNS Client Subnet and Additional section caching
* Rename "echconfig" to "ech"
* Add a suite of test vectors (both valid and invalid) and more examples
* Clarify requirements for resolvers' (non-)use of SvcParams
* Clarify guidance regarding default ALPN values

On Wed, Apr 21, 2021 at 9:51 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title   : Service binding and parameter specification via
> the DNS (DNS SVCB and HTTPS RRs)
> Authors : Ben Schwartz
>   Mike Bishop
>   Erik Nygren
> Filename: draft-ietf-dnsop-svcb-https-05.txt
> Pages   : 56
> Date: 2021-04-21
>
> Abstract:
>This document specifies the "SVCB" and "HTTPS" DNS resource record
>(RR) types to facilitate the lookup of information needed to make
>connections to network services, such as for HTTPS origins.  SVCB
>records allow a service to be provided from multiple alternative
>endpoints, each with associated parameters (such as transport
>protocol configuration and keys for encrypting the TLS ClientHello).
>They also enable aliasing of apex domains, which is not possible with
>CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
>origins.  By providing more information to the client before it
>attempts to establish a connection, these records offer potential
>benefits to both performance and privacy.
>
>TO BE REMOVED: This document is being collaborated on in Github at:
>https://github.com/MikeBishop/dns-alt-svc
>(https://github.com/MikeBishop/dns-alt-svc).  The most recent working
>version of the document, open issues, etc. should all be available
>there.  The authors (gratefully) accept pull requests.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-05
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 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

Re: [DNSOP] ECS and SVCB

[Ben Schwartz]

Thanks to everyone who provided input into the draft text for ECS with SVCB
on Github.  The current proposed text is:

> The EDNS Client Subnet option (ECS, [RFC7871]) allows recursive resolvers
to request IP addresses that are suitable for a particular client IP range.
SVCB records may contain IP addresses (in ipv*hint SvcParams), or direct
users to a subnet-specific TargetName, so recursive resolvers SHOULD
include the same ECS option in SVCB queries as in A/ queries.
>
> According to Section 7.3.1 of [RFC7871], "Any records from [the
Additional section] MUST NOT be tied to a network". Accordingly, resolvers
SHOULD treat any records in the Additional section as having SOURCE
PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified in the ECS option,
and MAY cache them on this basis. Authoritative servers MUST omit such
records if they are not suitable for use by any stub resolvers that set
SOURCE PREFIX-LENGTH to zero. This will cause the resolver to perform a
followup query that can receive properly tailored ECS. (This is similar to
the usage of CNAME with ECS discussed in [RFC7871] Section 7.2.1.)
>
> Authoritative servers that omit Additional records can avoid the added
latency of a followup query by following the advice in Section 10.2.

If anyone would like changes to this text, please let me know.

On Wed, Mar 24, 2021 at 5:19 PM Ben Schwartz  wrote:

> In the course of WGLC for SVCB, a few people have highlighted nontrivial
> interactions between SVCB and EDNS Client Subnet (ECS).  To clear this up,
> the authors are considering [1] adding a section explaining how SVCB and
> ECS should interact, for entities that are trying to do both.
>
> Please review if you have an interest in these topics.
>
> Thanks,
> Ben Schwartz
>
> [1]
> https://github.com/MikeBishop/dns-alt-svc/pull/308/files?short_path=3500257#diff-3500257c8185942fb80e67b6128f73e7807ad42cdbeee3caf923c376e899235f
>


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