> On 25 Mar 2022, at 03:50, Ulrich Wisser wrote:
>
> Hi Mark,
>
> Sorry for the late answer, IETF and some other stuff keeps me busy.
>
>
> Let’s start with this
>
> We did not and do not propose to remove anything from RFC 4035. Currently we
> are asking for RFC 6840 to be amended
>
> R
On Thu, Mar 24, 2022 at 4:08 PM Tim Wicinski wrote:
>
> All
>
> If you attended the most recent DNSOP session, you've heard Warren speak
> about creating a BCP for DNSSEC, including all of the DNSSEC related RFCs,
> in order to make life easier for implementers and DNS operators.
>
> We want to
The DNSOP WG has placed draft-hoffman-dnssec in state
Call For Adoption By WG Issued (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-hoffman-dnssec/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.
All
If you attended the most recent DNSOP session, you've heard Warren speak
about creating a BCP for DNSSEC, including all of the DNSSEC related RFCs,
in order to make life easier for implementers and DNS operators.
We want to ask the working group if this is something DNSOP wants to work
on. I
Tim Wicinski writes:
> With the authors feeling there are no outstanding changes and most people are
> happy with the current
> version. So this means it's time:
Note that two small changes have been introduced since -06 were
published, which were just wording related changes. Here are the di
On Thu, Mar 24, 2022 at 9:53 AM Ulrich Wisser wrote:
> Hi Mark,
>
> Sorry for the late answer, IETF and some other stuff keeps me busy.
>
>
> Let’s start with this
>
> *We did not and do not propose to remove anything from RFC 4035. Currently
> we are asking for RFC 6840 to be amended *
>
> *RFC
Hi Mark,
Sorry for the late answer, IETF and some other stuff keeps me busy.
Let’s start with this
We did not and do not propose to remove anything from RFC 4035. Currently we
are asking for RFC 6840 to be amended
RFC 6840 Section 5.11
This requirement applies to servers, not validators.
On 22/03/2022 09.56, Nils Wisiol wrote:
There was some internal discussion about using 17 vs 253, with the main
argument for 253 being that this is the intended use case for 253 and
the main argument for 17 being that worry that some resolver
implementations could have special treatment for priva
On Thu, 2022-03-24 at 11:27 +0100, Petr Špaček wrote:
> On 23. 03. 22 10:45, Peter van Dijk wrote:
> > So, Paul, I support the idea behind your draft, but not the current
> > wording. While more 253-like points might be somewhat useful, what
> > we
> > really need are experimental code points with
Petr Menšík wrote:
>
> I thought it is not a problem, because it contains multiple iterations.
> Yet popular TLD has iterations==0. This is about how hash of name is
> created from original Next Hashed Owner Name. No other algorithm for
> this is defined.
>
> My conclusion is owner name hash is no
Paul Wouters wrote:
If a parent zone administrator or some employee of it is
compromised and forged zone delegation (with an IP address of a
forged nameserver using forged public/secret keys) is signed by a
valid key, it will not be noticed easily.
Such an individual would have to get acce
Matthew Pounsett wrote:
> On Wed, Mar 23, 2022 at 3:20 PM Petr Menšík wrote:
> >
> > Yes, it says so. It also says SHA-1 is not recommended for new
> > signatures and ietf.org signature was made at 20220318000627.
>
> It's more accurate to say that it's not recommended for new
> deployments. Ope
On 23. 03. 22 10:45, Peter van Dijk wrote:
So, Paul, I support the idea behind your draft, but not the current
wording. While more 253-like points might be somewhat useful, what we
really need are experimental code points with non-253 semantics.
I agree. IMHO experiment codepoint which does not g
13 matches
Mail list logo
