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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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”
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
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
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
(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
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,
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.
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,
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
> […]
___
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
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
>
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
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.
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
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.
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
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
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
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
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
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
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
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",
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 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
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
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
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
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
___
> 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
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
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
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
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
> 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
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
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
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
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
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.
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
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.
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
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
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
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
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.
As a follow-up to the thread last week, I created a fairly short draft that
describes DNSSEC in a single document and calls it a BCP. See:
https://datatracker.ietf.org/doc/draft-hoffman-dnssec/
Based on the list discussion, I spoke with Warren about the idea of a
short-lived separate WG for
63 matches
Mail list logo
