On Fri, 29 May 2020, Peter van Dijk wrote:
I'm not even sure what my question is, so let's try this: if a
malicious parent has the ability to publish a malicious DS record, why
wouldn't that parent also change the NS records in some subtle way?
Then the real client side CDS becomes invisible. I
On Fri, 2020-05-29 at 11:59 -0400, Paul Wouters wrote:
> On Fri, 29 May 2020, Peter van Dijk wrote:
>
> > > - Takes DNSKEY, only does syntax checks ---> we dont need to publish
> > > anything
> >
> > Yes.
>
> Actually I was wrong. We still need to publish something so the child
> proves the
On Fri, 2020-05-29 at 11:31 -0400, Paul Wouters wrote:
>
> Note for DNSKEY algorithm, we could use 253 or 254:
>
> https://tools.ietf.org/html/rfc4034#appendix-A.1.1
>
> DNS software might already support ignoring these algorithms without
> adding too much noise to the DNSSEC validation process
On Fri, 29 May 2020, Peter van Dijk wrote:
- Takes DS, but verifies it is a real DNSKEY at the child --> we create bogus
DNSKEY matching our DS request
I am hoping, also for 'normal' DNSSEC reasons (like key rolls) that no
registry does this.
Yes, hopefully, they will limit themselves to
On Fri, 2020-05-29 at 11:25 -0400, Paul Wouters wrote:
> On Fri, 29 May 2020, Peter van Dijk wrote:
>
> > On Wed, 2020-05-27 at 21:27 -0400, Paul Wouters wrote:
> > > It would make everything a LOT cleaner and we got no bogus
> > > DNSKEY records to ignore in our DNSSEC validation path.
> >
> >
Note for DNSKEY algorithm, we could use 253 or 254:
https://tools.ietf.org/html/rfc4034#appendix-A.1.1
A.1.1. Private Algorithm Types
Algorithm number 253 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the
On Fri, 29 May 2020, Peter van Dijk wrote:
On Wed, 2020-05-27 at 21:27 -0400, Paul Wouters wrote:
It would make everything a LOT cleaner and we got no bogus
DNSKEY records to ignore in our DNSSEC validation path.
What bogus DNSKEY records?
It really all depends on what registry systems you
Peter van Dijk wrote:
> On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote:
> >
> > This made me wonder if this pseudorecord should be a KEY instead, and then
> > I wondered how hard it would be to persuade existing code to generate a DS
> > from a KEY.
>
> That could make semantic sense, but
On Thu, 2020-05-28 at 12:08 -0400, Paul Wouters wrote:
> On Thu, 28 May 2020, Petr Špaček wrote:
> > With your proposal auth server operators need to _also_ operate DNS
> > resolver and tie it together with the auth server. That's very significant
> > change from how authoritative servers are
On Thu, 2020-05-28 at 00:43 +0100, Tony Finch wrote:
> Peter van Dijk wrote:
> > On Tue, 2020-05-26 at 09:10 +0200, Ondřej Surý wrote:
> > > 1. Bit 7 of the Flags fields needs to be 0.
> >
> > Definitely [...] I noted earlier that whatever flags we might need, it's
> > definitely *not* ZONE and
On 28. 05. 20 18:08, Paul Wouters wrote:
> On Thu, 28 May 2020, Petr Špaček wrote:
>
>> Is there any indication that TLS libraries are going to implement this?
>> (Unmerged patches do not count!)
>
> I thought "indication" to implement would be uhm, unmerged patches?
> Otherwise, it would be
11 matches
Mail list logo
