Re: [DNSOP] IANA Policy for SVCB

[Martin Thomson]

I agree with Tommy.

Selecting an expert who is able to recognize when wider review might help is a 
far lower bar than the one Ray suggests might be necessary.

On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we’ll have missed 
> the mark. The space is designed to be large (65K) to allow new work to 
> easily use this extensibility. We don’t need to be too conservative 
> with this space.
>
> I disagree that there wouldn’t be good experts — we have authors of the 
> document who have seen it through, and we have more people using this 
> RR and gaining expertise.
>
> Expert review is the right balance here.
>
> Tommy
>
>> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy  wrote:
>> 
>> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis  wrote:
>>> I am concerned that the set of Expert Reviewers necessary to handle SVCB 
>>> needs to have both expert DNS experience *and* detailed knowledge of the 
>>> SVCB model for this to work.
>>> 
>>> I am not sure there's anybody who fits that criteria.
>> 
>> Specification Required also assumes a community that can produce them, which 
>> presumably contains the right experts.
>> 
>> Are we actually moving toward IETF Review here?
>> 
>> -MSK
>> ___
>> 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] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt

[Mark Andrews]

> On 23 Mar 2022, at 01:45, Ralf Weber  wrote:
> 
> Moin!
> 
> On 22 Mar 2022, at 14:43, Hugo Salgado wrote:
>> On 14:02 22/03, Ralf Weber wrote:
>>> However missing data might make it impossible for a name server to answer 
>>> with the correct (referral) glue data.
>>> 
>>> And maybe add some encouragement or referral ;-) to work that has to be 
>>> done elsewhere.
>>> 
>> 
>> The problem is with SIBLING glue records. The in-domain glues are of
>> course required and included in the zone.
> No, the problem with missing data is general. The (referral) glue records are 
> required, but it is possible to not supply them and break resolution. I think 
> in general a name server can only serve what it is given. So if you have a 
> zone example.com that has
> 
> sub.example.com. IN NS ns.sub.example.com.
> sub.example.com. IN NS ns.example.org.
> 
> that is valid data even if you check in zone glues (and not all servers check 
> that on load and the ones that do usually just issue a warning). It is very 
> easy to create wrong zone data that will lead to resolution errors, and there 
> is nothing an authoritative name server can do once it has accepted that 
> data. I actually just loaded the above example in Akamai AuthServe, ISC bind 
> and NLNetLabs NSD and all of them loaded it, and I could also load them even 
> without ns.example.org line on all of them.

Well for BIND missing glue on zone load was supposed to be made fatal with the 
BIND 9.5.0 release
See lib/dns/zone.c:zone_check_glue

/* XXX950 make fatal for 9.5.0. */
/* answer = false; */

> So if we say that we don’t put requirements on data or data generators 
> (registries) than we have to spell out that even a server that follows this 
> draft/RFC might not be able to serve answers according to the draft/RFC when 
> the data is not correct.
> 
> So long
> -Ralf
> ——-
> Ralf Weber
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC as a Best Current Practice

[Brian Dickson]

On Tue, Mar 22, 2022 at 7:12 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Paul Wouters wrote:
>
> >> Wrong. DNSSEC as PKI is not cryptographically secure subject to
> >> MitM attacks on CA chains, which is not more difficult than
> >> MitM attacks on ISP chains.
> >
> > I think at this point we have reached a point where your repeated
> > claims lack any merit
>
> So, you ignore diginotar to have demonstrated that PKI to
> blindly trust untrustworthy TTPs is cryptographically
> insecure.
>

This is where your error is introduced. DNSSEC does not involve blind
trust.

Previous statements by you (Ohta-san) in this thread, and observations or
counter-points:

If a resolver correctly knows an IP address of a nameserver of a
> parent zone and the resolver and the nameserver can communicate
> with long enough ID, the resolver can correctly know an IP
> address of a nameserver of a child zone, which is secure enough
> data origin security.
>

The difference between this model (client to server transport security
using IDs) and DNSSEC, is that DNSSEC is resistant to any MITM attacks, so
long as the resolver's root trust anchor is the same as the one published
by ICANN/IANA and used to sign the root zone.

It is correct that the single element is a necessary component of the trust
model for DNSSEC. It is not a dependency within DNSSEC that the endpoint's
connectivity must be transport-secured or impervious to hijack. DNSSEC does
not care where the data lives or how it is retrieved. It protects the data
cryptographically.

 The point is that DNSSEC, or PKI in general, is not cryptographically
> secure merely blindly trusting untrustworthy intermediate systems,
> which means it is against the end to end principle, improperly
> called TTPs (Trusted Third Parties).


I think this is where your argument fails. The trust in DNSSEC is not
blind. The validation which is done by a resolver can be confirmed by an
end-host, along the entire chain (tree) from root to leaf.

In order to achieve complete compromise, the adversary (e.g. state) would
need to compromise every software stack on every host and every resolver,
and block access to every external place that could provide contradictory
results.

Given that the root trust anchor is public, and published on the IANA's web
site with all the appropriate protections, this means anyone can publish
the same information on their own web site, e.g. protected by TLS.

The only way this would not be available to someone under the control of
that adversary, would be the compromise of every CA's cert, or publishing
competing certs for every TLS cert in existence, or to prevent any access
to external sites entirely.

The notion that a state exercising that level of control would also permit
the long-enough ID communication to enable your alternative to function,
does not seem credible.

This devolves down to two possibilities: your method is not viable if the
efforts needed to block use of the Root Trust Anchor are undertaken; or if
the efforts needed to block the Root Trust Anchor are not undertaken (in
their entirety), attempts to replace the Root Trust Anchor are detectable,
which also means the real Root Trust Anchor can be obtained and validated,
and once the latter is done, DNSSEC continues to be cryptographically
secure.

The actual real root trust anchor is not feasible to compromise, nor are
the signing mechanisms involved for signing the root zone. A secured root
zone and root trust anchor makes it impossible to compromise any zone
protected by its parent, with the root zone anchoring those protections.

DNSSEC is not blind trust. The ability to compromise via spoofing requires
compromise of a parent. The root zone cannot feasibly be compromised.
Therefore DNSSEC is secure.

 I concur with the rest of the folks on this thread, this subject thread is
effectively concluded.

This message is mostly for your (Ohta-san's) benefit to understand why
DNSSEC is not in the same category as WebPKI in terms of the trust model
and trust mechanisms.

There is an analogy in infinities:
The rational numbers and real numbers are both infinite, but the infinity
of the real numbers is "uncountable", a larger infinity than the infinity
of the rational numbers, which are "countable".

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

[DNSOP] BCP 235, RFC 9210 on DNS Transport over TCP - Operational Requirements

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.

BCP 235
RFC 9210

Title:  DNS Transport over TCP - 
Operational Requirements 
Author: J. Kristoff,
D. Wessels
Status: Best Current Practice
Stream: IETF
Date:   March 2022
Mailbox:j...@dataplane.org,
dwess...@verisign.com
Pages:  29
Updates:RFC 1123, RFC 1536
See Also:   BCP 235

I-D Tag:draft-ietf-dnsop-dns-tcp-requirements-15.txt

URL:https://www.rfc-editor.org/info/rfc9210

DOI:10.17487/RFC9210

This document updates RFCs 1123 and 1536.  This document requires the
operational practice of permitting DNS messages to be carried over
TCP on the Internet as a Best Current Practice.  This operational
requirement is aligned with the implementation requirements in RFC
7766.  The use of TCP includes both DNS over unencrypted TCP as well
as over an encrypted TLS session.  The document also considers the
consequences of this form of DNS communication and the potential
operational issues that can arise when this Best Current Practice is
not upheld.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

Re: [DNSOP] IANA Policy for SVCB

[Tommy Pauly]

If this space is not extensible from non-IETF RFCs, we’ll have missed the mark. 
The space is designed to be large (65K) to allow new work to easily use this 
extensibility. We don’t need to be too conservative with this space.

I disagree that there wouldn’t be good experts — we have authors of the 
document who have seen it through, and we have more people using this RR and 
gaining expertise.

Expert review is the right balance here.

Tommy

> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy  wrote:
> 
> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis  > wrote:
> I am concerned that the set of Expert Reviewers necessary to handle SVCB 
> needs to have both expert DNS experience *and* detailed knowledge of the 
> SVCB model for this to work.
> 
> I am not sure there's anybody who fits that criteria.
> 
> Specification Required also assumes a community that can produce them, which 
> presumably contains the right experts.
> 
> Are we actually moving toward IETF Review here?
> 
> -MSK
> ___
> 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] IANA Policy for SVCB

[Murray S. Kucherawy]

On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis  wrote:

> I am concerned that the set of Expert Reviewers necessary to handle SVCB
> needs to have both expert DNS experience *and* detailed knowledge of the
> SVCB model for this to work.
>
> I am not sure there's anybody who fits that criteria.
>

Specification Required also assumes a community that can produce them,
which presumably contains the right experts.

Are we actually moving toward IETF Review here?

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

Re: [DNSOP] IANA Policy for SVCB

[Ray Bellis]

On 22/03/2022 16:01, Murray S. Kucherawy wrote:

As to the options proposed, I agree that Expert Review can introduce 
delay, but given the above, so too can Specification Required (maybe 
worse, in aggregate).  So I recommend Expert Review.


I am concerned that the set of Expert Reviewers necessary to handle SVCB 
needs to have both expert DNS experience *and* detailed knowledge of the 
SVCB model for this to work.


I am not sure there's anybody who fits that criteria.

Ray [RRTYPE expert reviewer]

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

Re: [DNSOP] IANA Policy for SVCB

[Murray S. Kucherawy]

On Tue, Mar 22, 2022 at 8:48 AM Martin Thomson  wrote:

> On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> > On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz
> >  wrote:
> >> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
> >
> > Do you have a reference that asserts this?  An I-D that isn't published
> > will expire, which would appear to contradict "permanent and readily
> > available".
>
> There is precedent (TLS docs), but I don't know if there is a reference.
>

Interesting.

In my role as a media type reviewer, for example, it's unlikely I'd accept
an I-D as a stable reference in a registration request except maybe for a
provisional registration.  I could be wrong, but my understanding of the
intent of "Specification Required" is roughly "permanently published,
though not necessarily by the IETF", so I think the bar is a little higher
than just the existence of an I-D.

As to the options proposed, I agree that Expert Review can introduce delay,
but given the above, so too can Specification Required (maybe worse, in
aggregate).  So I recommend Expert Review.

Finally, I just realized my DISCUSS on this document about the IANA
Considerations is redundant to Ben's, so I'm going to go clear it and just
support Ben's.

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

Re: [DNSOP] IANA Policy for SVCB

[Martin Thomson]

On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz 
>  wrote:
>> [...] any individual I-D is considered a qualified specification as soon as 
>> it is uploaded to the Datatracker.
>
> Do you have a reference that asserts this?  An I-D that isn't published 
> will expire, which would appear to contradict "permanent and readily 
> available".

There is precedent (TLS docs), but I don't know if there is a reference.

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

Re: [DNSOP] IANA Policy for SVCB

[Murray S. Kucherawy]

On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz  wrote:

> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
>

Do you have a reference that asserts this?  An I-D that isn't published
will expire, which would appear to contradict "permanent and readily
available".

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt

[Hugo Salgado]

On 15:45 22/03, Ralf Weber wrote:
> Moin!
> 
> On 22 Mar 2022, at 14:43, Hugo Salgado wrote:
> > On 14:02 22/03, Ralf Weber wrote:
> >> However missing data might make it impossible for a name server to answer 
> >> with the correct (referral) glue data.
> >>
> >> And maybe add some encouragement or referral ;-) to work that has to be 
> >> done elsewhere.
> >>
> >
> > The problem is with SIBLING glue records. The in-domain glues are of
> > course required and included in the zone.
> No, the problem with missing data is general. The (referral) glue records are 
> required, but it is possible to not supply them and break resolution. I think 
> in general a name server can only serve what it is given. So if you have a 
> zone example.com that has
> 
> sub.example.com. IN NS ns.sub.example.com.
> sub.example.com. IN NS ns.example.org.
> 

Yes, we agree that a zone must include the essential records for the
resolution to work. What I am trying to say is that records that are
not required, like some kind of siblings, should be optional even at
the zone data level, and of course can't be included in the nameserver
answer requirements. There are some registries that do not have
siblings that are not in-domain of the referred domain. More
information:
  https://mailarchive.ietf.org/arch/msg/dnsop/h0_6iEUIDWb4FyvrpDnDN1BRqBE/

> that is valid data even if you check in zone glues (and not all servers check 
> that on load and the ones that do usually just issue a warning). It is very 
> easy to create wrong zone data that will lead to resolution errors, and there 
> is nothing an authoritative name server can do once it has accepted that 
> data. I actually just loaded the above example in Akamai AuthServe, ISC bind 
> and NLNetLabs NSD and all of them loaded it, and I could also load them even 
> without ns.example.org line on all of them.
> 
> So if we say that we don’t put requirements on data or data generators 
> (registries) than we have to spell out that even a server that follows this 
> draft/RFC might not be able to serve answers according to the draft/RFC when 
> the data is not correct.
> 

Agree.

Hugo

> So long
> -Ralf
> ——-
> Ralf Weber
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice

[Paul Hoffman]

My reading of this thread is that one person thinks that there is a better way 
to achieve what DNSSEC is designed to achieve, and no one else agrees with him. 
Thus, I'll leave the text in the document alone unless I see more support for 
that lone opinion.

--Paul Hoffman

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-glue-is-not-optional-04.txt

[Ralf Weber]

Moin!

On 22 Mar 2022, at 14:43, Hugo Salgado wrote:
> On 14:02 22/03, Ralf Weber wrote:
>> However missing data might make it impossible for a name server to answer 
>> with the correct (referral) glue data.
>>
>> And maybe add some encouragement or referral ;-) to work that has to be done 
>> elsewhere.
>>
>
> The problem is with SIBLING glue records. The in-domain glues are of
> course required and included in the zone.
No, the problem with missing data is general. The (referral) glue records are 
required, but it is possible to not supply them and break resolution. I think 
in general a name server can only serve what it is given. So if you have a zone 
example.com that has

sub.example.com. IN NS ns.sub.example.com.
sub.example.com. IN NS ns.example.org.

that is valid data even if you check in zone glues (and not all servers check 
that on load and the ones that do usually just issue a warning). It is very 
easy to create wrong zone data that will lead to resolution errors, and there 
is nothing an authoritative name server can do once it has accepted that data. 
I actually just loaded the above example in Akamai AuthServe, ISC bind and 
NLNetLabs NSD and all of them loaded it, and I could also load them even 
without ns.example.org line on all of them.

So if we say that we don’t put requirements on data or data generators 
(registries) than we have to spell out that even a server that follows this 
draft/RFC might not be able to serve answers according to the draft/RFC when 
the data is not correct.

So long
-Ralf
——-
Ralf Weber

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Paul Wouters wrote:


Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.


I think at this point we have reached a point where your repeated
claims lack any merit


So, you ignore diginotar to have demonstrated that PKI to
blindly trust untrustworthy TTPs is cryptographically
insecure.

Note again that browsers with some public key information
configured is subject to MitM attacks on software
distribution chains.

Masataka Ohta

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt

[Hugo Salgado]

On 14:02 22/03, Ralf Weber wrote:
> Moin!
> 
> So to follow up on my comment in the working group on registries not having 
> anything to do with it. I understand that this drafts is for authoritative 
> name server implementers, however I think that we should make clear that an 
> authoritative name server not answering correct by this draft might do so 
> because it does not have sufficient data.
> 
> So we currently have in the introduction:
> 
> Note that this document only clarifies requirements of name server
> software implementations.  It does not place any requirements on data
> placed in DNS zones or registries.
> 
> how about adding:
> 
> However missing data might make it impossible for a name server to answer 
> with the correct (referral) glue data.
> 
> And maybe add some encouragement or referral ;-) to work that has to be done 
> elsewhere.
> 

The problem is with SIBLING glue records. The in-domain glues are of
course required and included in the zone.

Hugo



signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt

[Petr Špaček]

On 22. 03. 22 14:02, Ralf Weber wrote:

Moin!

So to follow up on my comment in the working group on registries not having 
anything to do with it. I understand that this drafts is for authoritative name 
server implementers, however I think that we should make clear that an 
authoritative name server not answering correct by this draft might do so 
because it does not have sufficient data.

So we currently have in the introduction:

Note that this document only clarifies requirements of name server
software implementations.  It does not place any requirements on data
placed in DNS zones or registries.

how about adding:

However missing data might make it impossible for a name server to answer with 
the correct (referral) glue data.

And maybe add some encouragement or referral ;-) to work that has to be done 
elsewhere.


Sounds reasonable to me.

--
Petr Špaček

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-04.txt

[Ralf Weber]

Moin!

So to follow up on my comment in the working group on registries not having 
anything to do with it. I understand that this drafts is for authoritative name 
server implementers, however I think that we should make clear that an 
authoritative name server not answering correct by this draft might do so 
because it does not have sufficient data.

So we currently have in the introduction:

Note that this document only clarifies requirements of name server
software implementations.  It does not place any requirements on data
placed in DNS zones or registries.

how about adding:

However missing data might make it impossible for a name server to answer with 
the correct (referral) glue data.

And maybe add some encouragement or referral ;-) to work that has to be done 
elsewhere.

So long
-Ralf
——-
Ralf Weber

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-05.txt

[Petr Špaček]

On 08. 03. 22 15:51, Willem Toorop wrote:

Dear dnsop,

This draft describes a mechanism for automatic provisioning of zones
among authoritative name servers by way of distributing a catalog of
those zones encoded in a regular DNS zone.

This version's focus was getting ready for WGLC.


Filename: draft-ietf-dnsop-dns-catalog-zones-05.txt


FTR during IETF 113 hackaton we have tested basic interoperability of 
NSD, Knot DNS, and the very last work-in-progress version of BIND with 
success: The basic zone de/provisioning worked as specified without 
using any extensions.


BIND currently does not support the optional "group" property a Knot DNS 
and NSD do not support he optional "coo" property, so we did not really 
test these.


--
Petr Špaček

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Tue, 22 Mar 2022, Masataka Ohta wrote:


Partially yes, because DNSSEC is not cryptographically secure.



Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.


I think at this point we have reached a point where your repeated
claims lack any merit and you keep refusing to elaborate so we
cannot further progress on this topic.

Perhaps the chairs can ask you to either substantiate your claims,
or for you to stop making false misleading claims.

Paul

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Joe Abley wrote:


As I wrote "rely on DNS cookie or something like that", an example
is in rfc7873.


Could I perhaps summarise what you're saying as follows?

1. The cost of DNSSEC signing is high, e.g. due to increased
complexity, brittleness of the DNS, perhaps as shown by relatively
low demonstrated system-wide deployment;


No, cost of DNSSEC is high because PKI, in general, is against
the end to end principle, which automatically means that
it is not cryptographically secure, actually because it blindly
depends on untrustworthy TTPs.

If we can be secure by just declaring some third parties not
under control of the first or the second party are trustworhy,
we can just declare that all the third parties of ISPs between
the first and the second, even with BGP route attacks, parties
are trustworthy.


2. The threats that DNSSEC protects against are not high-probability
threats, especially following the adoption of various
resolver-hardening techniques adopted following the late Dan
Kaminsky's various observations;


Partially yes, because DNSSEC is not cryptographically secure.


3. The threats that DNSSEC protects against are not high-impact
either since they affect one layer amongst many for most
applications;


No, MitM attacks on CA chains has as high or low impact as
MitM attacks on ISP chains.


4. Protocols and applications that depend on cryptographic assurances
in the DNS (DNS as PKI)


Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.


5. The cryptographic assurances in DNSSEC


No, there is no such assurances.


6. Better to avoid the cost of DNSSEC deployment


For no security improvement beyond plain DNS with long enough message
IDs? Yes.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Bjorn Mork wrote:


Sorry for being slow, but you'll have to explain a lot more than that if
you want to convince me that DNS cookies and DNSSEC are equivalent
alternatives.


In a sense, they are equivalent, because both plain DNS with
long enough message IDs and DNSSEC are subject to MitM attacks,
naturally with similar difficulties.

The point is that DNSSEC, or PKI in general, is not cryptographically
secure merely blindly trusting untrustworthy intermediate systems,
which means it is against the end to end principle, improperly
called TTPs (Trusted Third Parties).

In another sense, they are not equivalent because attack vectors
are different. MitM attacks can be on ISP chains, CA chains
or software distribution chains. The last example is applicable
to browser or DNSSEC resolver software containing some certificates
or public keys.

> I was asking specifically for your alternative BCP. "Go figure it
> out by yourself with DNS cookie or something like that" just doesn't
> make it.

That's your problem not to able to understand that DNSSEC is *NOT*
cryptographically secure, which I have been pointing out for these
20 years, because it is subject to MitM attacks on CA chains, which
was demonstrated by diginotar about 10 years ago.

Masataka Ohta

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

Re: [DNSOP] [Ext] More private algorithms for DNSSEC

[Mark Andrews]

BIND currently treats 253 as unknown

> On 22 Mar 2022, at 19:56, Nils Wisiol  wrote:
> 
> There was some internal discussion about using 17 vs 253, with the main
> argument for 253 being that this is the intended use case for 253 and
> the main argument for 17 being that worry that some resolver
> implementations could have special treatment for private algorithm
> numbers. As we are interested in how FALCON-512 would behave in the
> existing DNSSEC infrastructure, I pushed for using 17. I have to admit
> though that I did not do research whether there exists special
> treatment for private algorithms.
> 
> To settle this, I would like to ask the resolver vendors on this list:
> is your treatment of private DNSSEC algorithms (253) any different from
> unknown algorithms (such as 17)?
> 
> In any event, we shall make our implementation flexible wrt to the used
> algorithm number(s). The intent was explicitly not to make any claims
> on unused numbers.
> 
> Best,
> Nils
> 
> On Mon, 2022-03-21 at 19:32 +, Paul Hoffman wrote:
>> On Mar 21, 2022, at 11:34 AM, Wessels, Duane <
>> dwessels=40verisign@dmarc.ietf.org> wrote:
>>> Is it in response to the DNS-OARC talk we saw about implementing
>>> PQC Falcon in PowerDNS, and they used the next unused algorithm
>>> number rather than a private algorithm?
>> 
>> Nils could have picked 253 but probably didn't even think of looking
>> down to the bottom of the list. He was just following the time-
>> honored pattern in the IETF. :-)
>> 
>>> If the authors of that work are on this list I would be interested
>>> to hear from them about that decision. In particular, would just
>>> having more private algorithms change their thinking or is
>>> something else needed?
>> 
>> They only needed one. This draft is for experimenters who need many
>> at the same time. NIST has said that they are likely to later
>> standardize on multiple post-quantum signature algorithms which will
>> create larger payloads, and the DNSSEC community will have to decide
>> if it wants just one of those, or many. Having a bit of experimental
>> space for authoritative and recursive developers would be good, given
>> that basically the entire range will be empty for centuries.
>> 
>> --Paul Hoffman
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> -- 
> deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany
> 
> Vorstandsvorsitz: Nils Wisiol
> Registergericht: AG Berlin (Charlottenburg) VR 37525
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Minutes for 113

[Paul Hoffman]

Attached. I thought that the mix of in-person mic and MeetEcho went very well!

--Paul
DNSOP WG
IETF 113, Vienna
2022-03-22
Minutes by Paul Hoffman
Text on slides is not reproduced here
~125 people in MeetEcho

Administrivia
Sent longer note top the mailing list with full status
https://mailarchive.ietf.org/arch/msg/dnsop/jZ2OYzwvGaHLD9caC4a4Q_pXRMk
Warren Kumari: Would really like something in addition
Discussed with the IESG to start up a short WG for 
DNSSEC-as-BCP, weren't interested
Asks WG for a favor to move this to the front of the queue
Adjustments for Multi-signer: Ulrich Wisser
Request to consider changes to RFC 4034 about requiring 
signatures for all algorithms
Wants more discussion on list

Negative Caching of DNS Resolution Failures
draft-dwmtwc-dnsop-caching-resolution-failures, Duane Wessels
Also presented at the DNS-OARC meeting in 2022-02
Paul Wouters: Why is exponential backoff a must?
Duane: Most important is "at least 5 seconds"
 Would be willing to make this mandatory
Ralf Weber: Supports adoption
Lars-Johan Liman: Supports adoption
Hazel Smith: Good idea
What proportion is coming from large public resolvers?
Are these restrictions supposed to be across all anycast 
addresses?
Duane: This is per backend server
Maybe can be more specific in language
Sees thousands of queries per second from each 
backend server
Jim Reid: Strong support
Wants the numbers of seconds to wait to be more evidence-based
Was the bulk from a small number of resolvers?
Duane: Verisign identified some of the sources, 
including the large recursive resolvers (by address)
WG chairs will send out call for adoption soon

DNS Referral Glue Requirements
draft-ietf-dnsop-glue-is-not-optional, Duane Wessels
Ben Schwartz: Terminology is confusing, with conflicting defintions in 
different RFCs
Doesn't think "referral glue" distinction is helpful
Should be from parents uniformly
Duane: But we have sibling glue different than in-domain glue
Important distinction is location
Paul Hoffman: Put definition in the terminology document
Brett Carr: Put it in the terminology doucment
Good for training new staff
Keep the terminology document active
Ralf: All glue is for referral
Not sure if taking out the registry requirement is good
If a registry doesn't need to implement this, we are not 
gaining anything
Duane: Take this to the list
Different registries have different modes of operation, 
didn't want to change their models
"Host object" use
Hazel: Could not find a straight answer whether DS records are glue or 
not
Alexander Mayrhofer: Important to differentiate "registry accepts 
data", "registry puts data in zone", "auth server sends data"
This document focuses on third step
Maybe second step could be in REGEXT WG
Some things will go back to the list

Using Service Bindings with DANE,
draft-rebs-dnsop-svcb-dane, Ben Schwartz
Wes Hardaker: The reason DANE changes the target is about control of 
the certificate
Doesn't want to chase CDN certs, do the least amount of 
management
Ben: Thinks this pushes the furthest in that direction

dry-run DNSSEC
draft-yorgos-dnsop-dry-run-dnssec, Willem Toorop
Gavin Brown: Useful tool
Validate DS algorithms from EPP, check the hash lengths
Can't add dry run, would need an EPP extension
Shane Kerr: Can this help with a root algorithm rollover?
Willem: Useful for any dommain
Ralf: Adding complexity to validation code
Get clients to implement EDE
Should not make resolver more and more complex
Willem: Goal is to give operators more confidence
Ben: This is a recurring paterm (stuff things into DS types)
Should maybe have a general-purpose meta DS type
Would we be better off providing some best practice on how to 
set up a duplicate parallel zone  

Stateful Hash-Based Signatures for DNSSEC
draft-afrvrd-dnsop-stateful-hbs-for-dnssec, Roland van Rijswijk-Deij
Stephen Farrell: "Safe" is not the whole thing
Roland: Must stop with the finite number of signatures
Gavin: How much state needs to be stored, and for how long?
Roland: Which key has been used (sequence number) for the 
lifetime of the key
Have a finite 

Re: [DNSOP] DNSSEC as a Best Current Practice

[Joe Abley]

On Mar 22, 2022, at 10:06, Masataka Ohta  
wrote:

> Bjorn Mork wrote:
> 
>>> Plain DNS with long enough message ID is secure enough.
>> Hello!
>> Can you please point me to the set of RFCs (or draft) which describes
>> this "secure enough" alternative to DNSSEC?
> 
> As I wrote "rely on DNS cookie or something like that",
> an example is in rfc7873.

Could I perhaps summarise what you're saying as follows?

1. The cost of DNSSEC signing is high, e.g. due to increased complexity, 
brittleness of the DNS, perhaps as shown by relatively low demonstrated 
system-wide deployment;

2. The threats that DNSSEC protects against are not high-probability threats, 
especially following the adoption of various resolver-hardening techniques 
adopted following the late Dan Kaminsky's various observations;

3. The threats that DNSSEC protects against are not high-impact either since 
they affect one layer amongst many for most applications;

4. Protocols and applications that depend on cryptographic assurances in the 
DNS (DNS as PKI) are few and far between, e.g. low uptake of DANE for protocols 
other than SMTP;

5. The cryptographic assurances in DNSSEC in any case are not absolute, e.g. 
since they depend on accurate trust anchor maintenance that is subject to 
interference by nation states, mobile device management, manipulation through 
system compromise;

6. Better to avoid the cost of DNSSEC deployment given its low value and focus 
instead on other approaches like cache-hardening or improving transactional 
integrity using cookies. 

Does that come close to what you're getting at?


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

Re: [DNSOP] DNSOPDNSOP Updates, Document Status etc

[Wes Hardaker]

Tim Wicinski  writes:

> draft-ietf-dnsop-nsec3-guidance-06
> 
> Authors are revising in accordance with WG advice– main result has been
> slowly driving the iteration number down.

FYI, there are no outstanding changes to be made to this document based
on the last round of changes.  In general, I believe most people are
happy with it and its ready for LC.

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Bjørn Mork]

Masataka Ohta  writes:

> Bjorn Mork wrote:
>
>>> Plain DNS with long enough message ID is secure enough.
>> Hello!
>> Can you please point me to the set of RFCs (or draft) which
>> describes
>> this "secure enough" alternative to DNSSEC?
>
> As I wrote "rely on DNS cookie or something like that",
> an example is in rfc7873.

Sorry for being slow, but you'll have to explain a lot more than that if
you want to convince me that DNS cookies and DNSSEC are equivalent
alternatives.  But maybe that wasn't your goal here? You're just happy
that you have seen the light and don't care if I understand what it is?

If so, then that's fine.  I don't understand why the announcement was
important though.

I was asking specifically for your alternative BCP.  "Go figure it
out by yourself with DNS cookie or something like that" just doesn't
make it.


Bjørn

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

Re: [DNSOP] IANA Policy for SVCB

[Petr Špaček]

On 21. 03. 22 10:37, Jim Reid wrote:




On 21 Mar 2022, at 09:19, Ben Schwartz  
wrote:

Personally, I favor #3.  What do you think?
  
Ben, I think 2 (Expert Review) is the right approach. This would hopefully ensure any specifications are complete/valid and raise the threshold to discourage bad or frivolous SrvParamValues "registrations".


An Expert Review seems right to me. It's culturally compatible with how we 
handle the allocation of new RRtypes.


+1 for Expert Review for reasons stated by Jim. I don't see #3 as really 
needed.


--
Petr Špaček

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Bjorn Mork wrote:


Plain DNS with long enough message ID is secure enough.


Hello!

Can you please point me to the set of RFCs (or draft) which describes
this "secure enough" alternative to DNSSEC?


As I wrote "rely on DNS cookie or something like that",
an example is in rfc7873.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Bjørn Mork]

Masataka Ohta  writes:

> Plain DNS with long enough message ID is secure enough.

Hello!

Can you please point me to the set of RFCs (or draft) which describes
this "secure enough" alternative to DNSSEC?

I must admit I'm a bit lost wrt precisely what that alternative is since
you haven't given a single reference AFAICS. The whole point of the
draft being discussed here is to define a BCP pointing to the relevant
standards. Please contribute to that.

Thanks.


Bjørn

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

Re: [DNSOP] [Ext] More private algorithms for DNSSEC

[Nils Wisiol]

There was some internal discussion about using 17 vs 253, with the main
argument for 253 being that this is the intended use case for 253 and
the main argument for 17 being that worry that some resolver
implementations could have special treatment for private algorithm
numbers. As we are interested in how FALCON-512 would behave in the
existing DNSSEC infrastructure, I pushed for using 17. I have to admit
though that I did not do research whether there exists special
treatment for private algorithms.

To settle this, I would like to ask the resolver vendors on this list:
is your treatment of private DNSSEC algorithms (253) any different from
unknown algorithms (such as 17)?

In any event, we shall make our implementation flexible wrt to the used
algorithm number(s). The intent was explicitly not to make any claims
on unused numbers.

Best,
Nils

On Mon, 2022-03-21 at 19:32 +, Paul Hoffman wrote:
> On Mar 21, 2022, at 11:34 AM, Wessels, Duane <
> dwessels=40verisign@dmarc.ietf.org> wrote:
> > Is it in response to the DNS-OARC talk we saw about implementing
> > PQC Falcon in PowerDNS, and they used the next unused algorithm
> > number rather than a private algorithm?
> 
> Nils could have picked 253 but probably didn't even think of looking
> down to the bottom of the list. He was just following the time-
> honored pattern in the IETF. :-)
> 
> > If the authors of that work are on this list I would be interested
> > to hear from them about that decision. In particular, would just
> > having more private algorithms change their thinking or is
> > something else needed?
> 
> They only needed one. This draft is for experimenters who need many
> at the same time. NIST has said that they are likely to later
> standardize on multiple post-quantum signature algorithms which will
> create larger payloads, and the DNSSEC community will have to decide
> if it wants just one of those, or many. Having a bit of experimental
> space for authoritative and recursive developers would be good, given
> that basically the entire range will be empty for centuries.
> 
> --Paul Hoffman
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525


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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Brian Dickson wrote:


If a resolver correctly knows an IP address of a nameserver of a
parent zone



The statement is not more demanding for resolvers to be configured
with correct certificates.



I'm presuming you mean "DNSSEC ICANN/IANA Root Trust Anchor", which is a
public key, not a certificate per se.


OK.


I presume you're comparing two models, one using DNSSEC, and one where no
DNSSEC validation is done ever (replaced with TLS,


No, TLS is overkill. Plain DNS with long enough message ID is
secure enough. Though it is vulnerable to active MitM attacks,
where packets are not only spoofed but also dropped, modified
and/or generated, such attacks are as likely/unlikely as
having a fake root trust anchor through social attacks
(including legal order by some government).

As for DoS, IMO, anycast is the only practical protection.

Masataka Ohta

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