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
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 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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
17 matches
Mail list logo
