Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Mukund Sivaraman wrote:




:  Third, all the CAs, including TLDs, pursuing commercial
:  success have very good appearance using such words as
:  "HSMs" or "four eyes minimum". That is, you can't
:  compare actual operational/physical strength from
:  their formal documents.


This is an anecdote, that a logical reasoned argument.


That's your anecdote to mention "HSMs" or "four eyes minimum"
proven to be useless by diginotar.


(From your posts in this thread, you appear well convinced that
  cryptography is broken due to operational weaknesses in securing access
  to signers. So I don't know if this will convince you differently.)


I'm afraid you miss my point that intermediate zones between
the first and the second parties are the third parties having
no knowledge of required security on transactions between the
first and the second parties.

That DNSSEC is not cryptographically or end-to-end secure
means third parties must be absolutely secure, which is,
as was demonstrated by diginoar, impossible.

OTOH, with the end-to-end security where secret information is
shared directly between the first and the second parties, the
parties know the degree of the required security.


HSMs don't have anything to do with DNSSEC's security guarantee.


If so, feel free to put private keys accesible from general public.


An operational decision
leading to weakness doesn't mean that the cryptographic foundation of
DNSSEC is broken or cannot be secured.


Of course. DNSSEC, certainly, has some components which is
cryptographically secure.

But, as you should know, security of a system depends on the
weakest components of the system.

As such, that some secure components are secure do not
mean the system is secure.


On the topic of leak of private key or access to signers by rogue
parties, there have been experiments to use threshold cryptography
with DNSSEC where the actual private key is not present in any > single form, but 
distributed as "key shares" among N parties, and
"signature shares" are generated separately by M out of N parties

> and combined to make the final signature.

Relying on two or more third parties is no better than relying on
single third party, when all of them are not cryptographically
but physically secure.

As was demonstrated by diginotar, "four eyes minimum" is not
so secure. So are six or more eyes.


Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Mukund Sivaraman]

On Thu, Apr 14, 2022 at 08:55:34PM +0900, Masataka Ohta wrote:
> Paul Wouters wrote:
> 
> > > I can't see any reason why you think the root zone is
> > > more secure than TLDs, especially because, as I wrote:
> > 
> > Because I am informed about their operational procedures and I
> > contributed to the technical design as one of the for the DNS Root Zone
> > Key-Signing-Key of the Root Zone Rollover advisory group.
> 
> So, you mean the root zone is secure because of "operational
> procedures", which is not cryptographic.
> 
> Thank you very much to have confirmed my  point that DNSSEC
> is not cryptographically secure.
> 
> Your point is, surely, conclusive.
> 
> > I was also responsible for the design and implementation of a large TLD
> > fully implementation redundant DNSSEC signer solution.
> 
> So, the root and TLD zones are as secure as diginotar.
> 
> > I talked to a lot of TLD operators at ICANN during my term as the
> > IETF Liason to the ICANN Technical Expert Group.
> 
> I'm sure none of them were aware that PKI is not cryptographically
> secure. So?
> 
> >> :  Third, all the CAs, including TLDs, pursuing commercial
> >> :  success have very good appearance using such words as
> >> :  "HSMs" or "four eyes minimum". That is, you can't
> >> :  compare actual operational/physical strength from
> >> :  their formal documents.
> >
> > This is an anecdote, that a logical reasoned argument.
> 
> That's your anecdote to mention "HSMs" or "four eyes minimum"
> proven to be useless by diginotar.

(From your posts in this thread, you appear well convinced that
 cryptography is broken due to operational weaknesses in securing access
 to signers. So I don't know if this will convince you differently.)

HSMs don't have anything to do with DNSSEC's security guarantee. Use of
HSMs is an implementation/operational detail. An operational decision
leading to weakness doesn't mean that the cryptographic foundation of
DNSSEC is broken or cannot be secured. So it's not entirely correct to
say "DNSSEC is not cryptographically secure."

On the topic of leak of private key or access to signers by rogue
parties, there have been experiments to use threshold cryptography with
DNSSEC where the actual private key is not present in any single form,
but distributed as "key shares" among N parties, and "signature shares"
are generated separately by M out of N parties and combined to make the
final signature. The private key does not exist in one place to be used
by bypassing operational security mechanisms.

E.g., see this implementation by NIC Chile: https://github.com/niclabs/dtc

There has also been a previous C/C++ implementation by them. These
provide a PKCS11 implementation that can be used by existing DNSSEC
signing tools that support the PKCS11 library interface.

They use the RSA threshold signatures mechanism designed by Victor
Shoup, which is compatible to be used for PKCS#1 v1.5 signature
generation as used in the DNSSEC RSA algorithms, i.e., it can be used in
DNSSEC currently within the RSA algorithms.

https://www.shoup.net/papers/thsig.pdf

There are other methods for ECDSA, and some standardization process at
NIST.

The army can be sent to the house of every member of "N eyes minimum"
group to hit on the knuckles repeatedly until either the key cracks or
their knuckles crack. Bribing with carrots also works sometimes.

https://xkcd.com/538/

So this isn't an attempt to convince you that security is relative. :)

Mukund


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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Tim Wicinski]

I sent this earlier today but I failed to do the Reply-All:

---

>From the chairs,

This needs to stop.  Please send suggested text for the document that can
be discussed, otherwise we are requesting you cease

Thanks
Tim




On Thu, Apr 14, 2022 at 10:02 AM Paul Wouters  wrote:

> On Thu, 14 Apr 2022, Masataka Ohta wrote:
>
> >>>  I can't see any reason why you think the root zone is
> >>>  more secure than TLDs, especially because, as I wrote:
> >>
> >>  Because I am informed about their operational procedures and I
> >>  contributed to the technical design as one of the for the DNS Root Zone
> >>  Key-Signing-Key of the Root Zone Rollover advisory group.
> >
> > So, you mean the root zone is secure because of "operational
> > procedures", which is not cryptographic.
>
> No I did not say that at all.
>
> > Thank you very much to have confirmed my  point that DNSSEC
> > is not cryptographically secure.
>
> > Your point is, surely, conclusive.
>
> This twisting of my words has now reached abusive levels, and I hope
> the chairs will now take action.
>
> Paul
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Thu, 14 Apr 2022, Masataka Ohta wrote:


 I can't see any reason why you think the root zone is
 more secure than TLDs, especially because, as I wrote:


 Because I am informed about their operational procedures and I
 contributed to the technical design as one of the for the DNS Root Zone
 Key-Signing-Key of the Root Zone Rollover advisory group.


So, you mean the root zone is secure because of "operational
procedures", which is not cryptographic.


No I did not say that at all.


Thank you very much to have confirmed my  point that DNSSEC
is not cryptographically secure.



Your point is, surely, conclusive.


This twisting of my words has now reached abusive levels, and I hope
the chairs will now take action.

Paul

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[james]

Surely this is at the point of just being trolling right?

-Original Message-
From: DNSOP  On Behalf Of Masataka Ohta
Sent: Thursday, April 14, 2022 12:56 PM
To: Paul Wouters 
Cc: dnsop@ietf.org WG 
Subject: Re: [DNSOP] DNSSEC as a Best Current Practice

Paul Wouters wrote:

>> I can't see any reason why you think the root zone is more secure 
>> than TLDs, especially because, as I wrote:
> 
> Because I am informed about their operational procedures and I 
> contributed to the technical design as one of the for the DNS Root 
> Zone Key-Signing-Key of the Root Zone Rollover advisory group.

So, you mean the root zone is secure because of "operational procedures",
which is not cryptographic.

Thank you very much to have confirmed my  point that DNSSEC is not
cryptographically secure.

Your point is, surely, conclusive.

 > I was also responsible for the design and implementation of a large TLD
> fully implementation redundant DNSSEC signer solution.

So, the root and TLD zones are as secure as diginotar.

 > I talked to a lot of TLD operators at ICANN during my term as the  > IETF
Liason to the ICANN Technical Expert Group.

I'm sure none of them were aware that PKI is not cryptographically secure.
So?

 >> :  Third, all the CAs, including TLDs, pursuing commercial  >> :
success have very good appearance using such words as  >> :  "HSMs" or "four
eyes minimum". That is, you can't  >> :  compare actual operational/physical
strength from  >> :  their formal documents.
 >
 > This is an anecdote, that a logical reasoned argument.

That's your anecdote to mention "HSMs" or "four eyes minimum"
proven to be useless by diginotar.

Masataka Ohta

___
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] DNSSEC as a Best Current Practice

[Masataka Ohta]

Paul Wouters wrote:


I can't see any reason why you think the root zone is
more secure than TLDs, especially because, as I wrote:


Because I am informed about their operational procedures and I
contributed to the technical design as one of the for the DNS Root Zone
Key-Signing-Key of the Root Zone Rollover advisory group.


So, you mean the root zone is secure because of "operational
procedures", which is not cryptographic.

Thank you very much to have confirmed my  point that DNSSEC
is not cryptographically secure.

Your point is, surely, conclusive.

> I was also responsible for the design and implementation of a large TLD
> fully implementation redundant DNSSEC signer solution.

So, the root and TLD zones are as secure as diginotar.

> I talked to a lot of TLD operators at ICANN during my term as the
> IETF Liason to the ICANN Technical Expert Group.

I'm sure none of them were aware that PKI is not cryptographically
secure. So?

>> :  Third, all the CAs, including TLDs, pursuing commercial
>> :  success have very good appearance using such words as
>> :  "HSMs" or "four eyes minimum". That is, you can't
>> :  compare actual operational/physical strength from
>> :  their formal documents.
>
> This is an anecdote, that a logical reasoned argument.

That's your anecdote to mention "HSMs" or "four eyes minimum"
proven to be useless by diginotar.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Mon, 11 Apr 2022, Masataka Ohta wrote:


I can't see any reason why you think the root zone is
more secure than TLDs, especially because, as I wrote:


Because I am informed about their operational procedures and I
contributed to the technical design as one of the for the DNS Root Zone
Key-Signing-Key of the Root Zone Rollover advisory group.

I was also responsible for the design and implementation of a large TLD
fully implementation redundant DNSSEC signer solution.

I talked to a lot of TLD operators at ICANN during my term as the
IETF Liason to the ICANN Technical Expert Group.


:  Third, all the CAs, including TLDs, pursuing commercial
:  success have very good appearance using such words as
:  "HSMs" or "four eyes minimum". That is, you can't
:  compare actual operational/physical strength from
:  their formal documents.


This is an anecdote, that a logical reasoned argument.


:  A false sense of security that DNSSEC were
:  cryptographically secure


This remains factually incorrect, no matter how many times you quote
yourself.


: motivates the operators
:  ignore DNSSEC operation rules, which are very
:  complicated and hard to follow, for relatively
:  strong physical security, which might be what
:  happened in diginotar.


This is hearsay combined with personal opinion that is unsubstantiated
by facts.

As for your other mail to list, it seems we do not in fact have an
ongoing discussion. You keep repeating and quoting yourself as evidence
while people keep telling you they disagree with your quotes.

But to make it abundantly clear this is not a discussion, I shall
refrain from further messages so you cannot  miscatageorize my
correspondence as a "discussion of peers".

Paul

___
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:


In your
favourite terms, diginotar as DNSSEC entity would have only
been able to mess up .nl and not any other TLD, if it had been
a "DNSSEC CA" instead of a "webpki CA". The hierarchical space
offers better security than the flat webpki.


I can't see any reason why you think the root zone is
more secure than TLDs, especially because, as I wrote:

: Third, all the CAs, including TLDs, pursuing commercial
: success have very good appearance using such words as
: "HSMs" or "four eyes minimum". That is, you can't
: compare actual operational/physical strength from
: their formal documents.

and

: A false sense of security that DNSSEC were
: cryptographically secure motivates the operators
: ignore DNSSEC operation rules, which are very
: complicated and hard to follow, for relatively
: strong physical security, which might be what
: happened in diginotar.

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]

Paul Wouters wrote:


First, "CA" is terminology not specific to WebPKI, whatever it
means, but PKI in general including DNS. That is, a DNSSEC TLD is a
CA.



This is incorrect.


First, thank you very much for an evidence that discussion is
still continuing.

Anyway,

https://en.wikipedia.org/wiki/Public_key_infrastructure
In cryptography, a PKI is an arrangement that binds public
keys with respective identities of entities (like people
and organizations). The binding is established through a
process of registration and issuance of certificates at
and by a certificate authority (CA).

Do you still insist that CA is terminology specific to WebPKI
not PKI in general?


In your favourite
terms, diginotar as DNSSEC entity would have only been able to mess
up .nl and not any other TLD,


The fact is that diginotar actually supported government PKI of NL,
which is why the problem is so serious.

As for DNSSEC, we can be sure that national TLDs are not so secure.

You keep conflating operational security with protocol security, and 
insisting protocol security is not needed because operational

security is always the weaker link.


Your previous statement:

: At the TLD level
: and higher, this involves HSMs and physical access restrictions
: using a "four eyes minimum" approach.

is an evidence that operational security is required because
DNSSEC is not secure merely by protocol security.

I don't deny DNSSEC has some protocol security, but the
problem is that it is not complete and useless without
operational security.

But you are not offering any alternative ("larger plaintext cookies" 
is not a security protocol)


Cookies and DNSSEC, subject to active MitM attacks, are
equally secure.


So please tell me why you use TLS at all? Why not force your browser > into 
only using port 80? You can also use extra long HTTP header
cookies.


With compromised intermediate CAs and ISPs, TLS and plain http with
long enough cookies are equally secure against active MitM attacks.

The difference is that, unlike cookies, TLS is safe against passive
MitM attacks of packet snooping.

So?

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Fri, 8 Apr 2022, Masataka Ohta wrote:


First, "CA" is terminology not specific to WebPKI, whatever
it means, but PKI in general including DNS. That is, a DNSSEC
TLD is a CA.


This is incorrect. Or rather, it is equivalent to a CA with a
very strict path constraint of being within the TLD. In your
favourite terms, diginotar as DNSSEC entity would have only
been able to mess up .nl and not any other TLD, if it had been
a "DNSSEC CA" instead of a "webpki CA". The hierarchical space
offers better security than the flat webpki.


Second "any CA which is weaker than some TLD" means not
"cryptographically weaker" but "operationally/physically
weaker". As such, your conclusion can only be "DNSSEC is
more operationally/physically secure than WebPKI"


You keep conflating operational security with protocol security, and
insisting protocol security is not needed because operational security
is always the weaker link.

But you are not offering any alternative ("larger plaintext cookies"
is not a security protocol) and therefor imply we should abandon every
cryptographic protocol in the name of "false security".

So please tell me why you use TLS at all? Why not force your browser
into only using port 80? You can also use extra long HTTP header
cookies.

Paul

___
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:


Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?



I'm not sure why "thinks" enters into the conversation.


You may replace it with "dreams".


The facts are what matters here:


The important facts are that:

DNSSEC is not cryptographically secure.

DNSSEC "at the TLD level and higher", which
include root zone, is only as trustworthy
as diginotar.


Taken together, this means that as long as there exists any CA which
is weaker than some TLD, that automatically means that as a global
system, DNSSEC is more cryptographically secure than WebPKI.

First, "CA" is terminology not specific to WebPKI, whatever
it means, but PKI in general including DNS. That is, a DNSSEC
TLD is a CA.

Second "any CA which is weaker than some TLD" means not
"cryptographically weaker" but "operationally/physically
weaker". As such, your conclusion can only be "DNSSEC is
more operationally/physically secure than WebPKI"

Third, all the CAs, including TLDs, pursuing commercial
success have very good appearance using such words as
"HSMs" or "four eyes minimum". That is, you can't
compare actual operational/physical strength from
their formal documents.

Remember:


At the TLD level and higher, this involves HSMs and physical
access restrictions using a "four eyes minimum" approach. > Not surprisingly, 
diginotar was equally strongly secure.


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:


Are there anyone who still think, with reasons, DNSSEC were
cryptographically secure or had protected TLDs more securely
than diginotar?


Does DNSSEC make the TLD operators less trustworthy in your eyes?


Good point.

A false sense of security that DNSSEC were
cryptographically secure motivates the operators
ignore DNSSEC operation rules, which are very
complicated and hard to follow, for relatively
strong physical security, which might be what
happened in diginotar.

With proper recognition that DNSSEC is not cryptographically
secure, operators won't violate rules for physical security
of DNSSEC and, instead, stop operating DNSSEC.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Brian Dickson]

On Thu, Apr 7, 2022 at 5:45 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> As I wrote:
>
> >> Such an individual would have to get access, create the records, give
> >> them to others, who then have to on-path attack you. At the TLD level
> >> and higher, this involves HSMs and physical access restrictions using
> >> a “four eyes minimum” approach.
>
> > Not surprisingly, diginotar was equally strongly secure.
>
> Are there anyone who still think DNSSEC were cryptographically secure
> or had protected TLDs more securely than diginotar?
>

I'm not sure why "thinks" enters into the conversation.

Nobody is entitled to their own facts, only their own opinions.

The facts are what matters here:

   - Each TLD has its own specific infrastructure, practices, etc.
  - Not all TLDs are equivalent for purposes of comparison of relative
  security (to each other or when compared to corresponding CA
infrastructure
  and practices)
   - Each TLD is a monopoly for the purposes of DNSSEC. The TLD operator
   has exclusive control over the delegations (including DNSSEC components) to
   registrants.
   - Registrants choose the TLD to use when they register a domain
   - Modulo the restrictions applicable to specific TLDs, the available
   choices of TLD are substantial
   - Each CA (including diginotar) is not a monopoly. Any CA can issue a
   certificate for any domain name.
   - Each CA has its own specific infrastructure, practices, etc.
  - Not all CAs are equivalent for purposes of comparison of relative
  security (to each other or when compared to corresponding TLD
  infrastructure and practices)

Taking these facts into consideration, the following assertions are clear
consequences:

   - Some CAs MAY have stronger infrastructure and practices than some TLDs
   - Some TLDs MAY have stronger infrastructure and practices than some CAs
   - It MAY be the case that some TLDs have infrastructure and practices
   that are not exceeded by those of any CA
  - Rephrased: some TLDs >= all CAs (which includes the boundary
  condition of "some TLDS == some CAs" without explicitly claiming that set
  is non-empty)
   - An attacker who wishes to compromise a domain via a WebPKI
   certificate, can choose which CA to use for this purpose
   - An attacker who wishes to compromise a domain via DNSSEC delegation,
   cannot choose which TLD to use for this purpose

Taken together, this means that as long as there exists any CA which is
weaker than some TLD, that automatically means that as a global system,
DNSSEC is more cryptographically secure than WebPKI.
And, given the facts regarding diginotar, this means that as a system,
DNSSEC is more cryptographically secure than diginotar.

QED

Registrants get to choose the TLD. Once that decision has been made, the
attacker has no alternatives to that TLD in terms of what would need to be
compromised to affect that specific domain.
The same is not true of CAs. Any CA being compromised places every domain
(regardless of TLD) in jeopardy, if the only protections on certificates
are those currently employed (e.g. CT, CRLs, OCSP).
If/when DANE (TLSA records) are used to improve certificate validation, the
choice of CA for the attacker to compromise is removed from the equation.

Brian
___
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:

> Are there anyone who still think, with reasons, DNSSEC were
> cryptographically secure or had protected TLDs more securely
> than diginotar?

Does DNSSEC make the TLD operators less trustworthy in your eyes?


Bjørn

___
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:


Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?


Yes, everyone but you who participated in this thread.


That's simply wrong.

Are there anyone who still think, with reasons, DNSSEC were
cryptographically secure or had protected TLDs more securely
than diginotar?

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Thu, 7 Apr 2022, Masataka Ohta wrote:


As I wrote:


 Such an individual would have to get access, create the records, give
 them to others, who then have to on-path attack you. At the TLD level
 and higher, this involves HSMs and physical access restrictions using
 a “four eyes minimum” approach.



 Not surprisingly, diginotar was equally strongly secure.


Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?


Yes, everyone but you who participated in this thread.

Paul

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

As I wrote:


Such an individual would have to get access, create the records, give
them to others, who then have to on-path attack you. At the TLD level
and higher, this involves HSMs and physical access restrictions using
a “four eyes minimum” approach.



Not surprisingly, diginotar was equally strongly secure.


Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?

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]

Paul Vixie wrote:

If some CA between you and your peer is compromised, communication 
between you and your peer is compromized.


About 10 years ago, diginotar demonstrated that attack on 
intermediate CAs possible.


i consider that your arguments about PKI CAs apply to DNSSEC in the
form of static and dynamic trust anchors, those being the root key,
and the set of DS RRsets in a validation chain. it is always the case
that if a CA is compromised then security is compromised


An important question is how the CA is protected. Physically or
cryptographically? As the CA is not cryptographically
protected, DNSSEC is not cryptographically secure.


i think the specific reliance on physical security is irrelevant.


But it is relied by DNSSEC, which is why not me but Paul Wouters
wrote:

: At the TLD level
: and higher, this involves HSMs and physical access restrictions
: using a "four eyes minimum" approach.


i
know of secure digital vaults, and i know of insecure physical
vaults.


You don't have to use metaphor of vaults because
diginotar successfully demonstrated that a CA
with physical security by

   HSMs and physical access restrictions
   using a "four eyes minimum" approach.

can be compromised.


i think there are two assumptions in the DNSSEC design which go to
your assertion of meaninglessness. first, birthday attacks of the
kind you describe are essentially hop by hop (transactional), and any
defense against only hop by hop attacks will necessarily leave open
data integrity vulnerabilities in the end to end data path.


"hop by hop (transactional)"??? Do you mean "transaction
by transaction"? Or, do you mean hops over routers,
which is not "transactional" at all.


for
example, if we had larger message IDs we would still be vulnerable to
data modification attacks by RDNS operators, or by BGP injections


They are not "birthday attacks". DNS is subject to MitM attacks
on ISP chain, CA chain and software distribution chain.


which change the identity of an IP address. therefore pure hop by hop
security features were out of scope for the DNSSEC effort.


I'm afraid DNSSEC prevents MitM attacks on ISP chain.


second, a general and effective prohibition against end to end
attacks can be made proof against hop by hop attacks also.


I'm afraid there is no such thing as "end to end attacks".

>  however, "security theater" is not an unalloyed failure:
>
> https://healthguardsecurity.com/bruce-schneier-ted/
> 
https://www.cnet.com/culture/bruce-schneiers-new-view-on-security-theater/


You should just say "diginotar".

>  accordingly, DNSSEC admits to the inevitability of "security
> theater" but considers it, along with the inevitability of compromise
> in any PKI CA system, to be design inputs and not design constraints.
> more "below".

No PKI is cryptographically secure. So?

>> So, let's recognize that DNSSEC is not cryptographically secure not
>> worth its so high cost and move on to make DNS with longer message
>> IDs even though DNS must, with or without DNSSEC, be subject to
>> various MitM attacks.
>
> this proposal is out of scope for the reasons described above.

Certainly, the proposal to obsolete DNSSEC is out of scope for
DNSSEC. So?

>> Which of my points, if any, are you saying, can not be understood
>> by you not so clealy?
>
> we (you and i) have discussed this on the record several times in the
>  last 25 years, and i think i have always understood your concerns.
> in fact i share your concerns, but not your conclusions.

Thanks.

>> DNSSEC's focus is on end to end data integrity,

Note that "end to end data integrity" is applied on ends of
not only ISP but also CA and software distribution chains.

> DNSSEC expects PKI CA
> compromise but makes such compromises transparent and observable.

No, as I wrote to Ted Lemon:

: If a parent zone administrator or some employee of it is
: compromised and forged zone delegation (with an IP address
: of a forged nameserver using forged public/secret keys)
: is signed by a valid key, it will not be noticed easily.

> RFC
> 3833 should clarify any misunderstandings as to DNSSEC's intent and
> utility.

It was before diginotar. At that time most people did not think
PKI cryptographically insecure.

> "below":
>
> i think your primary argument is that DNSSEC solves the wrong
> problem,

No, my primary argument is that DNSSEC is not cryptographically
secure. It prevent MitM attacks on ISP chain but not on CA chain.

> and the best formulation of that concern that i have seen is
> here:
>
> https://sockpuppet.org/blog/2015/01/15/against-dnssec/

In it, I can't find a concern that CAs can be compromised.

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]

I wrote:


Ohta-san is using the term MiTM in an unusual way.


Wrong. See, for example,

 https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
 More facts have recently come to light about the compromise
 of the DigiNotar Certificate Authority, which appears to have
 enabled Iranian hackers to launch successful man-in-the-middle
 attacks against hundreds of thousands of Internet users inside
 and outside of Iran.


Sorry, this is not a good reference because it mentions MitM attack
on ISP chain is enabled by diginotar.

A proper reference is:


https://www.thesslstore.com/knowledgebase/ssl-support/explaining-the-chain-of-trust/
Intermediate Certificate – Intermediate certificates branch
off of root certificates like branches off of trees. They
act as middle-men between the protected root certificates
   ^^
and the server certificates issued out to the public.
^^^

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Vixie]

(sunday long read, beware.)

Masataka Ohta wrote on 2022-03-27 06:24:

Dr Eberhard W Lisse wrote:


I am also struggling finding your point.


...


i am not eberhard, but:


If some CA between you and your peer is compromised, communication
between you and your peer is compromized.

About 10 years ago, diginotar demonstrated that attack on
intermediate CAs possible.


i consider that your arguments about PKI CAs apply to DNSSEC in the form 
of static and dynamic trust anchors, those being the root key, and the 
set of DS RRsets in a validation chain. it is always the case that if a 
CA is compromised then security is compromised -- this is axiomatic. in 
DNSSEC, with CA PKI interpreted as "the root key and every DS RRset", it 
is a large attack surface, larger even than in X.509. but if any PKI 
having a CA is insecure, then we must reason within that context. more 
"below".



Another evidence for my point is that, DNSSEC assumes actually-not-
so-strong but too costly physical security of intermediate zones,
which means DNSSEC relies on too costly physical security of
intermediate zone and is not cryptographically secure.


i think the specific reliance on physical security is irrelevant. i know 
of secure digital vaults, and i know of insecure physical vaults. we can 
reason about the vulnerability of a PKI CA (which in DNSSEC takes the 
form of the root key and all DS RRsets) without specificity as to cause. 
more "below".



...

It is true that plain DNS is not so secure because birthday
attacks from anyone, not necessarily MitM, can be successful
because of too short (16bits) message IDs.

However, that DNSSEC is not cryptographically secure subject
to MitM attacks means operating costly DNSSEC only to keep
it subject to MitM attacks is not only meaningless but also
harmful to let society give false sense of security as if
DNSSEC were cryptographically secure.


i think there are two assumptions in the DNSSEC design which go to your 
assertion of meaninglessness. first, birthday attacks of the kind you 
describe are essentially hop by hop (transactional), and any defense 
against only hop by hop attacks will necessarily leave open data 
integrity vulnerabilities in the end to end data path. for example, if 
we had larger message IDs we would still be vulnerable to data 
modification attacks by RDNS operators, or by BGP injections which 
change the identity of an IP address. therefore pure hop by hop security 
features were out of scope for the DNSSEC effort.


second, a general and effective prohibition against end to end attacks 
can be made proof against hop by hop attacks also. DNSSEC attempts this. 
only by data compromise against the PKI CA (which for DNSSEC means the 
root key and any DS RRsets needed for a particular validation) can false 
data be injected by a "hop" in the hop by hop system without detection. 
since this is possible, it should be noted, and caution be exercised. 
this caution includes transparency by each CA operator (the root, and 
every DS RRset owner) as to the methods of generating and using secret 
keys associated with a CA element. this is often "security theater" as 
originally defined by bruce schneier:


https://www.schneier.com/essays/archives/2009/11/beyond_security_thea.html

however, "security theater" is not an unalloyed failure:

https://healthguardsecurity.com/bruce-schneier-ted/
https://www.cnet.com/culture/bruce-schneiers-new-view-on-security-theater/

accordingly, DNSSEC admits to the inevitability of "security theater" 
but considers it, along with the inevitability of compromise in any PKI 
CA system, to be design inputs and not design constraints. more "below".



So, let's recognize that DNSSEC is not cryptographically
secure not worth its so high cost and move on to make
DNS with longer message IDs even though DNS must, with
or without DNSSEC, be subject to various MitM attacks.


this proposal is out of scope for the reasons described above.


Which of my points, if any, are you saying, can not be
understood by you not so clealy?


we (you and i) have discussed this on the record several times in the 
last 25 years, and i think i have always understood your concerns. in 
fact i share your concerns, but not your conclusions.


DNSSEC's focus is on end to end data integrity, and handles hop by hop 
data integrity issues by side effect. DNSSEC expects PKI CA compromise 
but makes such compromises transparent and observable. RFC 3833 should 
clarify any misunderstandings as to DNSSEC's intent and utility.


the impact of DNSSEC on relying parties is paramount. DNSSEC makes DNS 
more fragile, signaling failure in both attack scenarios and the more 
common operational error scenarios (wrong keys, expired signatures, and 
so forth). this fragility is another inevitability, another design 
input. no system of this kind will avoid rampant false negatives.


---

"below":

i think your primary argument is that DNSSEC solves the wrong problem, 
and the best 

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Ted Lemon wrote:


Ohta-san is using the term MiTM in an unusual way.


Wrong. See, for example,


https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
More facts have recently come to light about the compromise
of the DigiNotar Certificate Authority, which appears to have
enabled Iranian hackers to launch successful man-in-the-middle
attacks against hundreds of thousands of Internet users inside
and outside of Iran.

There are a lot of other examples. For example, both plain DNS and
DNSSEC are subject to MitM attacks on software distribution chain
to forge root zone information of IP addresses of root servers
or public key of the root zone.


Normally we mean an on-path attack.


Exactly, MitM attack means on-path attack on some chain including
but not limitedvto ISP chain. So?


Ohta-san is talking about attacks on root and intermediate
zone keys


That is, well known MitM attack, in this case, on zone/CA chain.


using the term "man-in-the-middle," that's all.


Your denial of the term of MitM can not deny a fact that PKI
including DNSSEC is not cryptographically secure, diseparate
attempt against which is to make intermediate intelligent
entities of CAs physically secure, which was demonstrated
by diginotar not secure at all.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Ted Lemon]

Ohta-san is using the term MiTM in an unusual way. Normally we mean an
on-path attack. Ohta-san is talking about attacks on root and intermediate
zone keys using the term "man-in-the-middle," that's all. It's true as far
as it goes, but doesn't support the conclusion he's reaching.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Dr Eberhard W Lisse wrote:

>> Which of my points, if any, are you saying, can not be
>> understood by you not so clealy?


Every single one, actually.


I understand that you don't understand, at all, DNSSEC
almost all details of which to make DNS and PKI precisely
match are of my design, through which I puzzled by
too complicated operational practices of PKI.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Dr Eberhard W Lisse]

Every single one, actually.

el

—
Sent from Dr Lisse’s iPhone/iPad
On 27. Mar 2022, 15:25 +0200, Masataka Ohta , 
wrote:
> […]
>
> Which of my points, if any, are you saying, can not be
> understood by you not so clealy?
>
> 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]

Dr Eberhard W Lisse wrote:


I am also struggling finding your point.


More than 20 years ago, I noticed that PKI, including DNSSEC is, not
at all, cryptographically secure subject to MitM attacks on CA or
zone chain, whichI pointed it out for every several years in this ML.

Initially, I was puzzled why PKI is operationally so complicated
with a lot of parameters without any theory to properly determine
proper values for the parameters, which turned out to be that
there can not be any proper values for the parameters because
PKI is not cryptographically secure.

If some CA between you and your peer is compromised, communication
between you and your peer is compromized.

About 10 years ago, diginotar demonstrated that attack on
intermediate CAs possible.

Another evidence for my point is that, DNSSEC assumes actually-not-
so-strong but too costly physical security of intermediate zones,
which means DNSSEC relies on too costly physical security of
intermediate zone and is not cryptographically secure.

Diginotar also demonstrated that costly physical security similar
to DNSSEC TLDs can be compromised and is not secure at all.

It is true that plain DNS is not so secure because birthday
attacks from anyone, not necessarily MitM, can be successful
because of too short (16bits) message IDs.

However, that DNSSEC is not cryptographically secure subject
to MitM attacks means operating costly DNSSEC only to keep
it subject to MitM attacks is not only meaningless but also
harmful to let society give false sense of security as if
DNSSEC were cryptographically secure.

So, let's recognize that DNSSEC is not cryptographically
secure not worth its so high cost and move on to make
DNS with longer message IDs even though DNS must, with
or without DNSSEC, be subject to various MitM attacks.

Which of my points, if any, are you saying, can not be
understood by you not so clealy?

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Dr Eberhard W Lisse]

I am also struggling finding your point.

el

—
Sent from Dr Lisse’s iPhone/iPad
On 24. Mar 2022, 11:56 +0100, Masataka Ohta , 
wrote:
> […]
>
> I'm afraid you completely miss my point.
>
> Masataka Ohta
>
> ___
> 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] DNSSEC as a Best Current Practice

[Masataka Ohta]

Paul Wouters wrote:

 If a parent zone administrator or some employee of it is 
compromised and forged zone delegation (with an IP address of a

forged nameserver using forged public/secret keys) is signed by a
valid key, it will not be noticed easily.



Such an individual would have to get access, create the records, give
them to others, who then have to on-path attack you. At the TLD level
and higher, this involves HSMs and physical access restrictions using
a “four eyes minimum” approach.


First, such impressively strong in depth security as strong
as those for nuclear reactors at Fukushima demonstrates a
fact that PKI is not cryptographically secure.

Not surprisingly, diginotar was equally strongly secure.

https://roselabs.nl/files/audit_reports/Fox-IT_-_DigiNotar.pdf

The main production servers of DigiNotar, including the
CA servers and the accompanying hardware security module
(netHSM), were located in a physically highlysecured
room and in the Secure-net network segment.

When a request was approved using the four-eye principle,

In order for the CA software to automatically sign the
certificate request, the appropriate private key
needed to be activated in the netHSM. This was done
by authorized employees by entering a smartcard
into the netHSM combined with a PIN code.

So, DNSSEC TLDs are as secure as diginotar.


At this point, it is easier to obtain physical access to the enduser
device and compromise the OS, browser or webpki stack - DNS attack is
not needed.


According to your theory, diginotar should not have been attacked.

It's like guaranteeing nuclear reactors protected by in depth
security never meltdown, proven by so many experts.

But, real security experts including bad guys are not hyped
by mere impression of security, which is merely not very
strong obscurity, which caused meltdown of diginotar.

So, may I volunteer to write a WG ID to obsolete DNSSEC
because it is only as secure as diginotar?


Merely because message ID is short, which can be improved, which is
a lot easier than deploying so costly DNSSEC.


You did not answer my earlier question on how you obtain this alleged
secure IP address of all DNS nameservers you plan to talk to with
"extra strong message ID".


I can't understand your question because upgrading all the
nameservers and resolvers operated by security aware
operators longer message ID capable is not so difficult.

> Note also the same employee from above can tcpdump their nameserver
> or read the RAM and give the extra strong message ID to the attacker.
> So all attacks you attribute to DNSSEC apply to msg ID too.

So, just accept the reality that DNS, relying on zone chain,
which is subject to MitM attacks on intermediate zones, can not
be so secure regardless of whether you use DNSSEC or not.


If a resolver has some knowledge on contents of an attacked zone,
such as IP addresses of some servers or some DNSSEC keys, it can
detect a DNS (both resolver and DNSSEC) attack by comparing,
unless an attacker knows IP addresses of detecting resolvers and 
return unforged answers to them. So?


Forged answers require access to a private key. As stated those tend
to be in HSMs or offline, 


HSMs? See above.


so "attacker knowing IP address" is
insufficient to forge answers.


I'm afraid you completely miss my point.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Mar 23, 2022, at 13:56, Masataka Ohta  
wrote:
> 
> 
> If a parent zone administrator or some employee of it is
> compromised and forged zone delegation (with an IP address
> of a forged nameserver using forged public/secret keys)
> is signed by a valid key, it will not be noticed easily.

Such an individual would have to get access, create the records, give them to 
others, who then have to on-path attack you. At the TLD level and higher, this 
involves HSMs and physical access restrictions using a “four eyes minimum” 
approach.

At this point, it is easier to obtain physical access to the enduser device and 
compromise the OS, browser or webpki stack - DNS attack is not needed.

Even cheaper at this point is to use a hammer on the user’s knee cap.

>> So the threat model for a viable  DNSSEC attack is quite a bit different
>> than for a recursive resolver attack, and is not something that could be
>> easily effected by a small entity.
> 
> Merely because message ID is short, which can be improved,
> which is a lot easier than deploying so costly DNSSEC.

You did not answer my earlier question on how you obtain this alleged secure IP 
address of all DNS nameservers you plan to talk to with “extra strong message 
ID”. 

Note also the same employee from above can tcpdump their nameserver or read the 
RAM and give the extra strong message ID to the attacker. So all attacks you 
attribute to DNSSEC apply to msg ID too.

> If a resolver has some knowledge on contents of an attacked zone, such
> as IP addresses of some servers or some DNSSEC keys, it can detect
> a DNS (both resolver and DNSSEC) attack by comparing, unless
> an attacker knows IP addresses of detecting resolvers and
> return unforged answers to them. So?

Forged answers require access to a private key. As stated those tend to be in 
HSMs or offline, so “attacker knowing IP address” is insufficient to forge 
answers. Your previous reply to his has been “there is always a human you can 
buy that has access to the key”, at which case see the above hammer and knee 
cap discussion.

> Unlike that, birthday attacks on resolvers are trivially detectable
> by the resolvers.

In your described world, a birthday attack would not be needed, as the 
compromised operator that would have DNSSEC key access can also just share the 
msg ID with the attacker. So the attacker uses one regular response that you 
cannot distinguish from an unforged response. In a world with your own 
parameters, your solution would equally have no chance.

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Ted Lemon wrote:


Brian, what you said about the crypto is right but there are definitely
opportunities to compromise trust at the tlds. I don't think it's wise to
ignore this type of attack. However, in order to make such an attack, you
have to do things which can be noticed (e.g. signing a zone delegation with
a forged key).


If a parent zone administrator or some employee of it is
compromised and forged zone delegation (with an IP address
of a forged nameserver using forged public/secret keys)
is signed by a valid key, it will not be noticed easily.


So the threat model for a viable  DNSSEC attack is quite a bit different
than for a recursive resolver attack, and is not something that could be
easily effected by a small entity.


Merely because message ID is short, which can be improved,
which is a lot easier than deploying so costly DNSSEC.

> And unlike
> a resolver attack, it is possible to detect a DNSSEC attack by
> comparing known keys to detect a compromise.

If a resolver has some knowledge on contents of an attacked zone, such
as IP addresses of some servers or some DNSSEC keys, it can detect
a DNS (both resolver and DNSSEC) attack by comparing, unless
an attacker knows IP addresses of detecting resolvers and
return unforged answers to them. So?

Unlike that, birthday attacks on resolvers are trivially detectable
by the resolvers.

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]

Brian Dickson wrote:


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.


Wrong.

If a TLD with its key signed by the root is compromised, which
is a MitM attack, child zones under the TLD are easy victim
of the attack.

Or, if your theory is that we can blindly trust any entity
blessed by ICANN/IANA through some chain as an trustworthy
TTP, then, according to your theory, we can blindly trust
all the ISPs as trustworthy TTPs, because they are blessed
by ICANN/IANA through RIRs, which means there can be no MitM
attacks on ISP chains.

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

You are totally confused, because I never assumed any compromised
resolver.

> The validation which is done by a resolver can be
> confirmed by an end-host, along the entire chain (tree) from root to
> leaf.

"The validation which is done by a resolver" is not compromised.

I merely mean MitM attacks on some part of the zone chain is
effective both to the resolver and the end-host.


Masataka Ohta




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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Ted Lemon]

Brian, what you said about the crypto is right but there are definitely
opportunities to compromise trust at the tlds. I don’t think it’s wise to
ignore this type of attack. However, in order to make such an attack, you
have to do things which can be noticed (e.g. signing a zone delegation with
a forged key).

So the threat model for a viable  DNSSEC attack is quite a bit different
than for a recursive resolver attack, and is not something that could be
easily effected by a small entity.

Or to put it differently, the cost of a successful attack on DNSSEC would
be orders of magnitude higher than for an attack on a resolver. And unlike
a resolver attack, it is possible to detect a DNSSEC attack by comparing
known keys to detect a compromise. With a resolver attack, you have no way
to know that you’ve been spoofed.

On Tue, Mar 22, 2022 at 22:12 Brian Dickson 
wrote:

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

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

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Brian Dickson]

On Mon, Mar 21, 2022 at 5:28 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Paul Wouters wrote:
>
> >> If a resolver correctly knows an IP address of a nameserver of a
> >> parent zone
> >
> > This statement seems a recursion of the original problem statement?]
>
> What?
>
> 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.

I presume you're comparing two models, one using DNSSEC, and one where no
DNSSEC validation is done ever (replaced with TLS, either DNS over TLS to
Authority, or DNS over HTTPS to Authority, including root, TLD and all
authority servers for all zones).

I'll use that assumption in the remainder of this message...


>
> > This would not help for on-path attackers (without DoT, DoH)
>
> See below.
>
> > How would this be safe against the current BGP attacks we are seeing?
>
> Are you saying connecting to an IP address secured by DNSSEC
> is safe even under BGP attacks?
>

The complete model of using DNSSEC involves also using TLSA records (DANE).
In the DNSSEC-protected TLSA record model, BGP attacks have no direct
impact on DNSSEC-protected zones, including BOTH the address records
(A/) AND the TLS information (complete certificate, or public key, or
hash of either of those), and consequently no impact on the TLS connections
subsequent to the DNS lookups (i.e. no possible cert-level MITM or web site
spoofing).

The exclusive capability of a MITM would be to DOS the DNS lookups, or to
block the TLS set-up (if the attacker were on the data path to the
endpoint).

So, yes, a web site properly protected using all of the DNSSEC-based
capabilities, where the client software was doing the validation using the
corresponding methods, would be safe against any and all MITM attacks,
including BGP.

Note that this is already the case for SMTP (using SMTPS via TLSA records).
Those SMTP connections between parties publishing and validating TLSA
records are not subject to downgrade attacks, and only properly validated
endpoints can communicate (securely).


>
> >> As for MitM attacks, PKI, in general, is insecure against
> >> them as was demonstrated by diginotar. So, don't bother.
> >
> > DNSSEC is more hierarchical than the "bag of CAs", so a failure
> > like this would be more contained. Regardless, I do not understand
> > how PKI failures relate to DNS?
>
> Are you saying you don't understand DNSSEC is a form of PKI?
>

I'm reasonably sure that Paul W meant "WebPKI" when he said PKI.

WebPKI is effectively a "flat namespace" sort of PKI, meaning a bunch of
CAs all have the right to issue certificates, with no exclusivity (which is
part of what lead to the diginotar thing).

By comparison, DNSSEC is an exclusively hierarchical, singular control
point PKI system. At each level of the hierarchy, the public keys are under
the exclusive control of the zone owner/administrator/operator, and signed
by the parent zone.
(Any concerns on the out-of-band update aspects are potentially worthy of
work, but that is also the case for the OOB update aspects for WebPKI.)


>
> >> IETF can do nothing if some government legally force
> >> people to install some government provided certificates
> >> to some PKI, including DNSSEC, which is as easy as
> >> MitM attacks on ISP chain may be by government order.
> >
> > With DNSSEC, a government in country X cannot spoof data of
> > country Y, they can only block it.
>
> Country X legally forcing people to install government provided
> root certificates can freely spoof PKI, including DNSSEC, data
> of country Y.
>

This is another place where the "flat" WebPKI vs the "hierarchical" DNSSEC
models are not exactly the same.

In addition to resolvers, end hosts have the ability to do DNSSEC
validation (on data received from resolvers).

Any host (resolver or end host) is capable of installing trust anchors for
any level of the DNS hierarchy, which would preempt any spoofed delegation
information (DS records) and reduce unsigned delegation spoofery to the
aforementioned DOS level of interference. End hosts would never see the
spoofed answers.

End hosts may also have some ability to make use of other resolvers (very
much dependent on local conditions, of course).

The scope of what country X can do with respect to country Y, is limited by
any number of orthogonal elements.
Those include

   - geographical limits (e.g. the physical boundary of country X)
   - topological considerations (all the paths from every host/user to the
   outside world)
   - resolvers reachable by any/all hosts/users
   - host/application configuration on all of the resolvers and hosts
   - necessity of altering responses at every level of the DNS hierarchy by
   on-path changes for all of the above elements

Additionally, outside of the physical geographical boundary of country X,
nothing country X can do can accomplish 

Re: [DNSOP] DNSSEC as a Best Current Practice

[David Conrad]

On Mar 21, 2022, at 1:01 AM, Masataka Ohta  
wrote:
> Paul Wouters wrote:
> 
>>>  Constructive thing to do to make DNS secure is to totally
>>> abandon DNSSEC and rely on DNS cookie or something like that.
> 
>> DNS cookies provide no data origin security, only a weak transport
>> security against non-onpath attackers.
> 
> 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.

No.

https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack/ 

https://www.theregister.com/2018/04/24/myetherwallet_dns_hijack/ 

Etc.

Securing the channel of communication != securing the data communicated via 
that channel.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Jim Reid wrote:


If you're saying DNS cookies are the answer,


As I said "DNS cookie or something like that", no, not necessarily
"the answer". But it certainly is an alternative.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Jim Reid]

> On 21 Mar 2022, at 14:36, Masataka Ohta  
> wrote:
> 
> How can you say I must provide some draft for some protocol by
> myself even though an alternative of DNS cookie already is an rfc?

Modulo the IETF's code of conduct, I can say whatever I like - as can you or 
anyone else.

If you're saying DNS cookies are the answer, there's nothing more to say on 
this thread. Goodbye.

___
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:


I tried to substantiate the discussion


I'm afraid you didn't, from the beginning, to have stated:

   it just
   indicates that the value of deploying DNSSEC is often considered
   lower than the cost.

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]

Jim Reid wrote:


That might or might not be true. But where's your draft and code for an 
alternative?


How can you say I must provide some draft for some protocol by
myself even though an alternative of DNS cookie already is an rfc?

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

Okay,

I tried to substantiate the discussion but all I get back are unsubstantiated 
one line claims. I tried to ask for clarifications with details but didn’t 
receive these. If you can’t or won’t provide details, I cannot evaluate your 
claims and can take no action other than to reject your claims. If you can 
substantiate this in the future, I am happy to pick up this discussion.

Regards,

Paul

> 
> On Mar 21, 2022, at 15:12, Masataka Ohta  
> wrote:
> 
> Paul Wouters wrote:
> 
>> "Using a rogue AS known as AS9457, on February 3, the attackers
>> began advertising that they owned the IP addresses that served
>> developers.kakao.com,"
> 
> It is as easy as compromising developers.kakao.com.
> 
>> You can define every technical hack as a social problem because it
>> involved humans.
> 
> Yup.
> 
>>> The problem of DNSSEC, or PKI in general, is that, assuming such attacks, 
>>> it is equally easy to socially compromise a zone with DNSSEC signature.
>> Yet that has never happened, unlike BGP attacks.
> 
> You miss my point that DNSSEC to produce correct IP addresses
> is powerless against BGP attacks.
> 
>>> It's pretty easy to forge certificates.
>>> Never rely on untrustworthy TTPs.
>> Yet I don’t hear you say to abandon TLS ?
> 
> TLS is no better than DH, which is subject to MitM attacks,
> though you might hear it from me for the first time.
> 
>>> Because security by PKI including DNSSEC is not end to end
>> With TRRs in browsers like Firefox, it practically is.
> 
> Wrong.
> 
> Because it is not end to end, it is subject to MitM attacks
> on software distribution chain.
> 
>>> Or, can you improve DNSSEC to instantly invalidate compromised
>>> zone information, which is impossible with slowly acting CRLs.
>> DNSSEC has no CRLs, only TTLs. I think you meant PKI here, not
>> DNSSEC?
> 
> That CRLs are very slow to react against attacks because
> PKI is not end to end makes CRLs totally useless for
> PKIs including DNSSEC, which is why I stated "instantly
> invalidate".
> 
 Socially, having long enough message IDs is as secure as DNSSEC.
>> “Socially” makes no sense from a protocol level.
> 
> BCP is not at the protocol level.
> 
> 
 That is because authors of the original specification of DNSSEC
>>> ignored my comments
>> It was not ignored, it was rejected.
> 
> It was ignored and rejected but later, with some implementation
> efforts, was recognized resulting in specification changes in
> the worst possible way, because recognition occurred to late.
> 
> So?
> 
> > Please submit a draft with enough details for an implementer and/or
> > sample code so the IETF can objectively evaluate your claims.
> 
> No implementation or code is necessary to say DNSSEC is
> fundamentally hopeless.
> 
>Masataka Ohta
> 
> ___
> 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] DNSSEC as a Best Current Practice

[Masataka Ohta]

Paul Wouters wrote:


You claim DNS can be secured if we somehow securely know all the IPs
of all nameservers of parent zones, for which the only source is DNS.
How do you propose to fulfill your own stated requirement without
DNSSEC?


Securely configuring IP addresses of root servers, which can
recursively assure data origin security of child servers, is
as easy/difficult as securely configuring root certificates.

So?


Are you saying connecting to an IP address secured by DNSSEC is
safe even under BGP attacks?


Yes. Obviously the attacker can deny the actual real DNS content but
sending their own made up DNS data is ignored due to data origin
protection.


Wrong.

With BGP attacks, your packet with an DNSSEC secured destination IP
address is delivered elsewhere.


Please refrain from ad hominem attacks if you wish to continue to
discuss.


I'm afraid it is you who want to discontinue discussion.

Country X legally forcing people to install government provided 
root certificates can freely spoof PKI, including DNSSEC, data of

country Y.



No they cannot. I can give you root access to a nameserver for
nohats.ca and you still can't create a "proof.nohats.ca"


It is trivially easy with root zone certificate recognized by
end users to forge RRs of "nohats.ca" and "proof.nohats.ca".


If you only handwave your claims,


I'm afraid it is you who is handwaving with such unfounded
statement:

   it just
   indicates that the value of deploying DNSSEC is often considered
   lower than the cost.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Jim Reid]

> On 21 Mar 2022, at 14:12, Masataka Ohta  
> wrote:
> 
> No implementation or code is necessary to say DNSSEC is
> fundamentally hopeless.

That might or might not be true. But where's your draft and code for an 
alternative?

___
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:


"Using a rogue AS known as AS9457, on February 3, the attackers
began advertising that they owned the IP addresses that served
developers.kakao.com,"


It is as easy as compromising developers.kakao.com.


You can define every technical hack as a social problem because it
involved humans.


Yup.

The problem of DNSSEC, or PKI in general, is that, assuming such 
attacks, it is equally easy to socially compromise a zone with 
DNSSEC signature.


Yet that has never happened, unlike BGP attacks.


You miss my point that DNSSEC to produce correct IP addresses
is powerless against BGP attacks.


It's pretty easy to forge certificates.

Never rely on untrustworthy TTPs.


Yet I don’t hear you say to abandon TLS ?


TLS is no better than DH, which is subject to MitM attacks,
though you might hear it from me for the first time.


Because security by PKI including DNSSEC is not end to end


With TRRs in browsers like Firefox, it practically is.


Wrong.

Because it is not end to end, it is subject to MitM attacks
on software distribution chain.


Or, can you improve DNSSEC to instantly invalidate compromised
zone information, which is impossible with slowly acting CRLs.


DNSSEC has no CRLs, only TTLs. I think you meant PKI here, not
DNSSEC?


That CRLs are very slow to react against attacks because
PKI is not end to end makes CRLs totally useless for
PKIs including DNSSEC, which is why I stated "instantly
invalidate".


Socially, having long enough message IDs is as secure as DNSSEC.


“Socially” makes no sense from a protocol level.


BCP is not at the protocol level.



That is because authors of the original specification of DNSSEC

ignored my comments


It was not ignored, it was rejected.


It was ignored and rejected but later, with some implementation
efforts, was recognized resulting in specification changes in
the worst possible way, because recognition occurred to late.

So?

> Please submit a draft with enough details for an implementer and/or
> sample code so the IETF can objectively evaluate your claims.

No implementation or code is necessary to say DNSSEC is
fundamentally hopeless.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Mar 21, 2022, at 13:28, Masataka Ohta  
wrote:
> 
> Paul Wouters wrote:
> 
>>> If a resolver correctly knows an IP address of a nameserver of a
>>> parent zone
>> This statement seems a recursion of the original problem statement?]
> 
> What?

You claim DNS can be secured if we somehow securely know all the IPs of all 
nameservers of parent zones, for which the only source is DNS. How do you 
propose to fulfill your own stated requirement without DNSSEC ?


>> How would this be safe against the current BGP attacks we are seeing?
> 
> Are you saying connecting to an IP address secured by DNSSEC
> is safe even under BGP attacks?

Yes. Obviously the attacker can deny the actual real DNS content but sending 
their own made up DNS data is ignored due to data origin protection. 


> 
>>> As for MitM attacks, PKI, in general, is insecure against
>>> them as was demonstrated by diginotar. So, don't bother.
>> DNSSEC is more hierarchical than the "bag of CAs", so a failure
>> like this would be more contained. Regardless, I do not understand
>> how PKI failures relate to DNS?
> 
> Are you saying you don't understand DNSSEC is a form of PKI?

Please refrain from ad hominem attacks if you wish to continue to discuss.

A webpki root ca failure has no relationship to dnssec which has no root ca’s.

> Country X legally forcing people to install government provided
> root certificates can freely spoof PKI, including DNSSEC, data
> of country Y.

No they cannot. I can give you root access to a nameserver for nohats.ca and 
you still can’t create a “proof.nohats.ca” DNS record that google DNS would 
serve to people. Similarly if we imagine you can coerce country X to do 
anything you want, how you could get this DNS record published so that the 
world’s servers/clients will believe your answer to be true. 

>> Again, I think perhaps you should write this up in a draft, so
>> we can see how your proposal would cover everything that DNSSEC
>> covers.
> 
> Before diginotar, maybe. After that, I don't think it necessary
> any more.

If you only handwave your claims, the only possible IETF response is to not 
spend time on your claims. I have now given you two methods to substantiate 
your claims to further the discussion.

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Mar 21, 2022, at 13:10, Masataka Ohta  
wrote:
> 
> Ted Lemon wrote
> 
>> It's pretty easy to intercept all packets destined for a particular IP
>> address and spoof the responses.
> 
> Technically, yes, but, socially, no, not at all.
> 
> It can be practically possible only if ISPs employees are socially
> compromised, which is criminal, or the ISP is ordered to do so
> by government.

https://therecord.media/klayswap-crypto-users-lose-funds-after-bgp-hijack/amp/

“ Using a rogue AS known as AS9457, on February 3, the attackers began 
advertising that they owned the IP addresses that served developers.kakao.com,”

You can define every technical hack as a social problem because it involved 
humans.

> The problem of DNSSEC, or PKI in general, is that, assuming such
> attacks, it is equally easy to socially compromise a zone with
> DNSSEC signature.

Yet that has never happened, unlike BGP attacks.


> It's pretty easy to forge certificates.
> 
> Never rely on untrustworthy TTPs.

Yet I don’t hear you say to abandon TLS ?

> Because security by PKI including DNSSEC is not end to end

With TRRs in browsers like Firefox, it practically is.

> Or, can you improve DNSSEC to instantly invalidate compromised zone
> information, which is impossible with slowly acting CRLs.

DNSSEC has no CRLs, only TTLs. I think you meant PKI here, not DNSSEC?

>> Socially, having long enough message IDs is as secure as DNSSEC.

“Socially” makes no sense from a protocol level. 



>> That is because authors of the original specification of DNSSEC
> ignored my comments

It was not ignored, it was rejected.

> For me, it was, has been and still is easy.

Please submit a draft with enough details for an implementer and/or sample code 
so the IETF can objectively evaluate your 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]

Ted Lemon wrote:


Ohta-san, I think the points you are making in response to what I have said
are that

(1) it's easier for a government to fake a DNS delegation than to MiTM an
IP connection, and
(2) if it's a government that's faking your DNS, they can jail you for
noticing.


You miss my point that compromising employees of ISPs or zones by, say,
kidnapping their children.


I think these are both valid points. However, I don't think they lead to
the conclusion you are drawing. First, if the government really cares about
censorship,


Censorship? Fake news are obviously better.


To the second question, this is also absolutely true, but at the same time,
as we can see, just because something is illegal doesn't mean that it's not
useful. E.g., the government in Russia has made it illegal to protest the
war in Ukraine, and yet we see people protesting in the streets. Their goal
is pretty clearly to bypass a government restriction on communication.


Be also aware of fake news produced against Russia by some governments.


Having a watchdog in software that notices when a certificate has been
replaced by one that isn't valid isn't that hard, and while it might be
made illegal after the fact, officially making it illegal would be a public
act that would have to be announced by the government in order to be
enforceable—otherwise software vendors would have no reason to know they
were violating the law.


The point is what, if any, can DNSSEC do against it.


By announcing it, the government in question is
disclosing the status of your security, which is the whole point.


But, justice defined by the government is the justice for those
who are under control of the government.

> Absent
> such a disclosure, citizens can continue to run such software, and
> continue to detect such attacks.

Though it can be a criminal offense against local justice.


Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Ted Lemon]

Ohta-san, I think the points you are making in response to what I have said
are that

(1) it's easier for a government to fake a DNS delegation than to MiTM an
IP connection, and
(2) if it's a government that's faking your DNS, they can jail you for
noticing.

I think these are both valid points. However, I don't think they lead to
the conclusion you are drawing. First, if the government really cares about
censorship, it's probably going to do some degree of DPI for connections to
IP addresses it has reason to care about. So you could in principle do a
connection to a device that isn't on the government's radar and bypass
their attack, for sure. But this is actually quite hard for a layperson to
arrange, and impossible to automate, since any automatic mechanism would be
known to the government in question.

To the second question, this is also absolutely true, but at the same time,
as we can see, just because something is illegal doesn't mean that it's not
useful. E.g., the government in Russia has made it illegal to protest the
war in Ukraine, and yet we see people protesting in the streets. Their goal
is pretty clearly to bypass a government restriction on communication.

Having a watchdog in software that notices when a certificate has been
replaced by one that isn't valid isn't that hard, and while it might be
made illegal after the fact, officially making it illegal would be a public
act that would have to be announced by the government in order to be
enforceable—otherwise software vendors would have no reason to know they
were violating the law. By announcing it, the government in question is
disclosing the status of your security, which is the whole point. Absent
such a disclosure, citizens can continue to run such software, and continue
to detect such attacks. In the presence of such a disclosure, citizens know
that their traffic is not secure, which is obviously not great, but still
represents success: the user now knows that the network isn't safe to use.
___
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:


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


This statement seems a recursion of the original problem statement?]


What?

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


This would not help for on-path attackers (without DoT, DoH)


See below.


How would this be safe against the current BGP attacks we are seeing?


Are you saying connecting to an IP address secured by DNSSEC
is safe even under BGP attacks?


As for MitM attacks, PKI, in general, is insecure against
them as was demonstrated by diginotar. So, don't bother.


DNSSEC is more hierarchical than the "bag of CAs", so a failure
like this would be more contained. Regardless, I do not understand
how PKI failures relate to DNS?


Are you saying you don't understand DNSSEC is a form of PKI?


IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.


With DNSSEC, a government in country X cannot spoof data of
country Y, they can only block it.


Country X legally forcing people to install government provided
root certificates can freely spoof PKI, including DNSSEC, data
of country Y.


Again, I think perhaps you should write this up in a draft, so
we can see how your proposal would cover everything that DNSSEC
covers.


Before diginotar, maybe. After that, I don't think it necessary
any more.

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]

Ted Lemon wrote:


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.



It's pretty easy to intercept all packets destined for a particular IP
address and spoof the responses.


Technically, yes, but, socially, no, not at all.

It can be practically possible only if ISPs employees are socially
compromised, which is criminal, or the ISP is ordered to do so
by government.

The problem of DNSSEC, or PKI in general, is that, assuming such
attacks, it is equally easy to socially compromise a zone with
DNSSEC signature.

It's pretty easy to forge certificates.

Never rely on untrustworthy TTPs.


IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.



Attacks of this nature are in principle detectable.


Technically, maybe, but, socially, it is not detectable at
least legally, if such detection is defined to be (may be
criminally) unlawful.


The way to detect them
is to notice these forcibly injected certificates based on the public keys
presented in them.


And you can be arrested.

It should be noted that google's attempt to statically install
some certificate in their browser is subject to MitM attacks
on employees of google or distribution chain of the browser.
Moreover, such software may be legally banned by some government.


Of course, you need to have a source of truth, and
nothing is perfect, but also, the best is the enemy of good enough. There's
been plenty of discussion and research on the topic of how to notice that
forged certificates are being presented. What I don't see happening (maybe
I'm missing it) is this stuff being deployed in the real world.


Because security by PKI including DNSSEC is not end to end, it is
impossible to detect security breach so quickly.

Or, can you improve DNSSEC to instantly invalidate compromised zone
information, which is impossible with slowly acting CRLs.


As for using "something like cookies" to secure the communications channel,
this is functionally the same problem as noticing that certificates have
been forged, but gets you a lot less benefit in practice, because you have
to have a secure channel to each thing you want to be able to validate, or
else you have to have  a server that is able to do such validation for you
and a secure channel to it (which amounts to the same thing).


Socially, having long enough message IDs is as secure as DNSSEC.


So although DNSSEC is complicated,


That is because authors of the original specification of DNSSEC
ignored my comments (at that time, I was not aware of fundamental
lack of security of PKIs), as a DNS expert having enough knowledge
on PKI, to make it highly compatible with existing DNS.

As a result, DNSSEC was modified to be so complicated trying to
incorporate my earlier comments in ugly manners.


and it's easy to talk about simpler
solutions,


For me, it was, has been and still is easy.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Mon, 21 Mar 2022, Masataka Ohta wrote:


 DNS cookies provide no data origin security, only a weak transport
 security against non-onpath attackers.


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


This statement seems a recursion of the original problem statement?


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.


This would not help for on-path attackers (without DoT, DoH)

How would this be safe against the current BGP attacks we are seeing?


As for MitM attacks, PKI, in general, is insecure against
them as was demonstrated by diginotar. So, don't bother.


DNSSEC is more hierarchical than the "bag of CAs", so a failure
like this would be more contained. Regardless, I do not understand
how PKI failures relate to DNS?


IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.


With DNSSEC, a government in country X cannot spoof data of
country Y, they can only block it. DNS without DNSSEC allows
country Y to spoof country X.

Again, I think perhaps you should write this up in a draft, so
we can see how your proposal would cover everything that DNSSEC
covers.

Paul

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Ted Lemon]

On Mon, Mar 21, 2022 at 9:02 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

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

It's pretty easy to intercept all packets destined for a particular IP
address and spoof the responses.

IETF can do nothing if some government legally force
> people to install some government provided certificates
> to some PKI, including DNSSEC, which is as easy as
> MitM attacks on ISP chain may be by government order.


Attacks of this nature are in principle detectable. The way to detect them
is to notice these forcibly injected certificates based on the public keys
presented in them. Of course, you need to have a source of truth, and
nothing is perfect, but also, the best is the enemy of good enough. There's
been plenty of discussion and research on the topic of how to notice that
forged certificates are being presented. What I don't see happening (maybe
I'm missing it) is this stuff being deployed in the real world.

As for using "something like cookies" to secure the communications channel,
this is functionally the same problem as noticing that certificates have
been forged, but gets you a lot less benefit in practice, because you have
to have a secure channel to each thing you want to be able to validate, or
else you have to have  a server that is able to do such validation for you
and a secure channel to it (which amounts to the same thing).

So although DNSSEC is complicated, and it's easy to talk about simpler
solutions, whenever you dig into the details, what you find is that either
they don't actually deliver what DNSSEC delivers, or else they wind up
being more complicated and harder to operate. Security doesn't come for
free.
___
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:


 Constructive thing to do to make DNS secure is to totally
abandon DNSSEC and rely on DNS cookie or something like that.



DNS cookies provide no data origin security, only a weak transport
security against non-onpath attackers.


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.

As for MitM attacks, PKI, in general, is insecure against
them as was demonstrated by diginotar. So, don't bother.

IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.

Masataka Ohta

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Paul Wouters]

On Mar 21, 2022, at 07:10, Masataka Ohta  
wrote:
> 
> 
> Constructive thing to do to make DNS secure is to totally abandon
> DNSSEC and rely on DNS cookie or something like that.


DNS cookies provide no data origin security, only a weak transport security 
against non-onpath attackers.

A replacement suggestion for DNSSEC would need a bit more specification than 
“cookie or something like that”. It would not only need to cover what DNSSEC 
protects against, but also be worth the pain of a worldwide migration. An 
internet draft for this would be a good starting point for a discussion.

Paul

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

Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta]

Paul Hoffman wrote:


In the meantime, anyone interested can make suggestions on how to
improve the draft so that it is nice and shiny when it come to the WG
for adoption.


   it just
   indicates that the value of deploying DNSSEC is often considered
   lower than the cost.

is just wrong.

Constructive thing to do to make DNS secure is to totally abandon
DNSSEC and rely on DNS cookie or something like that.

Masataka Ohta

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