Hi Rob,
One can do a bit of semi-generic analysis here to help motivate 12 bytes as
being a tolerable choice (one could make some argument for 32 being the
right length to actually use, but the protocol-mandated floor does not
necessarilly need to be the "full protection" value as there can be
Hi Rob,
I'm not aware of any precise analysis supporting the 12 byte minimum
size but I believe it is reasonable and in line with the lower end of
the range of hash sizes typically standardized by the IETF these days.
Thanks,
Donald
===
Donald E. Eastlake 3rd
> On Oct 7, 2020, at 11:55 PM, Murray Kucherawy via Datatracker
> wrote:
>
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: No Objection
Hi Murray, thanks for the comments.
>
>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Message Digest for DNS Zones
Authors : Duane Wessels
Piet Barber
> On Oct 9, 2020, at 12:08 PM, Ben Schwartz wrote:
>
>
> 6.2. Use of Multiple ZONEMD Hash Algorithms
>
>When a zone publishes multiple ZONEMD RRs, the overall security is
>only as good as the weakest hash algorithm in use.
>
> Why not require recipients to verify all digests with
On Fri, Oct 9, 2020, 2:36 PM Wessels, Duane wrote:
>
>
> > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-dnsop-dns-zone-digest-12: No Objection
> >
> >
> >
> On Oct 7, 2020, at 1:52 PM, Roman Danyliw wrote:
>
>
> In that case (where no assumptions are made about the transport), it seems
> that only these scenarios from the list above apply:
>
> With an on-path attacker (and trusted server hosting the zone file)
>
> ** No DNSSEC = integrity:
> On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker
> wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: No Objection
>
>
> --
> COMMENT:
>
This starts a Working Group Last Call for draft-ietf-dnsop-server-cookies.
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/
The Current Intended Status of this document is: Standards Track
FYI, I will not shepherd this document,
> On 9 Oct 2020, at 10:38, Andrew McConachie wrote:
> Hi Roy and Joe,
>
> It’s not clear to me whether the document is advising to only use this
> facility when a sub-domain of a public domain name is unavailable, or to
> optionally use this facility based on the user’s preference. What I
On 8 Oct 2020, at 11:54, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations WG of
the IETF.
Title : Top-level Domains for Private Internets
Hi Donald,
> -Original Message-
> From: Donald Eastlake
> Sent: 09 October 2020 00:47
> To: Rob Wilton (rwilton)
> Cc: The IESG ; draft-ietf-dnsop-dns-zone-dig...@ietf.org;
> Tim Wicinski ; ;
> dnsop-cha...@ietf.org
> Subject: Re: [DNSOP] Robert Wilton's No Objection on
Hello Nick,
The closest encloser proof is explained in RFC 7129, Section 5.5.
https://tools.ietf.org/html/rfc7129#section-5.5
Best regards,
Matthijs
On 10/9/20 1:46 AM, Nick Johnson wrote:
> I'm reading RFC 5155, and I'm a bit puzzled by the requirement for
> "closest encloser" proofs to
13 matches
Mail list logo
