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

From: Ondřej Surý <[email-masked]>
Date: Tue, 19 Jun 2018 22:48:09 +0200

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ý
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Jun 2018 22:04:01 +0100

Ondřej Surý <[email-masked]> 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.finch  <[email-masked]>  http://dotat.at/
an equitable and peaceful international order

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 19 Jun 2018 23:07:39 +0200

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

Ondrej
--
Ondřej Surý
[email-masked]

> On 19 Jun 2018, at 23:04, Tony Finch <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2018 07:20:54 +1000

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ý <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 19 Jun 2018 23:33:32 +0200

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 <[email-masked]> wrote:
>

---

From: "Wellington, Brian" <[email-masked]>
Date: Tue, 19 Jun 2018 21:41:33 +0000

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 <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2018 07:47:16 +1000

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ý <[email-masked]> wrote:
>

---

From: Mark Elkins <[email-masked]>
Date: Wed, 20 Jun 2018 09:49:17 +0200

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.

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 20 Jun 2018 09:50:56 +0100

> 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.finch  <[email-masked]>  http://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.

---

From: Tony Finch <[email-masked]>
Date: Wed, 20 Jun 2018 10:05:54 +0100

Wellington, Brian <bwelling=[email-masked]> 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.finch  <[email-masked]>  http://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.

---

From: Bjørn Mork <[email-masked]>
Date: Wed, 20 Jun 2018 13:27:13 +0200

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Jun 2018 10:17:35 -0400

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 <[email-masked]> 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.
> >>
> >> 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
> >>
> >>> 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)...
> >>>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 20 Jun 2018 10:59:36 -0400

> On Jun 19, 2018, at 4:48 PM, Ondřej Surý <[email-masked]> wrote:
> 
> 

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

---

From: Shane Kerr <[email-masked]>
Date: Wed, 20 Jun 2018 19:23:00 +0000

Ondřej,

> 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

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 20 Jun 2018 16:06:43 -0400

> On Jun 20, 2018, at 3:23 PM, Shane Kerr <[email-masked]> wrote:
> 
> Ondřej,
> 
> Ondřej Surý:
> —

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Jun 2018 19:07:17 -0400

> * secure stealth secondaries (maybe TLS support would be better)
​<no hats>​

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

> an equitable and peaceful international
> order_______________________________________________
> DNSOP mailing list
> [email-masked]

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Jun 2018 19:13:53 -0400

Warren Kumari wrote:
> ...
> ​<no hats>​
>
> ​... 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 :-))

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:

> ...
> next to the nameserver, and <handwave> 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

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Jun 2018 16:30:02 -0700

On Jun 20, 2018, at 19:07, Warren Kumari <[email-masked]> wrote:

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

Joe

---

From: Shumon Huque <[email-masked]>
Date: Wed, 20 Jun 2018 21:05:42 -0400

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

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 21 Jun 2018 06:19:33 +0200

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

---

From: Joe Abley <[email-masked]>
Date: Thu, 21 Jun 2018 04:52:14 -0400

On Jun 20, 2018, at 21:05, Shumon Huque <[email-masked]> wrote:

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

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 21 Jun 2018 08:04:58 -0400

> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát <[email-masked]> wrote:
> 

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 <http://foo.example.com/> and the recursive resolver modifies this query to foo.exampl.com <http://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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 21 Jun 2018 09:55:01 -0400

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

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

---

From: [email-masked]
Date: Thu, 21 Jun 2018 16:20:41 +0100

> On 21 Jun 2018, at 00:13, Paul Vixie <[email-masked]> wrote:
> 
> ...
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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 Jun 2018 12:53:14 -0400

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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 Jun 2018 13:40:50 -0400

On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri <[email-masked]> wrote:

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

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 21 Jun 2018 15:31:50 -0400

> On Jun 21, 2018, at 1:40 PM, Shumon Huque <[email-masked]> wrote:
> 
> On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 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.
>  
> 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.
>  
> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Jun 2018 18:27:37 -0400

Why would that make a difference?

On Thu, Jun 21, 2018 at 3:34 PM Tom Pusateri <[email-masked]> wrote:

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

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 22 Jun 2018 15:41:36 +0200

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Jun 2018 09:47:05 -0400

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.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 22 Jun 2018 12:12:08 -0400

On Fri, Jun 22, 2018 at 12:05 PM Tom Pusateri <[email-masked]> 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.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 22 Jun 2018 14:30:25 -0400

> 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 <
> [email-masked]> wrote:
>

---

From: Evan Hunt <[email-masked]>
Date: Fri, 22 Jun 2018 18:49:25 +0000

> use slow SIG(0) to establish fast TSIG session keys.

This matches my own intuition. "A clear idea of what to do about it" has
been slow in coming, but I think you're right.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 23 Jun 2018 21:14:49 +0000

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