On Sun, 20 Mar 2022, Paul Hoffman wrote:
Greetings again. I have created a new, very short draft to add more private use
algorithms to DNSSEC.
https://datatracker.ietf.org/doc/draft-hoffman-more-private-algs/
The abstract says:
RFC 4034 allocates one value in the IANA registry for DNSSEC
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
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
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 statemen
I'm concerned about this. Concretely, this seems like it would raise a
major barrier to rolling out new algorithms. For example, any zone that
offers ECDSA and RSA signatures would be insecure for any RSA-only
resolvers. It's hard to see how new algorithms could be adopted at scale
if this rule
> On 21 Mar 2022, at 09:19, Ben Schwartz
> wrote:
>
> Personally, I favor #3. What do you think?
Ben, I think 2 (Expert Review) is the right approach. This would hopefully
ensure any specifications are complete/valid and raise the threshold to
discourage bad or frivolous SrvParamValues "
I favour #3 over #2 on the basis that you can't reasonably put the "how to
convert" text into a registry.
On Mon, Mar 21, 2022, at 20:19, Ben Schwartz wrote:
> Hi DNSOP,
>
> The latest draft of the SVCB specification says [1]
>
>> Entries in this registry are subject to a First Come First Serve
Hi Libor,
You are absolutely right. The problem is not easily solved.
We will need a way to signal when this is ok and when not.
My own security assessment goes like this:
If the domain is in transition from one signer to another and a resolver only
supports one of the algorithms, the transiti
On Mon, 21 Mar 2022, Ben Schwartz wrote:
This leaves us with several possible options:
1. Change the MUST to SHOULD, or otherwise indicate that IANA is not expected
to enforce anything about the contents of the format
reference. Registrations might appear without a suitable format reference,
On Mon, Mar 21, 2022 at 6:33 AM Paul Wouters wrote:
> On Mon, 21 Mar 2022, Ben Schwartz wrote:
>
> > This leaves us with several possible options:
> > 1. Change the MUST to SHOULD, or otherwise indicate that IANA is not
> expected to enforce anything about the contents of the format
> > reference
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
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
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. H
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
I agree with Paul that #2 seems to be best, with the expert being able to
enforce a certain level of specification depending on the parameter being
allocated.
Tommy
> On Mar 21, 2022, at 3:32 AM, Paul Wouters wrote:
>
> On Mon, 21 Mar 2022, Ben Schwartz wrote:
>
>> This leaves us with severa
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 a
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
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
inv
> 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
D
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
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 cla
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
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
> 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 say
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
___
DNSO
On the other hand, do you know any zones that permanently (other than
active roll-over) sign with two algorithms in parallel? AFAIK this is
_not_ the usual way how new algorithms are being rolled out. I guess new
algorithms would continue to be adopted in the same way: first wide
enough support
Hi Ben,
The proposal is not to remove the possibility of double signatures, but to
relax the requirement so that other use cases become possible.
Our use case is the transition from one dns provider to another without going
insecure. If both use the same algorithm you can use the multi-signer d
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
Hi Paul,
I think this is good.
Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon in
PowerDNS, and they used the next unused algorithm number rather than a private
algorithm? If the authors of that work are on this list I would be interested
to hear from them about tha
On Mar 21, 2022, at 11:34 AM, Wessels, Duane
wrote:
> Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon
> in PowerDNS, and they used the next unused algorithm number rather than a
> private algorithm?
Nils could have picked 253 but probably didn't even think of lookin
If we assume the existing install base of resolvers isn't going away, then
I don't see how we could relax the requirement. There are already deployed
resolvers enforcing it. You would need a "flag day" to deprecate them,
which could not happen for many years.
This seems a lot harder than just te
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 sta
All,
When we started preparing a slide deck for the usual chairs’ slides and
updating the working group on what has been going on, we quickly realized
it was probably better to keep the chairs’ time in the meeting to a
minimum. So there will be a very quick overview in the meeting but more
substan
Also the whole point of mandatory to implement (which includes business
practices) is to prevent cases like this.
If a business wants to lie to its customers about supporting DNSSEC it should
be taken to court, preferably by
bodies like the ACCC.
As for migration between providers, provided ther
34 matches
Mail list logo
