Re: [DNSOP] SIG(0) useful (and used?)

[Viktor Dukhovni]

On Wed, Jun 20, 2018 at 07:47:16AM +1000, Mark Andrews wrote:

> SIG(0) has miles of potential.  Active Directory shows that hosts updating
> their own addresses is useful.

And not just their own addresses.  On my TODO list is making DANE
more manageable by (optionally) allowing the holder of a private
key correspoding to a TLSA "DANE-EE(3) X Y" record to update the
containing RRset to introduce the TLSA record for the next key.

> SIG(0) provides a similar mechanism without the overhead of AD.   It
> actually works well today if you spend the time to hook it into a system.
> What�s needed is for OS vendors to ship machines with support enabled.
> 
> Use AD if the machine is part of  a AD domain and this if it isn�t.  It
> really isn�t that hard to do it just requires OS developers to do it.

I think that SIG(0) could be quite useful, perhaps it was just
introduced before its time.

-- 
Viktor.

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

Re: [DNSOP] SIG(0) useful (and used?)

[Warren Kumari]

On Fri, Jun 22, 2018 at 9:48 AM Ted Lemon  wrote:

> It seems to me that the main benefit of SIG(0) is not securing connections
> between resolvers and caches, but in securing DNS updates and other
> transfers where you need authentication+authorization.   In the case where
> you just need authentication, we already have DNSSEC.   I _guess_ Warren's
> use case makes some sense, but I think it's a bit hackerly, and not
> something we'd expect to see wide deployment.
>

​I think that if it *had* been implemented (and easily configured!) in e.g
glibc it might have gotten some deployment - but now DPRIVE and DoH (and
similar) will give me everything that I wanted (and more) and so my use
case is no longer worth considering...
W


>
> On Fri, Jun 22, 2018 at 9:41 AM, Vladimír Čunát <
> vladimir.cunat+i...@nic.cz> wrote:
>
>> On 06/22/2018 12:27 AM, Ted Lemon wrote:
>> > Thanks. In the case where a zone isn’t signed but the authoritative
>> > server supports SIG(0), the response could be verified that it
>> > includes exactly what the server sent. But the KEY would need to be
>> > DNSSEC validated or it probably can’t be trusted to verify the SIG(0)
>> > response.
>>
>> Well, the path to the resolver can be secured via other means that are
>> commonly available nowadays, e.g. DNS over TLS.  I can also see use
>> cases for client trusting a resolver enough not to bother with DNSSEC
>> validation locally.
>>
>> --Vladimir
>>
>> ___
>> 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
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SIG(0) useful (and used?)

[Shumon Huque]

On Fri, Jun 22, 2018 at 12:05 PM Tom Pusateri  wrote:

> What’s the point of using DNS to look up a KEY RR to verify a signature if
> you can’t trust the KEY? The KEY resides in the senders zone so no
> relationship with a resolver will help you here.
>

Yeah, this is a limitation in the SIG(0) spec as currently written, that I
don't think needed to be there. If we consider the functionality of SIG(0)
to be essentially a public key version of TSIG, then it should be possible
to support a mode of operation where the key material is verified and
pre-configured out-of-band, as is commonly the case with TSIG. If I were
implementing SIG(0), I would have supported that.

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

Re: [DNSOP] SIG(0) useful (and used?)

[Ted Lemon]

It seems to me that the main benefit of SIG(0) is not securing connections
between resolvers and caches, but in securing DNS updates and other
transfers where you need authentication+authorization.   In the case where
you just need authentication, we already have DNSSEC.   I _guess_ Warren's
use case makes some sense, but I think it's a bit hackerly, and not
something we'd expect to see wide deployment.

On Fri, Jun 22, 2018 at 9:41 AM, Vladimír Čunát 
wrote:

> On 06/22/2018 12:27 AM, Ted Lemon wrote:
> > Thanks. In the case where a zone isn’t signed but the authoritative
> > server supports SIG(0), the response could be verified that it
> > includes exactly what the server sent. But the KEY would need to be
> > DNSSEC validated or it probably can’t be trusted to verify the SIG(0)
> > response.
>
> Well, the path to the resolver can be secured via other means that are
> commonly available nowadays, e.g. DNS over TLS.  I can also see use
> cases for client trusting a resolver enough not to bother with DNSSEC
> validation locally.
>
> --Vladimir
>
> ___
> 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] SIG(0) useful (and used?)

[Vladimír Čunát]

On 06/22/2018 12:27 AM, Ted Lemon wrote:
> Thanks. In the case where a zone isn’t signed but the authoritative
> server supports SIG(0), the response could be verified that it
> includes exactly what the server sent. But the KEY would need to be
> DNSSEC validated or it probably can’t be trusted to verify the SIG(0)
> response.

Well, the path to the resolver can be secured via other means that are
commonly available nowadays, e.g. DNS over TLS.  I can also see use
cases for client trusting a resolver enough not to bother with DNSSEC
validation locally.

--Vladimir

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

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 21, 2018, at 1:40 PM, Shumon Huque  wrote:
> 
> On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri  > wrote:
>> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát > > wrote:
>> 
>> On 06/20/2018 04:59 PM, Tom Pusateri wrote:
>>> DNSSEC will tell you the answer you get is correct but it could be a > to a 
>>> different question or be incomplete.
>> Can you elaborate on that point.  I believe in signed zones you are able
>> to verify almost everything, in particular existence of the queried-for
>> RRset and its exact value, except for details like current TTL.
>> 
>> --Vladimir
>> 
> 
> I’ve been thinking about the case when you are given a DNS recursive resolver 
> over DHCP and you don’t necessarily trust it.
> 
> SIG(0) can't really protect you from an untrustworthy resolver. It can ensure 
> that the question you sent and the answer you got back from the recursive 
> server was not tampered with in-flight. But it can't detect whether the 
> recursive server modified any data in its response before it signed it with 
> SIG(0). If the response contained DNSSEC signed data and the stub was 
> validating, then those pieces of the response could be authenticated. But not 
> anything in the header, question etc - all of that could have been modified 
> by the recursive server without detection.
>  
> If you send a query with the DO bit set to a recursive resolver for the A 
> record for foo.example.com  and the recursive 
> resolver modifies this query to foo.exampl.com , you 
> can get back a validated DNSSEC response with the A record answer, RRSIG, 
> NSEC(3) records all for the wrong question. The resolver code in the OS or 
> application would get back the matching DNS header identifier and if it 
> lazily just grabbed the A record answer without comparing the RR name, it 
> could be misled. You can detect this without SIG(0) so maybe that was a bad 
> example. But if you always sent a SIG(0) signed question and got a signed 
> answer, you could detect this and possibly other future attacks and drop it 
> before even parsing the answers.
> 
> Most competent resolvers will check that the response that they got back was 
> for the question they asked. So I don't think they would "lazily just grab 
> the A record answer without comparing the RR name".
> 
> I don't think SIG(0) really helps much here. The response signature has to 
> include the entire query message, but the actual response can contain 
> anything the recursive server puts in there.
>  
> In the case of missing answers, I was thinking that if there were multiple A 
> records in the response and some were filtered, you could not detect this 
> without a SIG(0) signed response from the authoritative server. This would be 
> important if one server was compromised and the recursive resolver filtered 
> the response to exclude the other A records pointing to servers that weren’t 
> compromised directing you to the compromised server.
> 
> DNSSEC is really the solution to this problem. DNSSEC signatures cover the 
> entire RRset, so authoritative (or recursive) servers cannot strip away some 
> of the RRs without detection by a downstream validator.
> 
> Shumon.
> 

Thanks. In the case where a zone isn’t signed but the authoritative server 
supports SIG(0), the response could be verified that it includes exactly what 
the server sent. But the KEY would need to be DNSSEC validated or it probably 
can’t be trusted to verify the SIG(0) response.

Tom


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

Re: [DNSOP] SIG(0) useful (and used?)

[Shumon Huque]

On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri  wrote:

> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát 
> wrote:
>
> On 06/20/2018 04:59 PM, Tom Pusateri wrote:
>
> DNSSEC will tell you the answer you get is correct but it could be a > to
> a different question or be incomplete.
>
> Can you elaborate on that point.  I believe in signed zones you are able
> to verify almost everything, in particular existence of the queried-for
> RRset and its exact value, except for details like current TTL.
>
> --Vladimir
>
>
> I’ve been thinking about the case when you are given a DNS recursive
> resolver over DHCP and you don’t necessarily trust it.
>

SIG(0) can't really protect you from an untrustworthy resolver. It can
ensure that the question you sent and the answer you got back from the
recursive server was not tampered with in-flight. But it can't detect
whether the recursive server modified any data in its response before it
signed it with SIG(0). If the response contained DNSSEC signed data and the
stub was validating, then those pieces of the response could be
authenticated. But not anything in the header, question etc - all of that
could have been modified by the recursive server without detection.


> If you send a query with the DO bit set to a recursive resolver for the A
> record for foo.example.com and the recursive resolver modifies this query
> to foo.exampl.com, you can get back a validated DNSSEC response with the
> A record answer, RRSIG, NSEC(3) records all for the wrong question. The
> resolver code in the OS or application would get back the matching DNS
> header identifier and if it lazily just grabbed the A record answer without
> comparing the RR name, it could be misled. You can detect this without
> SIG(0) so maybe that was a bad example. But if you always sent a SIG(0)
> signed question and got a signed answer, you could detect this and possibly
> other future attacks and drop it before even parsing the answers.
>

Most competent resolvers will check that the response that they got back
was for the question they asked. So I don't think they would "lazily just
grab the A record answer without comparing the RR name".

I don't think SIG(0) really helps much here. The response signature has to
include the entire query message, but the actual response can contain
anything the recursive server puts in there.


> In the case of missing answers, I was thinking that if there were multiple
> A records in the response and some were filtered, you could not detect this
> without a SIG(0) signed response from the authoritative server. This would
> be important if one server was compromised and the recursive resolver
> filtered the response to exclude the other A records pointing to servers
> that weren’t compromised directing you to the compromised server.
>

DNSSEC is really the solution to this problem. DNSSEC signatures cover the
entire RRset, so authoritative (or recursive) servers cannot strip away
some of the RRs without detection by a downstream validator.

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

Re: [DNSOP] SIG(0) useful (and used?)

[Shumon Huque]

On Thu, Jun 21, 2018 at 9:55 AM Warren Kumari  wrote:

>
> I think that 95% of the issue is on the stub side.
>
> Paul's https://github.com/BII-Lab/DNSoverHTTP and Stubby both come fairly
> close to solving this. The more I think about it, DPRIVE and DoH are
> driving towards what I want.
>
>
Yeah, this might end up being mostly a theoretical exercise. DPRIVE/DOH may
be the more easily available solution by time time you figure out how to do
this!

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

Re: [DNSOP] SIG(0) useful (and used?)

[ietf-dnsops]

> On 21 Jun 2018, at 00:13, Paul Vixie  wrote:
> 
> ...
>> So, SIG(0) could be many nice things, but without more implementations
>> is is hobbled...
> 
> i'd love to see it implemented.
I would also add my voice to those who would love to see this implemented.  I 
have looked at using SIG(0) many times in the past and its lack of support is 
what has prevented me.  I think systems like Wes's localroot[1] system would be 
much improved with support for  SIG(0) and could even allow operators, and 
software distributors to support a a list of LocalRoot services out of the box 
without additional configuration by users

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

Re: [DNSOP] SIG(0) useful (and used?)

[Warren Kumari]

On Thu, Jun 21, 2018 at 4:52 AM Joe Abley  wrote:

> On Jun 20, 2018, at 21:05, Shumon Huque  wrote:
>
>
> On Wed, Jun 20, 2018 at 7:30 PM Joe Abley  wrote:
>
>> On Jun 20, 2018, at 19:07, Warren Kumari  wrote:
>>
>> ​... what I'd alway wanted[0] was to be able to setup my own recursive
>> name server somewhere on the Internet, and then only allow myself (and a
>> few of my closest friends) to be able to query it.
>>
>> For this particular use-case, why is SIG(0) better than TSIG?
>>
>
> Either might be fine in these small user scenarios.
>
>
> Yes, I know, hence the question. Warren usually has his reasons :-)
>

​Yes, but these are often related to "because it amused me or seemed like a
good idea at the time", and so it is always worth checking :-)

I was wanting to be able to provide this on the order of 50 - 100 devices.
This includes all my devices, including laptops, phones, tablets, travel
routers, kindle, and all of my wife's devices (similar set), and my aunty
Sue's devices. Ideally this would also be usable for something like a small
enterprise (without having a full VPN). Managing TSIG keys for all those
seems tricky.

I don't actually think that TSIG would do what I want either -- technically
it could, but I think that what is missing is the ability to easily
configure keying information in /etc/resolv.conf (or other stub config).
Ideally I'd like to add something to resolve.conf (or similar) saying:
nameserver 192.0.2.53 key 0xbadc0ffee

I think that 95% of the issue is on the stub side.

Paul's https://github.com/BII-Lab/DNSoverHTTP and Stubby both come fairly
close to solving this. The more I think about it, DPRIVE and DoH are
driving towards what I want.


> The follow-on question was why he needs this functionality in the stub
> resolver rather than running a local copy of BIND9 (bound to localhost,
> configured appropriately) and pointing his stub resolver at that.
>

A couple of reasons:
1: I'd like to be able to take advantage of a shared cache
2: I'd like to be able to use this for my {mac,  androids,  iPhone / iPads,
linux laptops}, my wife's {mac, iPhone / iPads, linux laptops}, travel
router, kindle, etc.
Apart from the fact that I cannot run BIND / Unbound on many of these
devices, keeping this many full nameservers watered and fed would be
annoying.


​W​



>
>
> Joe
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát  
> wrote:
> 
> On 06/20/2018 04:59 PM, Tom Pusateri wrote:
>> DNSSEC will tell you the answer you get is correct but it could be a > to a 
>> different question or be incomplete.
> Can you elaborate on that point.  I believe in signed zones you are able
> to verify almost everything, in particular existence of the queried-for
> RRset and its exact value, except for details like current TTL.
> 
> --Vladimir
> 

I’ve been thinking about the case when you are given a DNS recursive resolver 
over DHCP and you don’t necessarily trust it.

If you send a query with the DO bit set to a recursive resolver for the A 
record for foo.example.com  and the recursive resolver 
modifies this query to foo.exampl.com , you can get 
back a validated DNSSEC response with the A record answer, RRSIG, NSEC(3) 
records all for the wrong question. The resolver code in the OS or application 
would get back the matching DNS header identifier and if it lazily just grabbed 
the A record answer without comparing the RR name, it could be misled. You can 
detect this without SIG(0) so maybe that was a bad example. But if you always 
sent a SIG(0) signed question and got a signed answer, you could detect this 
and possibly other future attacks and drop it before even parsing the answers.

In the case of missing answers, I was thinking that if there were multiple A 
records in the response and some were filtered, you could not detect this 
without a SIG(0) signed response from the authoritative server. This would be 
important if one server was compromised and the recursive resolver filtered the 
response to exclude the other A records pointing to servers that weren’t 
compromised directing you to the compromised server.

If I’m wrong about the second case, then I concede.

Thanks,
Tom



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

Re: [DNSOP] SIG(0) useful (and used?)

[Joe Abley]

On Jun 20, 2018, at 21:05, Shumon Huque  wrote:


On Wed, Jun 20, 2018 at 7:30 PM Joe Abley  wrote:

> On Jun 20, 2018, at 19:07, Warren Kumari  wrote:
>
> ​... what I'd alway wanted[0] was to be able to setup my own recursive
> name server somewhere on the Internet, and then only allow myself (and a
> few of my closest friends) to be able to query it.
>
> For this particular use-case, why is SIG(0) better than TSIG?
>

Either might be fine in these small user scenarios.


Yes, I know, hence the question. Warren usually has his reasons :-)

The follow-on question was why he needs this functionality in the stub
resolver rather than running a local copy of BIND9 (bound to localhost,
configured appropriately) and pointing his stub resolver at that.


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

Re: [DNSOP] SIG(0) useful (and used?)

[Vladimír Čunát]

On 06/20/2018 04:59 PM, Tom Pusateri wrote:
> DNSSEC will tell you the answer you get is correct but it could be a > to a 
> different question or be incomplete.
Can you elaborate on that point.  I believe in signed zones you are able
to verify almost everything, in particular existence of the queried-for
RRset and its exact value, except for details like current TTL.

--Vladimir

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

Re: [DNSOP] SIG(0) useful (and used?)

[Shumon Huque]

On Wed, Jun 20, 2018 at 7:30 PM Joe Abley  wrote:

> On Jun 20, 2018, at 19:07, Warren Kumari  wrote:
>
> ​... what I'd alway wanted[0] was to be able to setup my own recursive
> name server somewhere on the Internet, and then only allow myself (and a
> few of my closest friends) to be able to query it.
>
> For this particular use-case, why is SIG(0) better than TSIG?
>

Either might be fine in these small user scenarios.

In the "only Warren" scenario, TSIG is probably simpler. For the "Warren
and few close friends" scenario, it depends on how much he trusts those
friends. If he trusts them not to spoof responses to him (if they are able
to insert themselves as MITM attacker somehow), he could get away with a
single shared symmetric TSIG key. If not, he'd have to provision distinct
TSIG keys for himself, and each of the friends, which is more work, but
still might be manageable if the set of friends is small enough - but
SIG(0) is probably now looking attractive. If Warren and friends are doing
their own validation of responses from the recursive server (note: most
stubs today do not), then spoofing might be less of a concern, but there is
still a lot of unsigned data out there.

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

Re: [DNSOP] SIG(0) useful (and used?)

[Joe Abley]

On Jun 20, 2018, at 19:07, Warren Kumari  wrote:

​... what I'd alway wanted[0] was to be able to setup my own recursive name
server somewhere on the Internet, and then only allow myself (and a few of
my closest friends) to be able to query it.

For this particular use-case, why is SIG(0) better than TSIG?


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

Re: [DNSOP] SIG(0) useful (and used?)

[Paul Vixie]

Warren Kumari wrote:

...
​​

​... what I'd alway wanted[0] was to be able to setup my own recursive
name server somewhere on the Internet, and then only allow myself (and a
few of my closest friends) to be able to query it.

1: Obviously having it as an open-recursive is not the answer (e.g it
would show up in Jared's list within a few days :-))
2: Everyone travels, and so adding and removing myself (and a few of my
closest friends) from ACLs won't realistically work
3: The obvious "just use a VPN" / SSH tunnels / etc is simply annoying.


i set up a dns-over-https tunnel for myself three years ago and promptly 
forgot all about it. note: i am easily annoyed.


https://github.com/BII-Lab/DNSoverHTTP

that said:


...
SIG(0) seemed like the perfect solution -- toss something in resolv.conf
next to the nameserver, and  magic happens. Unfortunately,
this doesn't actually, you know, exist...


i agree. if it existed, i would use it, except when behind middleboxes 
who "know" what dns has to look like.



(and much of it can now be
solved with DNS-over-TLS, but still...)


unless you're behind a middlebox that "knows" what dns has to look like.


...
So, SIG(0) could be many nice things, but without more implementations
is is hobbled...


i'd love to see it implemented.

--
P Vixie

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

Re: [DNSOP] SIG(0) useful (and used?)

[Warren Kumari]

On Tue, Jun 19, 2018 at 5:04 PM Tony Finch  wrote:

> Ondřej Surý  wrote:
> >
> > Do people think the SIG(0) is something that we should keep in DNS and
> > it will be used in the future or it is a good candidate for throwing off
> > the boat?
>
> SIG(0) is the only DNS feature that (could) allow unauthenticated client
> access to an authenticated server, which would allow
>
> * secure inteerface to resolver (maybe with SIG(0) + TKEY -> TSIG,
>   but now  probably better to use TLS or DoH)
>
> * secure stealth secondaries (maybe TLS support would be better)
>
​​

​... what I'd alway wanted[0] was to be able to setup my own recursive name
server somewhere on the Internet, and then only allow myself (and a few of
my closest friends) to be able to query it.

1: Obviously having it as an open-recursive is not the answer (e.g it would
show up in Jared's list within a few days :-))
2: Everyone travels, and so adding and removing myself (and a few of my
closest friends) from ACLs won't realistically work
3: The obvious "just use a VPN" / SSH tunnels / etc is simply annoying.

SIG(0) seemed like the perfect solution -- toss something in resolv.conf
next to the nameserver, and  magic happens. Unfortunately, this
doesn't actually, you know, exist... (and much of it can now be solved with
DNS-over-TLS, but still...)

So, SIG(0) could be many nice things, but without more implementations is
is hobbled...

W
[0]: Ok, I haven't *always* wanted this, only for the past ~18 years...






>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> an equitable and peaceful international
> order___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 20, 2018, at 3:23 PM, Shane Kerr  wrote:
> 
> Ondřej,
> 
> Ondřej Surý:
>> as far as I could find on the Internet there are only SIG(0) implementation 
>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I 
>> haven’t found; no mentions of real deployment was found over the Internet 
>> (but you can blame Google for that)...
>> 
>> Do people think the SIG(0) is something that we should keep in DNS and it 
>> will be used in the future or it is a good candidate for throwing off the 
>> boat?
> 
> My guess is that any time you ask this working group if a feature is
> important in DNS, the answer will be "yes", even if not a single system
> is using it anywhere on the Internet and beyond.
> 
> I wonder if there is any metric that dnsop would agree on to determine
> whether a DNS feature is useful or not?
> 
> Cheers,
> 
> —
> Shane

To be fair, he asked if it would be used in the future and that’s hard to 
measure. But given that the community hasn’t concentrated on security as much 
in the past as it will in the future, it seems that throwing security measures 
off the boat is premature.

Tom

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

Re: [DNSOP] SIG(0) useful (and used?)

[Shane Kerr]

Ondřej,

Ondřej Surý:
> as far as I could find on the Internet there are only SIG(0) implementation 
> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I 
> haven’t found; no mentions of real deployment was found over the Internet 
> (but you can blame Google for that)...
> 
> Do people think the SIG(0) is something that we should keep in DNS and it 
> will be used in the future or it is a good candidate for throwing off the 
> boat?

My guess is that any time you ask this working group if a feature is
important in DNS, the answer will be "yes", even if not a single system
is using it anywhere on the Internet and beyond.

I wonder if there is any metric that dnsop would agree on to determine
whether a DNS feature is useful or not?

Cheers,

--
Shane

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

Re: [DNSOP] SIG(0) useful (and used?)

[Tom Pusateri]

> On Jun 19, 2018, at 4:48 PM, Ondřej Surý  wrote:
> 
> 
> Do people think the SIG(0) is something that we should keep in DNS and it 
> will be used in the future or it is a good candidate for throwing off the 
> boat?
> 
> Ondrej

As far as I can tell, SIG(0) is the only mechanism in DNS to ensure the 
question you asked is being answered as well as ensuring that all of the 
responses from the server are included.

DNSSEC will tell you the answer you get is correct but it could be a to a 
different question or be incomplete.

This would seem to be an important tool in the toolbox as we move forward into 
more private and secure DNS.

Tom


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

Re: [DNSOP] SIG(0) useful (and used?)

[Ted Lemon]

You might get a kick out of this expired but soon-to-be-revived document in
DNSSD: https://tools.ietf.org/html/draft-sctl-service-registration-00

The principle is a bit different than what you're doing because there's no
DHCP (necessarily) involved, but otherwise it's the same basic idea.

On Wed, Jun 20, 2018 at 7:27 AM, Bjørn Mork  wrote:

> Well  Mark did propose this many years ago:
> https://mailman.nanog.org/pipermail/nanog/2013-October/061619.html
>
> And based on that, I created a half-assed implementation using Net::DNS.
> Of course I never got around to polishing it up enough to actually put
> it into production. And definitely not to let the public see it...
>
> But it is still there on the TODO list in the back of my head, for one
> of those days when you suddenly have 20 hours to spare and nothing
> better to do.  Might happen.  You never know.  Or someone else will pick
> up the idea.  That's more likely, I guess.
>
> Anyway, I'd hate to see a potentionally useful feature like SIG(0) go
> away for no obvious gain.
>
>
>
> Bjørn
>
>
> Ondřej Surý  writes:
>
> > But if nobody uses that and nobody else implements this, it sort of
> beats the usefulness of the feature.
> >
> > Ondrej
> > --
> > Ondřej Surý — ISC
> >
> >> On 19 Jun 2018, at 23:20, Mark Andrews  wrote:
> >>
> >> SIG(0) is much superior for machines updating their own data  to TSIG
> as you don’t need a secondary storage for the TSIG key.   You can replace a
> master server without having to worry about transferring TSIG secrets off a
> dead machine. You just copy the zone from a slave and go.
> >>
> >> There are other scenarios where it is also superior like automaton
> delegating  In the reverse tree.
> >>
> >> No I don’t think it should go.
> >>
> >> It should be widely implemented so it can be used. There is a lot of
> self fulfilling prophecy in the DNS of people will never is this so we
> won’t implement it.
> >>
> >> --
> >> Mark Andrews
> >>
> >>> On 20 Jun 2018, at 06:48, Ondřej Surý  wrote:
> >>>
> >>> Hi,
> >>>
> >>> as far as I could find on the Internet there are only SIG(0)
> implementation in handful DNS implementations - BIND, PHP Net_DNS2 PHP
> library, Net::DNS(::Sec) Perl library, trust_dns written in Rust and
> perhaps others I haven’t found; no mentions of real deployment was found
> over the Internet (but you can blame Google for that)...
> >>>
> >>> Do people think the SIG(0) is something that we should keep in DNS and
> it will be used in the future or it is a good candidate for throwing off
> the boat?
> >>>
> >>> Ondrej
> >>> --
> >>> Ondřej Surý
> >>> ond...@isc.org
> >>>
> >>> ___
> >>> DNSOP mailing list
> >>> DNSOP@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dnsop
> >>
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SIG(0) useful (and used?)

[Bjørn Mork]

Well  Mark did propose this many years ago:
https://mailman.nanog.org/pipermail/nanog/2013-October/061619.html

And based on that, I created a half-assed implementation using Net::DNS.
Of course I never got around to polishing it up enough to actually put
it into production. And definitely not to let the public see it...

But it is still there on the TODO list in the back of my head, for one
of those days when you suddenly have 20 hours to spare and nothing
better to do.  Might happen.  You never know.  Or someone else will pick
up the idea.  That's more likely, I guess.

Anyway, I'd hate to see a potentionally useful feature like SIG(0) go
away for no obvious gain.



Bjørn


Ondřej Surý  writes:

> But if nobody uses that and nobody else implements this, it sort of beats the 
> usefulness of the feature.
>
> Ondrej
> --
> Ondřej Surý — ISC
>
>> On 19 Jun 2018, at 23:20, Mark Andrews  wrote:
>> 
>> SIG(0) is much superior for machines updating their own data  to TSIG as you 
>> don’t need a secondary storage for the TSIG key.   You can replace a master 
>> server without having to worry about transferring TSIG secrets off a dead 
>> machine. You just copy the zone from a slave and go.
>> 
>> There are other scenarios where it is also superior like automaton 
>> delegating  In the reverse tree.
>> 
>> No I don’t think it should go. 
>> 
>> It should be widely implemented so it can be used. There is a lot of self 
>> fulfilling prophecy in the DNS of people will never is this so we won’t 
>> implement it. 
>> 
>> -- 
>> Mark Andrews
>> 
>>> On 20 Jun 2018, at 06:48, Ondřej Surý  wrote:
>>> 
>>> Hi,
>>> 
>>> as far as I could find on the Internet there are only SIG(0) implementation 
>>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
>>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others 
>>> I haven’t found; no mentions of real deployment was found over the Internet 
>>> (but you can blame Google for that)...
>>> 
>>> Do people think the SIG(0) is something that we should keep in DNS and it 
>>> will be used in the future or it is a good candidate for throwing off the 
>>> boat?
>>> 
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@isc.org
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] SIG(0) useful (and used?)

[Tony Finch]

Wellington, Brian  wrote:

> SIG(0) was implemented in BIND 9 back when BIND 9 was basically the only
> modern implementation, and no one used it then.

I think the problem is it isn't a complete implementation: you can't use
SIG(0) in all the places you can use TSIG. The TKEY support seems to be
specific to Kerberos, whereas broader support would make it a neat way to
use slow SIG(0) to establish fast TSIG session keys.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: In southeast, cyclonic 6 or 7 decreasing 4 or 5 later, otherwise
northeasterly, backing northerly later, 4 or 5, occasionally 6 in northwest.
Moderate. Rain or thundery showers. Good occasionally poor.

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

Re: [DNSOP] SIG(0) useful (and used?)

[Tony Finch]

Ondřej Surý  wrote:

> But is it really used like this? Or will it ever?

My point was that SIG(0) has use cases that are currently impossible
because of lack of implementations. So it's really hard to tell if it is
worth the effort. It's like trying to judge the need for a bridge by
counting the number of peopple swimming across the river.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire: Variable 4, becoming northwest 4 or 5, occasionally 6
later. Moderate, occasionally rough at first in north. Rain then showers.
Good, occasionally poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SIG(0) useful (and used?)

[Mark Elkins]

I run bind on my authoritative nameservers. I run linux on a number of
laptops. When these laptops are provided a DHCP address, they use SIG(0)
to authenticate a forwards zone update to update their current (DHCP
provided) IPv4 address into the Zone. I've been doing this for years -
ever since Johan Ihrén taught me how to do so on his DNS training
courses. A number of other people may also be doing this for the same
reason. This is totally automatic - just once in a while, I update the
SIG(0) "password".

If there is another newer way that does the same - I'd be willing to
look at it - otherwise I enjoy this current methodology.


On 19/06/2018 23:41, Wellington, Brian wrote:
> SIG(0) was implemented in BIND 9 back when BIND 9 was basically the only 
> modern implementation, and no one used it then.  The fact that no servers 
> have implemented it since then means that there really isn’t any demand.
>
> Brian  
>
>> On Jun 19, 2018, at 2:20 PM, Mark Andrews  wrote:
>>
>> SIG(0) is much superior for machines updating their own data  to TSIG as you 
>> don’t need a secondary storage for the TSIG key.   You can replace a master 
>> server without having to worry about transferring TSIG secrets off a dead 
>> machine. You just copy the zone from a slave and go.
>>
>> There are other scenarios where it is also superior like automaton 
>> delegating  In the reverse tree.
>>
>> No I don’t think it should go. 
>>
>> It should be widely implemented so it can be used. There is a lot of self 
>> fulfilling prophecy in the DNS of people will never is this so we won’t 
>> implement it. 
>>
>> -- 
>> Mark Andrews
>>
>>> On 20 Jun 2018, at 06:48, Ondřej Surý  wrote:
>>>
>>> Hi,
>>>
>>> as far as I could find on the Internet there are only SIG(0) implementation 
>>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
>>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others 
>>> I haven’t found; no mentions of real deployment was found over the Internet 
>>> (but you can blame Google for that)...
>>>
>>> Do people think the SIG(0) is something that we should keep in DNS and it 
>>> will be used in the future or it is a good candidate for throwing off the 
>>> boat?
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@isc.org
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

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

Re: [DNSOP] SIG(0) useful (and used?)

[Mark Andrews]

SIG(0) has miles of potential.  Active Directory shows that hosts updating 
their own addresses is useful.

SIG(0) provides a similar mechanism without the overhead of AD.   It actually 
works well today if you spend the time to hook it into a system.  What’s needed 
is for OS vendors to ship machines with support enabled.

Use AD if the machine is part of  a AD domain and this if it isn’t.
It really isn’t that hard to do it just requires OS developers to do it.

-- 
Mark Andrews

> On 20 Jun 2018, at 07:33, Ondřej Surý  wrote:
> 
> But if nobody uses that and nobody else implements this, it sort of beats the 
> usefulness of the feature.
> 
> Ondrej
> --
> Ondřej Surý — ISC
> 
>> On 19 Jun 2018, at 23:20, Mark Andrews  wrote:
>> 
>> SIG(0) is much superior for machines updating their own data  to TSIG as you 
>> don’t need a secondary storage for the TSIG key.   You can replace a master 
>> server without having to worry about transferring TSIG secrets off a dead 
>> machine. You just copy the zone from a slave and go.
>> 
>> There are other scenarios where it is also superior like automaton 
>> delegating  In the reverse tree.
>> 
>> No I don’t think it should go. 
>> 
>> It should be widely implemented so it can be used. There is a lot of self 
>> fulfilling prophecy in the DNS of people will never is this so we won’t 
>> implement it. 
>> 
>> -- 
>> Mark Andrews
>> 
>>> On 20 Jun 2018, at 06:48, Ondřej Surý  wrote:
>>> 
>>> Hi,
>>> 
>>> as far as I could find on the Internet there are only SIG(0) implementation 
>>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
>>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others 
>>> I haven’t found; no mentions of real deployment was found over the Internet 
>>> (but you can blame Google for that)...
>>> 
>>> Do people think the SIG(0) is something that we should keep in DNS and it 
>>> will be used in the future or it is a good candidate for throwing off the 
>>> boat?
>>> 
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@isc.org
>>> 
>>> ___
>>> 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] SIG(0) useful (and used?)

[Wellington, Brian]

SIG(0) was implemented in BIND 9 back when BIND 9 was basically the only modern 
implementation, and no one used it then.  The fact that no servers have 
implemented it since then means that there really isn’t any demand.

Brian  

> On Jun 19, 2018, at 2:20 PM, Mark Andrews  wrote:
> 
> SIG(0) is much superior for machines updating their own data  to TSIG as you 
> don’t need a secondary storage for the TSIG key.   You can replace a master 
> server without having to worry about transferring TSIG secrets off a dead 
> machine. You just copy the zone from a slave and go.
> 
> There are other scenarios where it is also superior like automaton delegating 
>  In the reverse tree.
> 
> No I don’t think it should go. 
> 
> It should be widely implemented so it can be used. There is a lot of self 
> fulfilling prophecy in the DNS of people will never is this so we won’t 
> implement it. 
> 
> -- 
> Mark Andrews
> 
>> On 20 Jun 2018, at 06:48, Ondřej Surý  wrote:
>> 
>> Hi,
>> 
>> as far as I could find on the Internet there are only SIG(0) implementation 
>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I 
>> haven’t found; no mentions of real deployment was found over the Internet 
>> (but you can blame Google for that)...
>> 
>> Do people think the SIG(0) is something that we should keep in DNS and it 
>> will be used in the future or it is a good candidate for throwing off the 
>> boat?
>> 
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>> 
>> ___
>> 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



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

Re: [DNSOP] SIG(0) useful (and used?)

[Ondřej Surý]

But if nobody uses that and nobody else implements this, it sort of beats the 
usefulness of the feature.

Ondrej
--
Ondřej Surý — ISC

> On 19 Jun 2018, at 23:20, Mark Andrews  wrote:
> 
> SIG(0) is much superior for machines updating their own data  to TSIG as you 
> don’t need a secondary storage for the TSIG key.   You can replace a master 
> server without having to worry about transferring TSIG secrets off a dead 
> machine. You just copy the zone from a slave and go.
> 
> There are other scenarios where it is also superior like automaton delegating 
>  In the reverse tree.
> 
> No I don’t think it should go. 
> 
> It should be widely implemented so it can be used. There is a lot of self 
> fulfilling prophecy in the DNS of people will never is this so we won’t 
> implement it. 
> 
> -- 
> Mark Andrews
> 
>> On 20 Jun 2018, at 06:48, Ondřej Surý  wrote:
>> 
>> Hi,
>> 
>> as far as I could find on the Internet there are only SIG(0) implementation 
>> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
>> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I 
>> haven’t found; no mentions of real deployment was found over the Internet 
>> (but you can blame Google for that)...
>> 
>> Do people think the SIG(0) is something that we should keep in DNS and it 
>> will be used in the future or it is a good candidate for throwing off the 
>> boat?
>> 
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>> 
>> ___
>> 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] SIG(0) useful (and used?)

[Mark Andrews]

SIG(0) is much superior for machines updating their own data  to TSIG as you 
don’t need a secondary storage for the TSIG key.   You can replace a master 
server without having to worry about transferring TSIG secrets off a dead 
machine. You just copy the zone from a slave and go.

There are other scenarios where it is also superior like automaton delegating  
In the reverse tree.

No I don’t think it should go. 

It should be widely implemented so it can be used. There is a lot of self 
fulfilling prophecy in the DNS of people will never is this so we won’t 
implement it. 

-- 
Mark Andrews

> On 20 Jun 2018, at 06:48, Ondřej Surý  wrote:
> 
> Hi,
> 
> as far as I could find on the Internet there are only SIG(0) implementation 
> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, 
> Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I 
> haven’t found; no mentions of real deployment was found over the Internet 
> (but you can blame Google for that)...
> 
> Do people think the SIG(0) is something that we should keep in DNS and it 
> will be used in the future or it is a good candidate for throwing off the 
> boat?
> 
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
> 
> ___
> 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] SIG(0) useful (and used?)

[Ondřej Surý]

But is it really used like this? Or will it ever?

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 19 Jun 2018, at 23:04, Tony Finch  wrote:
> 
> Ondřej Surý  wrote:
>> 
>> Do people think the SIG(0) is something that we should keep in DNS and
>> it will be used in the future or it is a good candidate for throwing off
>> the boat?
> 
> SIG(0) is the only DNS feature that (could) allow unauthenticated client
> access to an authenticated server, which would allow
> 
> * secure inteerface to resolver (maybe with SIG(0) + TKEY -> TSIG,
>  but now  probably better to use TLS or DoH)
> 
> * secure stealth secondaries (maybe TLS support would be better)
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> an equitable and peaceful international order

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