Hi,
(800-81 author here)
That needs to be updated as it was from the earlier revision of 800-81.
It really should stress the use of RFC 5011 automated trust anchor
update process. The first version of the doc assumed RFC 5011 was not
available in the majority of implementations, which is no
Is this draft still alive? It’s active, but don’t see much
discussion, so I’d thought I would present some comments. Some may be
my misunderstanding of the intent, in which case I would argue the text
isn’t clear enough for dummies like me :)
Section 5, last sentence
"...the mechanisms may h
On 6 Jul 2018, at 20:26, Tim Wicinski wrote:
We've had some interest in moving this document forward, and the
chairs
wanted to kick off this Call for Adoption before Montreal so if there
are concerns there will be some meeting time to address.
This document is label as: Informational. The doc
I have read the draft and support it advancing. It is a good
replacement for RFC 6944.
Scott
On 2 Oct 2018, at 8:51, Tim Wicinski wrote:
The chairs and the authors of this document feel that the
document is in solid shape to proceed to WGLC.
This starts a Working Group Last Call for
draft
There is a current document that would need to be updated: RFC 6944:
http://tools.ietf.org/html/rfc6944
The RFC needs to be updated to include the new elliptic curve
algorithms. It would also be a good place to move other algorithms to
other categories.
Scott
On 10 Sep 2015, at 10:02, Ondře
I have also read the draft and support it.
Scott
On 31 Oct 2015, at 18:18, Suzanne Woolf wrote:
Joe,
Thanks for the update.
Those of you who supported publication— I assume Joe will be
reminding you to review :-)
best,
Suzanne
On Oct 31, 2015, at 4:50 PM, Joe Abley wrote:
Hi,
Just a
This draft should also serve to obsolete RFC 6944.
Scott
On 19 Mar 2016, at 15:43, Paul Wouters wrote:
> Hi,
>
> there was an interest in deprecating some DNSSEC related algorithms.
> Ondrey and I wrote a draft that tries to introduce and depricate
> DNSSEC algorithms similar to how it has been
I have read the draft and support it being made into a WG document.
I do have some minor comments - none that change the tone of the
document:
1. Introduction 5th paragraph
“DNSSEC algorithms are used…” Probably should be “DNSSEC
registered algorithms…” There are no crypto algorithms that ar
I have read the previous version, and support this draft becoming a WG
document.
I will read and review the doc.
Scott
On 5 Jan 2017, at 16:28, Tim Wicinski wrote:
All
Since we're having so much fun on adopting work, let's have another
one. We discussed this work in Seoul, and there was a
I think the document should also include the risk of cache inspection. An
eavesdropper with access to the same recursive cache as the victim can examine
the cache to get a picture of the DNS queries the victim(s) performed and when
based on the TTL of cached RRsets. While the attacker can't say
On Mar 27, 2014, at 10:22 AM, Joe Abley wrote:
>
> On 27 Mar 2014, at 22:56, Nicholas Weaver wrote:
>
>> Bits are not precious: Until a DNS reply hits the fragmentation limit of
>> ~1500B, size-matters-not (tm, Yoda Inc).
>>
>> So why are both root and com and org and, well, just about ev
On Apr 2, 2014, at 12:06 PM, S Moonesamy wrote:
>
>> What does it matter from a security perspective? DNS messages are short
>> lived. It's not like we are encrypting a novel to be kept secret for 100
>> years. With zone signing keys lasting a month, 6 months, or so, and the
>> ability to
I can't speak for all of .gov, but I think the draft is ready for publication.
Once it has an RFC number it will get worked into products and ops manuals.
Since a lot of .gov agencies outsource, or use appliances, I wouldn't expect
much feedback. :)
Scott
_
Read over the new DNSOP-titled version and have a couple of minor comments.
Section 3 - 1st paragraph:
I am not a lawyer, but have had to deal with them on occasion. qname
minimization may or may not reduce legal responsibilities. Just because you
can't do something doesn't always absolve yo
On the subject of NTA's that should be there -
Should there be text describing auto-adding of NTA's based on important domains
(for the ISP/resolver's definition of important)? So that domains that are
used by low level services don't fail that also aren't normally visible to end
users? One
I support the adoption and will review/post comments. I think this draft will
be a necessity as DNSSEC validation gets wider deployment.
Scott
On Nov 26, 2014, at 10:58 AM, Tim Wicinski wrote:
>
> This starts a Call for Adoption for
> draft-livingood-dnsop-negative-trust-anchors. There was
On 22 Oct 2021, at 12:13, Wes Hardaker wrote:
Peter van Dijk writes:
It remains to be debated whether these ideas that you shouldn't use
unless you have to should eventually be published as an RFC.
I'm torn on this one. Sometimes going insecure is what has to happen,
and for those cases, op
I read the draft and support it. Suggest one wording change though: In the
draft the term "trust anchor" is used when is should really be "secure entry
point". At least to keep it in line with the dns-terminology draft and the
fact that the KSK for the zone may not be a trust anchor.
Scott
I think this draft is a good idea and should be adopted, but needs some
improvements first.
1. In Section 4: "unsecure" should be "insecure".
2. REQ2: What should happen when there are multiple trust anchors, but only one
failed to validate? E.g. a validator has both the root and .exampleTLD
On 7/13/09 10:08 AM, "Tony Finch" wrote:
> On Mon, 13 Jul 2009, Livingood, Jason wrote:
>
>> I think we probably also need to address the fact that mail servers
>> should not use resolvers that perform DNS redirect (this was assumed but
>> should be explicit).
>
> I think you need to widen that
Perhaps the wording is a bit incorrect in that it an insider attack (the
admin accessing the key) is not the biggest threat. The ZSK is accessed
more often and if it isn't on an HSM (or similar), there could be a risk
that it could be exposed by someone other than the responsible DNS admin. Of
cou
On 1/21/10 10:48 AM, "Edward Lewis" wrote:
> At 10:39 -0500 1/21/10, Andrew Sullivan wrote:
>> On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote:
>>> So many assumptions have changed...but the idea of KSK/ZSK hasn't.
>>
>> Maybe this is the problem?
>
> Problem?
>
> Not everyone ha
On 1/25/10 12:56 PM, "Edward Lewis" wrote:
> At 21:14 -0800 1/22/10, Eric Rescorla wrote:
>
>> I haven't formed a useful opinion one way or the other about the operational
>> value of frequent key rollovers. However, it seems to me that the value
>> of those practices is more or less independent
On 2/26/10 4:51 PM, "Paul Wouters" wrote:
> On Fri, 26 Feb 2010, Thierry Moreau wrote:
>
>> Basically, you adhere to (B) and suggest 1024-bits/1-month-cryptoperiod,
>> hence you inflate the requirements over NIST's.
>
> I am not inflating NIST's requirements. I believe 1024 bit RSA with monthl
tt
On 3/1/10 8:07 AM, "Eric Rescorla" wrote:
> On Mon, Mar 1, 2010 at 4:57 AM, Rose, Scott W. wrote:
>> On 2/26/10 4:51 PM, "Paul Wouters" wrote:
>>
>>> On Fri, 26 Feb 2010, Thierry Moreau wrote:
>>
>>>
>>>> Basicall
I have read the most recent version and sent some editorial comments
directly to the authors.
I have finally got around looking at the open-issues tracker and saw the
"Review-NIST" ticket. In short, I believe that it can be closed out. The
recommendations in NIST SP 800-81r1 are really an attemp
On Jun 17, 2010, at 5:15 PM, Olafur Gudmundsson wrote:
>
> Proposal #1:
> The document should describe both single key and split key operations
> and provide real guidance as to when each model is appropriate.
>
> Here is a draft of parameters that should be used to guide
> selection of single
Yes, in my opinion it is a good idea to have a plan to migrate to a new
algorithm and RSA/SHA-256 is probably the candidate as ECDSA is not widely
implemented as far as we can tell (but not sure). NIST is advocating migration
(or initial deployment) of RSA/SHA-256 within the .gov TLD. The .gov
I think the draft is good enough to be advanced. Since it is on the
Experimental track, there isn't too much risk. It only affects the resolver
that chooses to do it, not any other entity and doesn't change the DNS protocol.
Basic copy-edit comments:
1. Section 1. Introduction and background
According to my dictionary (as in, at least US english).
The usual phrasing in the sentence would be "less than" or "fewer than".
Scott
On Mar 9, 2015, at 10:21 AM, Bob Harold wrote:
>
> On Mon, Mar 9, 2015 at 10:12 AM, Stephane Bortzmeyer
> wrote:
> On Wed, Mar 04, 2015 at 08:10:11AM -05
On Apr 2, 2015, at 2:50 PM, Dave Lawrence wrote:
> Paul Hoffman:
>> I added the synonym for slave. How do people feel about "primary"
>> and "master"?
>
> Personally I'm not fond of the master/slave language and avoid the
> terms. I recognize their historic computer use and don't feel the
> nee
I think the draft is just about ready for publication as well.
On May 5, 2015, at 5:53 PM, Paul Hoffman wrote:
> This document has progressed very well and is nearly ready for publication.
>
> Related to an earlier thread about intended status: "Informational" is most
> appropriate here becaus
In general I support this document, with some minor comments below:
Abstract:
s/approache/approach
Section 1.1
2nd paragraph:
s/recomendations/recommendations
"it" is repeated twice in the sentence starting: "While these recomendations
are mainly aimed at Host Validators it it..."
s/Valida
On 4 Jul 2023, at 10:03, Peter Thomassen wrote:
> Hi Scott,
>
> Thank you very much for your feedback -- responses inline.
> o "inline" the actual definition, but that was just a feeling.)
>
>> Also, “Signaling Name” sounds
>> confusing compared to the Signaling Domain. Would it be easier to write
On 20 Apr 2024, at 19:38, Paul Wouters wrote:
> On Sat, 20 Apr 2024, Peter Thomassen wrote:
>
>> The authors certainly don't insist, but we'd need to pick a suitable
>> replacement for the "_signal" label.
>>
>> John proposed "_dnssec-signal" elsewhere in this thread.
>>
>> The authors would like
35 matches
Mail list logo
