On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters wrote:
> On Wed, 8 Nov 2017, Edward Lewis wrote:
>
> This is why the guidance in "Protocol Modifications for the DNS Security
>> Extensions" leads to "any" chain. "Clarifications and Implementation Notes
>> for DNS Security (DNSSEC)" opens the possibi
On 11/9/17, 00:01, "DNSOP on behalf of Paul Wouters" wrote:
>"prerogative of the implementer" canont apply to how one defines trust
>in a protocol. You can't have two implementations make different
>trust decisions, especially as most endusers don't control their
>resolver.
The first split I m
On Wed, 8 Nov 2017, Edward Lewis wrote:
This is why the guidance in "Protocol Modifications for the DNS Security Extensions" leads to
"any" chain. "Clarifications and Implementation Notes for DNS Security (DNSSEC)" opens
the possibility that knobs can be included, which is the prerogative of t
On 11/6/17, 10:57, "DNSOP on behalf of Petr Špaček" wrote:
>I did my best to explain my reasoning, let me know if you can see some holes
>in the reasoning.
Coming from my assumption that "use any chain" is the best way to go, I tried
to figure out why you are coming to a different conclusion.
On 6 Nov 2017, at 7:56, Petr Špaček wrote:
2. Vast majority of people will not bother with setting up own trust
anchors. I.e. vast majority of people will not be affected by any
brittlenes you envision.
3. The small fraction of people who configure their own TA do it for a
reason. The reason I
On 6.11.2017 16:15, Paul Hoffman wrote:
> Doesn't "I don't trust my parent's security policy" open up a million
> cans of worms anyway? It feels like making this change to the default
1. The problem is that there were (and certainly will be) successfull
hacks into registries, that seems just inevi
Doesn't "I don't trust my parent's security policy" open up a million
cans of worms anyway? It feels like making this change to the default
behavior will make validation more brittle (because people *will* forget
to update their lower-level trust anchors) in order to help a very small
number of
On 1.11.2017 12:11, Edward Lewis wrote:
> On 10/31/17, 20:50, "DNSOP on behalf of Mark Andrews" on behalf of ma...@isc.org> wrote:
>
>> Secondly doing deepest match on trust anchors is the only secure way to
>> prevent a parent overriding the child zone's security policy.
Even though Knot
This is only about which trust anchors applies for a given name with
you have several configured with different names. Multiple trust
anchors with the same name is still any match will do.
There are enough senarios where you want *only* the closest
trust-anchor to apply that that is what was cod
On 11/2/17, 11:27, "DNSOP on behalf of Warren Kumari" wrote:
> Having a (per-TA) knob sounds like a nice compromise, but I'd really
> like implementors to chime in on how much complexity this adds. If *I*
> added a local TA for .example (or foo.example.com) I'd automatically
> assume that this is
On 11/2/17, 11:04, "Bob Harold" wrote:
>I generally agree with you, but wonder if there is a performance penalty to
>searching every possible path before failing. Is that a reasonable concern?
There are a bunch of tradeoffs to consider. (I'll start with "it is a concern"
but not sure if it's
>Are there cases of "corrupted" registries make the threat of "stolen zones" a
>real thing?
I think the most well known example is the US government taking the .org domain
of Rojadirecta.
https://torrentfreak.com/u-s-returns-seized-domains-to-streaming-links-site-after-18-months-120830/
There w
On 11/1/17, 11:17, "DNSOP on behalf of Ólafur Guðmundsson"
wrote:
>Thus the question is twofold
>
>a) is there need for clarification in how protocol works possibly with
>recommendation for resolver "tunable" settings.
>
This is something that might be fit into -validator-requirements-. (Wh
On 1 Nov 2017, at 6:48, Edward Lewis wrote:
The reason why I'm digging into this is that "things change."
As a recap: this thread started with Moritz quoting from RFC 4035 and
asking:
Did we miss something, or is there indeed clarification needed?
I believe that RFC 4035 indicates succes
On 11/1/17, 08:17, "DNSOP on behalf of Patrik Wallstrom"
wrote:
>If I remember the discussions correctly, there was a sense that the
>resolver decides the local policy. And that yes, those are the three
>options. Perhaps the options should be made more clear in a text somewhere.
The
On 10/31/17, 20:50, "DNSOP on behalf of Mark Andrews" wrote:
>Secondly doing deepest match on trust anchors is the only secure way to
>prevent a parent overriding the child zone's security policy.
By this, do you mean choice of cryptographic algorithm and/or length? To
achieve "independenc
On 10/31/17, 15:52, "DNSOP on behalf of Paul Wouters" wrote:
>this zone can never be stolen from me by a parent.
Can you elaborate on this, what do you mean "stolen" by a parent?
The reason I am asking - choosing one strategy (any key, configured key rules,
DS rules) is based on what one mo
In message <59f8d666.9000...@redbarn.org>, Paul Vixie writes:
>
>
> Paul Wouters wrote:
> > On Tue, 31 Oct 2017, Edward Lewis wrote:
> >
> ...
> ConfiguredKey-trumps-DS
> ...
> >>
> >>> It better, it is the only working solution :)
> >>
> >> Can you elaborate...why would it be the "only" "w
Paul Wouters wrote:
On Tue, 31 Oct 2017, Edward Lewis wrote:
...
ConfiguredKey-trumps-DS
...
It better, it is the only working solution :)
Can you elaborate...why would it be the "only" "working" solution?
The idea of the hierarchical model has always been that if you don't
trust the
On Tue, 31 Oct 2017, Edward Lewis wrote:
Any-TrustedKey-works
ConfiguredKey-trumps-DS
DS-trumps-configuredKey
But I suspect the middle one is implemented
It better, it is the only working solution :)
Can you elaborate...why would it be the "only" "working" solution?
The idea of the hiera
On 10/31/17, 14:30, "DNSOP on behalf of Paul Wouters" wrote:
> On Oct 31, 2017, at 22:25, Ólafur Guðmundsson wrote:
>>
>> There are three ways to treat this case:
>> Any-TrustedKey-works
>> ConfiguredKey-trumps-DS
>> DS-trumps-configuredKey
>>
>> But I suspect the middle one is implemented
21 matches
Mail list logo
