Re: [DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

[Bob Harold]

On Wed, Apr 11, 2018 at 8:55 AM, Joe Abley  wrote:

> Hi Bob,
>
> On Apr 11, 2018, at 08:50, Bob Harold  wrote:
>
> > In various places, like 4.3.  TSIG Record Format, "resolver and server"
> is used which seems a little vague to me, since I use TSIG between master
> and slave authoritative servers, neither of which is a resolver.  Would it
> make sense to use "sender and receiver" ?  Or 6.5.4. uses "client" and
> "server" and that would work, if used consistently everywhere.
>
> Since you can send and receive both responses and queries, I prefer
> "initiator" and "responder" to "sender" and "receiver". I think I
> first saw those terms used in one of Vixie's drafts, and I liked them.
>
> "Client" and "server" have semantic overtones (e.g. relating to end
> users and services) and I find them less precise unless the context is
> very clear.
>
>
> Joe
>

Agreed.   "initiator" and "responder" is better, I just could not think of
the right term.

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

Re: [DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

[Bob Harold]

On Tue, Apr 10, 2018 at 4:57 PM, 神明達哉  wrote:

> At Tue, 10 Apr 2018 14:56:53 -0400,
> tjw ietf  wrote:
>
> > This draft was widely accepted in Singapore, and the chairs were waiting
> for
> > a revision before starting a call for adoption. That revision took a few
> > months
> > but it has been done and DNSOP is ready to start a call for adoption.
> >
> > This draft addresess the bug found in the existing RFC.
> >
> > This starts a Call for Adoption for draft-dupont-dnsop-rfc2845bis
> >
> > The draft is available here:
> > https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/
> >
> > Please review this draft to see if you think it is suitable for adoption
> > by DNSOP, and comments to the list, clearly stating your view.
>
> I support the adoption.  I've already reviewed the draft and provided
> (minor) feedback:
> https://www.ietf.org/mail-archive/web/dnsop/current/msg22063.html
>
> --
> JINMEI, Tatuya
>
>
> I support adoption.

In various places, like 4.3.  TSIG Record Format, "resolver and server" is
used which seems a little vague to me, since I use TSIG between master and
slave authoritative servers, neither of which is a resolver.  Would it make
sense to use "sender and receiver" ?  Or 6.5.4. uses "client" and "server"
and that would work, if used consistently everywhere.

6.5.1.  Key check and error handling
Why is this only for a "non-forwarding server" ? --- Answer is in 6.7, A
reference to there might be helpful.

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

Re: [DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

[Joe Abley]

Hi Bob,

On Apr 11, 2018, at 08:50, Bob Harold  wrote:

> In various places, like 4.3.  TSIG Record Format, "resolver and server" is 
> used which seems a little vague to me, since I use TSIG between master and 
> slave authoritative servers, neither of which is a resolver.  Would it make 
> sense to use "sender and receiver" ?  Or 6.5.4. uses "client" and "server" 
> and that would work, if used consistently everywhere.

Since you can send and receive both responses and queries, I prefer
"initiator" and "responder" to "sender" and "receiver". I think I
first saw those terms used in one of Vixie's drafts, and I liked them.

"Client" and "server" have semantic overtones (e.g. relating to end
users and services) and I find them less precise unless the context is
very clear.


Joe

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

Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

[Michael StJohns]

Sorry its taken me so long to get back to this.


On 3/31/2018 7:09 PM, Tony Finch wrote:

There are a few pertinent differences between trust anchor witnesses and
the undeployed RFC 5011 many-keys setup:

* in RFC 5011 each key is completely trusted, whereas no witness is
   trusted; compromise of an RFC 5011 key compromises the whole system,
   whereas compromise of a witness is equivalent to unavailability (up
   to the quorum size);

* RFC 5011 requires close co-operation between key holders for updating
   the DNSKEY RRset and its signatures, whereas trust anchor witnesses
   operate independently.

* Part of the circular dependency loop is accurate time, and it's easy to
   get trust anchor witnesses to tell you the time as well; not so easy
   purely within the DNS.

Tony.


You forgot:

* A 5011 trust system is maintained as part of the root zone - as long 
as the root zone is maintained, the 5011 trust system is maintained.


* The "requires close cooperation" bullet is just wrong.  It turns out 
that the SPECIFIC mechanism they're currently using requires everyone to 
show up in a certain place, but that's an artifact of process, not of 
protocol.  (Happy to sketch out a different protocol - its pretty 
straight forward).


* But time also requires a source of trust - if you can spoof enough 
witnesses, you can spoof time.  In any event, time is irrelevant  at the 
system level- each relying party is responsible for figuring out its 
source of time - in both systems.



One of the reasons I went away was to try and figure out how to 
accurately analyze your approach.


Before you start down this approach, you need to figure out at least a 
few parameters:


1) How many total witnesses?  (Since you won't be maintaining the 
system, these are all there ever will be)


2) How many of the witnesses are enough to assume trust?

3) How long do you want this system to work?


It turns out that the lifetime of an un-maintained M of N system has 
exactly the same characteristics as a nuclear decay analysis. E.g. Given 
a starting population of N, an ending population of M and a period of Y, 
what is the half-life of the system?   From the half-life of the system, 
you can calculate the minimum average mean time to failure of any given 
witness.


And its nice that there is this 
http://www.calculator.net/half-life-calculator.html online.


So let's start out with a 3 of 10 system with a required lifetime of 20 
years (240 months).  The half-life of the system is 138.2 months and the 
average required MTTF is 199 months or about 16.5 years.   That means 
that you have to expect that any given witness will be around and 
available AT the place it was originally available at for around 17 years.


It gets better with more witnesses, say 3 of 15:  149 months or about 
12.5 years MTTF.  That's a bit better, but that's an average - you still 
have to ensure that 3 of those systems will be around for the 20 years, 
and you have to ensure they aren't compromised in the mean time.


But it gets worse if you increase the number of required witnesses - say 
5 of 15 - 218 months or a required average MTTF of 18.2 years for that 
set of 15 witnesses.


Now you could add a maintenance protocol, and the ability to add and 
delete witnesses, but guess what - you end up looking like 5011, but 
with the problem of how to manage the trust set of the trust set.


This reminds me of the "Turtles all the way down" recursion.


Later, Mike




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

[DNSOP] Appointment of 3rd chair for DNSOP.

[Warren Kumari]

Dear WG,

As I mentioned in London, Im appointing a 3rd chair for DNSOP, to help
with the load, etc.

A number of people kindly volunteered, and I had a really hard time
selecting from such qualified candidates.  After agonizing over it for
a few weeks, I've decided to appoint Benno Overeinder.

Benno is new to the chairing role, so please go easy on him for the
first while as he learns the ropes -- I'm confident Suzanne and Tim
(and all of the WG!) will be willing to help him get spun up.

I'd like to thank everyone again who volunteered, I really appreciate
your willingness to serve,
   W
-- 
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] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[George Michaelson]

I'd like the WG to close on this. It feels to me like we've had useful
edit in the call and the document is now stable and ready to move onto
the next phase.

Ship it.

-George

On Fri, Apr 6, 2018 at 2:35 AM, tjw ietf  wrote:
>
> After walking through the 168 emails on this draft in the inbox, I feel
> we're ready to take this to WGLC.
>
> (We are aware of the two points raised my Job and Paul)
>
>
> This starts a Working Group Last Call for:
> draft-ietf-dnsop-kskroll-sentinel
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>
> The Current Intended Status of this document is: Proposed Standard
>
> In the brushing of the camel, the draft is focused on determining if
> a particular root key has been loaded into resolvers.
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> if someone feels the document is *not* ready for publication, please speak
> out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on:  23:59
> 19 April 2018
>
> thanks
> tim
>
>
> ___
> 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