Re: [DNSOP] About key tags

[Mark Andrews]

The primary use of the key tag is to select the correct key to validate the 
signature from multiple keys. 

-- 
Mark Andrews

> On 10 Feb 2024, at 12:38, Wellington, Brian 
>  wrote:
> 
> 
> 
>> On Feb 8, 2024, at 6:41 AM, Edward Lewis  wrote:
>> 
>> ...
>> 
>> When DNSSEC was designed, the possibility of tags colliding was known.  The 
>> validation process was defined to expect that a tag might lead to a 
>> non-singleton set of keys.  When it came to key management, and the practice 
>> of storing keys in files named K--.public was 
>> derived, the lone developer of DNSSEC code (at the time) sidestepped the 
>> odds that key tags would collide by deleting the work done when creating a 
>> new key pair if the file to be used already existed.  This side-stepping 
>> practice was never added to a standards document.  (BTW, the reason for the 
>> "K" in the filename was that we developed the protocol using a test root 
>> zone, meaning the  would be ".".  A filename starting with "." is 
>> hidden in the OS systems we used then, so we needed a prefix.)
> 
> This is a mischaracterization of history.
> 
> Yes, dnssec-keygen would regenerate a key upon tag collision.  This seemed 
> like a reasonable thing to do.
> 
> The behavior was never added into any standards document because it has 
> nothing to do with the standard.  The standards documents don’t describe how 
> keys are stored, nor any tooling around their generation.  If an 
> implementation chooses to avoid generating keys which have the same key tag, 
> that is an implementation issue, and doesn’t in any way make it noncompliant 
> with the specification.  There was no reason at the time why allowing for the 
> generation of colliding keys would be useful, and I believe that’s still the 
> case.  The fact that no one’s updated the tools to allow this in almost 25 
> years is probably significant.
> 
> If an implementation doesn’t support multiple keys with the same key tag when 
> validating, that would be noncompliant.  That was not the case, though.
> 
> Brian___
> 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] About key tags

[Wellington, Brian]

> On Feb 8, 2024, at 6:41 AM, Edward Lewis  wrote:
> 
> ...
> 
> When DNSSEC was designed, the possibility of tags colliding was known.  The 
> validation process was defined to expect that a tag might lead to a 
> non-singleton set of keys.  When it came to key management, and the practice 
> of storing keys in files named K--.public was 
> derived, the lone developer of DNSSEC code (at the time) sidestepped the odds 
> that key tags would collide by deleting the work done when creating a new key 
> pair if the file to be used already existed.  This side-stepping practice was 
> never added to a standards document.  (BTW, the reason for the "K" in the 
> filename was that we developed the protocol using a test root zone, meaning 
> the  would be ".".  A filename starting with "." is hidden in the OS 
> systems we used then, so we needed a prefix.)

This is a mischaracterization of history.

Yes, dnssec-keygen would regenerate a key upon tag collision.  This seemed like 
a reasonable thing to do.

The behavior was never added into any standards document because it has nothing 
to do with the standard.  The standards documents don’t describe how keys are 
stored, nor any tooling around their generation.  If an implementation chooses 
to avoid generating keys which have the same key tag, that is an implementation 
issue, and doesn’t in any way make it noncompliant with the specification.  
There was no reason at the time why allowing for the generation of colliding 
keys would be useful, and I believe that’s still the case.  The fact that no 
one’s updated the tools to allow this in almost 25 years is probably 
significant.

If an implementation doesn’t support multiple keys with the same key tag when 
validating, that would be noncompliant.  That was not the case, though.

Brian

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

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

[Philip Homburg]

> One of the misconceptions in DNSSEC is that the zone administrator
> is in control of the situation, dictating the state of signing,
> the cryptography in use, and so on.  DNSSEC is for the benefit of
> the querier, not the responder.  A zone administrator can't force
> a querier to validate the results, it can't dictate what cryptographic
> library support the receiver must have.  

I don't see how this statement is relevant.

The discussion was about possible downgrade attacks if the querier would
fallback to NS/DS.

Given that we are talking about downgrade attacks, there is already the
implicit assumption that the querier is interested in the integrity of the
reply. The zone administrator can assist the queriers with making an
informed decision, if the protocol allows for extra informaiton to be
passed.

> The zone administrator is out there in plain
> sight, anyone can see the data, anyone can see activity.  One can't
> (always) identify the receiver, that's what the privacy-enhancing
> transports support.

With TLS a lot of classical assumptions can change. With emphasis on *can*.
For example, client could use TLS to authenticate themselves, the
transferred data could be kept confidential. People could take DNS in
unexpected directions.

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

[DNSOP] CFP for DINR 2024 virtual workshop, Apr. 4, 2024, for early DNS research

[Wes Hardaker]

We would like to invite you to our upcoming virtual workshop on "DNS and
Internet Naming Research Directions - 2024" (DINR-2024). We will be
holding this workshop virtually over Zoom on Thursday 2024-04-04 from
14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast).

This year, we have a particular focus on privacy and security of the DNS
both now and in the future. For example, how has DNS-over-TLS and HTTPS
or QUIC changed privacy for their users? Or operations for providers?

However, we continue to welcome all DNS-related topics on
infrastructure, tools, and any early DNS and general name space related
work as well as any important updates about previous work.

If you have work in these areas to share, or you want to hear about what
the community is doing, we'd love to have you join us for DINR-2024.

Like previous years, we're planning for a very interactive day of short
talks followed by longer discussions. We are soliciting short abstracts
(suggested 1 page text + 1 page references) from people who are
interested presenting at the workshop. Abstracts are due soon on
2024-03-04, but as a reminder they need not be lengthy. 1-page maximum
contributions are preferred. Co-chairs are John Heidemann and Wes
Hardaker (both at USC/ISI), with Allison Mankin (Salesforce) and Moritz
Müller (SIDN Labs) on the Technical Program Committee. If you wish to
attend but not present, please submit a paragraph stating you wish to
attend only and provide a brief background about your involvement with
the DNS and identification.


For details about DINR2024, see https://ant.isi.edu/events/dinr2024/
. (For information about DINR in prior years, see
https://ant.isi.edu/events/ .)


Please let us know if you're interested, or register your abstract at 
https://ant.isi.edu/dinr2024sub .

-John and Wes on behalf of the DINR2024 TPC

-- 
Wes Hardaker
USC/ISI

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

[DNSOP] IETF 119 Call for Agenda Items DNSOP WG

[Benno Overeinder]

Dear WG,

This is a Call for Agenda Items for the IETF 119 in Brisbane, Australia.

DNSOP has requested two sessions for the IETF 119 so that we have 
sufficient time to discuss individual drafts.  The allocation of two 
sessions is yet to be confirmed and the preliminary IETF119 agenda will 
be published next week, 16 February.


Please email the chairs  with your requests. 
*Or* drop us a pull request 
https://github.com/ietf-wg-dnsop/wg-materials/tree/main/dnsop-ietf119 
look for dnsop-ietf119-agenda-requests.md.


Please Note: Draft Submission Deadline is Monday 3 March 2024.

See https://datatracker.ietf.org/meeting/important-dates/:
2024-03-04	Monday	Internet-Draft submission cut-off (for all 
Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D 
Submission Tool https://datatracker.ietf.org/submit/.


Thanks,

Suzanne
Tim
Benno

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

Re: [DNSOP] New mailing list: DNS Delegation

[Benno Overeinder]

Hi Ólafur,

On 08/02/2024 16:48, Ólafur Guðmundsson wrote:

Quick questions
why a new list and what is that lists standing in the IETF?
Is this  precursor for a BOF and possible new working group ?


For now, the mailing list is a non-WG list on a specific topic.  If 
there is a new WG after the BoF, discussions on DELEG will continue on 
that WG mailing list (given the name of the WG, and where naming has its 
own tradition - which I can actually appreciate).


Starting the non-WG list primarily means having discussions on DELEG in 
the IETF, rather than in other forums, and not overloading the DNSOP 
mailing list.



Best,

-- Benno




On Tue, Feb 6, 2024 at 2:37 PM Paul Hoffman > wrote:


Greetings. After the DNSOP interim meeting last week, Warren set up
a new mailing list. Its description is:

=
There is a desire to have better methods for parent zones in the DNS
to advertise DNS nameserver capabilities and zone features to resolvers.

This list discusses mechanisms to provide this support within the
DNS. This includes the ability to provide more information about a
DNS delegation in record(s) at the parent, as well as additional
capabilities beyond the DNS's current NS-style delegation.  Examples
include aliasing delegation with other domain names, delegating
DNSSEC management to operators, specifying encrypted transports, and
so on.
=

The new mailing list is a good place to discuss both the general
idea of new types of delegation for the DNS, as well as specific
proposals like the DELEG proposal which was first discussed at IETF-118.

The list can be found at https://www.ietf.org/mailman/listinfo/dd


Anyone interested in how delegation might work in the future should
join. Thanks!

___
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


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

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