Paul: Thanks for the explanation, it clears up a fair bit for me.
Replies inline.
On 03/20/2018 09:48 AM, Paul Wouters wrote:
> On Tue, 20 Mar 2018, Michael Casadevall wrote:
>
>> Without the RRtypes logged, I'm not seeing how you're supposed to be
>> able to audit them. In the case where a KSK is
On Tue, 20 Mar 2018, Michael Casadevall wrote:
Certificate Transparency works because specifically because the entire
certificate is uploaded, and (assuming a valid cert) a SCT is generated
which can be verified by cross-checking it against the log servers
public key.
Without the RRtypes logged
On 03/20/2018 07:44 AM, Paul Wouters wrote:
> The goal of the document is to make such malicious changes visible.
>
> If the parent needs to replace NS/DS records, these are easily
> auditable identically to Certificate Transparency (rfc 6962bis)
> We only need to look (log) the DS/DNSKEY and we
On Tue, 20 Mar 2018, Stephane Bortzmeyer wrote:
The 'delegation-only' flag does not *by itself* prevent parent
domains from answering authoritatively for their child domains, but
it could make "certificate-transparency" more tractable for DNSSEC.
I don't think that you replied to Bob's remark.
On Mon, Mar 19, 2018 at 07:49:45PM +,
Viktor Dukhovni wrote
a message of 30 lines which said:
> The 'delegation-only' flag does not *by itself* prevent parent
> domains from answering authoritatively for their child domains, but
> it could make "certificate-transparency" more tractable for
Paul Wouters wrote:
> On Mon, 19 Mar 2018, Robert Edmonds wrote:
>
> > Viktor Dukhovni wrote:
> > > The idea is to log the DNSKEY RRs observed at each zone apex.
> > > Without the proposed flag, one would also have to log denial of
> > > existence which would make the logs much too large.
> >
> >
On Mon, 19 Mar 2018, Stephane Bortzmeyer wrote:
I'm opposed to this idea.
Can you clarify whether you oppose to be a user of this new flag, or
whether you oppose of giving others the option of using this flag?
While the root and TLD zones are asumed to be almost exclusively
delegation-only z
On Mon, 19 Mar 2018, Robert Edmonds wrote:
Viktor Dukhovni wrote:
The idea is to log the DNSKEY RRs observed at each zone apex.
Without the proposed flag, one would also have to log denial of
existence which would make the logs much too large.
Can you expand on what you mean by "much too larg
Viktor Dukhovni wrote:
> The idea is to log the DNSKEY RRs observed at each zone apex.
> Without the proposed flag, one would also have to log denial of
> existence which would make the logs much too large.
Can you expand on what you mean by "much too large"? There are already
existing large scale
On Mon, Mar 19, 2018 at 02:12:38PM -0400, Bob Harold wrote:
> > > We have just submitted a draft aimed at increasing the security of
> > > the DNSSEC with respect to the power that parental zones have over
> > > their children.
> >
> > I'm opposed to this idea.
>
> If the parent simply pointed the
On Mon, Mar 19, 2018 at 12:34 PM, Stephane Bortzmeyer
wrote:
> On Mon, Mar 19, 2018 at 08:22:03AM -0400,
> Paul Wouters wrote
> a message of 57 lines which said:
>
> > We have just submitted a draft aimed at increasing the security of
> > the DNSSEC with respect to the power that parental zone
On Mon, Mar 19, 2018 at 08:22:03AM -0400,
Paul Wouters wrote
a message of 57 lines which said:
> We have just submitted a draft aimed at increasing the security of
> the DNSSEC with respect to the power that parental zones have over
> their children.
I'm opposed to this idea.
> While the roo
We have just submitted a draft aimed at increasing the security of the DNSSEC
with respect to the power that parental zones have over their children.
The aim of this draft is twofold:
1) Allow zones to publicly commit to being delegation_only zones.
The aim here is to counter the argument that
13 matches
Mail list logo
