Hi Jens,
Thanks for your comment. See below.
On Fri, Nov 8, 2024 at 7:56 AM Jens Finkhäuser wrote:
>
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>
> Hi,
>
> I just joined the list, so apologize if I am repeating a comment that has
> already been made. Something that just jumped out at me i
Hi,
I have posted a revision of the new TKEY draft which includes an
Elliptic Curve DH mode and expect to present on it in Dublin. See
oldish thread with subject "TKEY and MD5".
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle,
ggestions. We’ve implemented all your suggested changes
> in the source document. We’ll wait a few days for any more changes and
> then publish a new revision.
>
> DW
>
>
> > On May 12, 2024, at 1:30 AM, Donald Eastlake wrote:
> >
> > Caution: This email originated
Hi,
I support this draft but have the following comments:
I would assume this has been discussed before but, presumably, the purpose
of this document is to see that the zoneversion option will interoperate
between different implementations. So, why isn't it Standards Track?
NSID should be expand
So Mark,
You were the one who kicked-off my so-far feeble effort to do an
rfc2930bis in the thread starting with the message below...
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On
So, I am the person who added key tags in the initial design of
DNSSEC. The idea was just to, probabilistically, avoid unnecessary
expensive validation attempts. If key tags are causing problems for
some resolvers and validations are not such a problem with modern
hardware, you can always just igno
I've been around in DNS for quite a while.
The way I've always heard "lame delegation" used is in the sense of a
useless parent NS record at a delegation point. Note that "delegation" is
singular. The usual case is that the server name in the NS RR is a
non-existent name or has no address associat
I support publication of this draft.
Since it has no keywords in it, Section 1.1 should be deleted.
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
>
> *From: *DNSOP on behalf of Suza
Hi,
On Fri, Oct 7, 2022 at 2:17 PM Peter Thomassen wrote:
> On 10/7/22 19:46, Roy Arends wrote:
> > Perhaps:
> >
> > What we refer to as "DNSSEC" is the third iteration of the DNSSEC
> specification; [RFC2065] being the first, [RFC2535] being the second.
> Earlier iterations have not been deploye
I support adoption of this draft.
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Tue, Jul 12, 2022 at 9:54 AM Tim Wicinski wrote:
>
> This starts a Call for Adoption for Negative
Hi Andrew,
If you want to claim that because of the recommendations in it, this
document should be standards track instead of BCP, there might be some
merit to such a position, although personally I think it is fine as a BCP
and I don't think the code point allocation has anything to do with this
What you describe is completely improper but I'm not sure it's exactly
accurate. When you said you were "removed" as an author, I assumed that a
new revision of a draft was posted where you were a first page author for
version N but not listed as an author for version N+1. That would also be
improp
On Thu, Mar 3, 2022 at 7:00 PM Joey Deng
wrote:
> Hello,
>
> [RFC 4034 3.1.5. Signature Expiration and Inception
> Fields](https://datatracker.ietf.org/doc/html/rfc4034#section-3.1.5) says:
>
> > The Signature Expiration and Inception field values specify a date and time
> > in the form of a 32
On Mon, Dec 20, 2021 at 10:42 PM Paul Hoffman wrote:
> On Dec 20, 2021, at 6:57 PM, Mark Andrews wrote:
> > Isn’t it about time we updated DH support in DNS to not use MD5? Currently
> > there is
> > no FIPS compatible DH key exchange in DNS. I suspect it would be
> > relatively straight
> >
It would seem that registry references are not always fully updated.
Another example I stumbled over recently is that RFC 3404 obsoletes RFCs
2915 and 2168 but they were both left in as references in the IANA RR
registry entry for NAPTR when RFC 3404 was added as a reference... Last I
heard, IANA w
Hi,
I think this is a good, short draft and I support its publication. The
assignment requirement level it imposes is more appropriate than the
current requirement.
I do have some suggestions which range from minor to trivial:
- Delete "some" from the first line of the Abstract.
- To avoid
On Mon, Jul 26, 2021 at 9:02 PM Jim Reid wrote:
>
> > On 27 Jul 2021, at 01:56, Donald Eastlake wrote:
> >
> > Looks like initial query from IAB to ISO is
> > https://datatracker.ietf.org/liaison/1720/
> >
> > Maybe I'm blind but I don't see a re
All in and out liaisons are, I think, supposed to be posted at
https://datatracker.ietf.org/liaison/posted/
Looks like initial query from IAB to ISO is
https://datatracker.ietf.org/liaison/1720/
Maybe I'm blind but I don't see a response...
Thanks,
Donald
===
Donald
Seems like a good idea to me. I think the WG should adopt it.
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Mon, Jan 27, 2020 at 10:09 AM Hugo Salgado wrote:
>
> Dear DNSOPers, as
Hi,
On Wed, Apr 28, 2021 at 8:24 AM Roy Arends wrote:
> Hi Donald,
>
> On 28 Apr 2021, at 03:34, Donald Eastlake wrote:
>
> I am not comfortable with grabbing all the permanently unassigned 2-letter
> country codes for DNS private use.
>
>
> Note: I was the primary
I am not comfortable with grabbing all the permanently unassigned 2-letter
country codes for DNS private use.
Note: I was the primary author of RFC 2606 and have been involved in this
sort of thing before. See
https://datatracker.ietf.org/doc/draft-eastlake-2606bis/
https://datatracker.ietf.org/d
Hi,
Thanks for the quick response. See below.
On Fri, Apr 23, 2021 at 1:36 PM Wessels, Duane wrote:
>
> > On Apr 22, 2021, at 11:50 AM, Donald Eastlake wrote:
> >
> > Hi,
> >
> > This is a good document and I support publication.
> >
> > However
Hi,
This is a good document and I support publication.
However, I do have some comments. I scanned the Last Call comments by
others, and they mostly seem like improvements, but some of my
comments below may duplicate others for which I apologize in advance.
Section 3, last paragraph: Cut out wi
Hi,
On Thu, Mar 18, 2021 at 10:43 PM Viktor Dukhovni wrote:
> On Mon, Mar 15, 2021 at 05:38:40PM +, Jim Reid wrote:
>
> > ...
> ...
> > This could get nasty with icky CPE
> > firmware: imagine every home router in (say) Comcast’s net doing PMTU
> > to the same root server.
>
> These would gen
On Thu, Dec 17, 2020 at 1:19 PM Rob Wilton (rwilton) wrote:
> Hi Donald,
>
> > -Original Message-
> > From: Donald Eastlake
> > Sent: 17 December 2020 18:00
> > To: Rob Wilton (rwilton)
> > Cc: The IESG ; draft-ietf-dnsop-server-cook...@ietf.org;
&g
Hi,
On Thu, Dec 17, 2020 at 6:50 AM Robert Wilton via Datatracker
wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-dnsop-server-cookies-04: No Objection
>
> ...
>
> --
> COMMENT:
> -
+1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Fri, Oct 9, 2020 at 5:23 AM Rob Wilton (rwilton) wrote:
>
> Hi Donald,
>
> > -Original Message-----
> > From: Donald Eastlake
> > Sent: 09 October 2020 00:47
> > To:
On Thu, Oct 8, 2020 at 7: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:
>
Hi,
Replying on just one point:
On Mon, Sep 21, 2020 at 2:27 PM Michael StJohns wrote:
>
> ...
>
> 2.2.4 - SHA384 has a hash length of 48 bytes. 12 bytes seems to imply
> some sort of left or right truncation. Show stopper! Explain how this
> value was selected and how it interacts with the
==
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Mon, May 11, 2020 at 12:29 AM Donald Eastlake wrote:
>
>> The incremental effort to implement SHA-224 if you are implementing
>> SHA-256 is miniscule
The incremental effort to implement SHA-224 if you are implementing SHA-256
is miniscule. It makes no sense to me for SHA-224 to be NOT RECOMMENDED to
use when SHA-256 is MUST implement and RECOMMENDED to use and you can use
SHA-256 with truncation to 224 or even fewer bits.
Thanks,
Donald
===
Hi Wes,
On Mon, Mar 30, 2020 at 4:35 PM Wes Hardaker wrote:
>
> Donald Eastlake writes:
>
> > My apologies for getting in some minor comments so late. I do not
> > suggest any technical changes. However, at least to my eye, there are
> > some little glitches an
Hi,
My apologies for getting in some minor comments so late. I do not suggest
any technical changes. However, at least to my eye, there are some little
glitches and editorial changes I would suggest.
Among the glitches I see are incorrect internal cross references, old
implementation key word boi
Support as an authors. This draft fixes few little ways the existing
RFC unintentionally missed on interoperability and makes some
simplifying changes.
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
1424 Pro Shop Court, Davenport, FL 33896 USA
d3e
Hi,
Two comments:
1. Maybe I'm confused but it seems to me that the RESPONSE-CODE field of
12 bits plus the INFO-CODE field of 16 bits is 28 bits. So I don't
understand the 2nd paragraph of Section 3.3 that talks about their
concatenation fitting within 24 bits.
2. On the code poin
On Mon, May 13, 2019 at 1:03 AM Joe Abley wrote:
>
> I don't know what experts could be expected to know enough about the entire
> ecosystem to make that call. I also don't know that there's any measurement
> that could be used in all cases to indicate that an RRTYPE is dead. These
> both seem
Wes Hardaker
> > David C Lawrence
> > Filename: draft-ietf-dnsop-extended-error-03.txt
> > Pages : 12
> > Date: 2018-12-20
>
> 4 Donald Eastlake
> .. 4.1 DONE two dimens
I like the Extended Error Code using EDNS idea. This was effectively
what was done with TSIG and TKEY that have an expanded Error field
inside the RR. However:
>> I don't see any reason for the complex two-dimensional table to
new error codes. Given that 16 bits is available for "INFO-CODE"
(whic
Hi,
As the first author of the DNS Cookies RFC, I would be happy to generate a
draft to standardize this to improve inter vendor interoperability for
anycast servers.
Thanks,
Donald
On Thu, Jun 21, 2018 at 03:54 Ondřej Surý wrote:
> > On 21 Jun 2018, at 09:24, Petr Špaček wrote:
> > So let me
See RFC 6604.
Donald
from iPhone
On Wed, Apr 5, 2017 at 09:34 Edward Lewis wrote:
> On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" <
> dnsop-boun...@ietf.org on behalf of m...@isc.org> wrote:
>
> >It seems BIND currently returns NXDOMAIN in this case, and the change in
> >behavior bet
Wouldn't a BULK RR ignorant DNS server just store the BULK RR as opaque data?
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
On Tue, Mar 28, 2017 at 2:31 PM, John Levine wrote:
> At yest
Hi,
I've read this thread up to date. Reading the draft, a few minor things
occurred to me which I think might be small improvements, but I could be
wrong as I'm sure others have studied this more than me. And perhaps some
more warning should be sprinkled into it. But, when I get to the bottom
lin
Hi,
On Thu, Oct 6, 2016 at 3:14 PM, Jim Reid wrote:
> > On 6 Oct 2016, at 18:59, Donald Eastlake wrote:
> > I don't believe there is a registry.
>
> Actually there is. Sort of:
% whois -h whois.iana.org テスト
> % IANA WHOIS server
> % for more information on IA
I don't believe there is a registry. It would seem reasonable to reserve
labels starting with all other [a-z][a-z]-- besides xn-- and establish a
registry. (To avoid people trying to squat on names in advance, the "xn"
was selected by the same sort of publicly verifiable random process as
nomcom vo
It wasn't particularly clear which later message in this thread to respond
to so I'm replying to the first. If anyone is interested, I happen to know
John Postel's opinion on this matter. If you look at early drafts of RFC
2606, such as
https://www.ietf.org/archive/id/draft-ietf-dnsind-test-tlds-06
Adrien,
On Thu, Apr 7, 2016 at 7:13 PM, Adrien de Croy wrote:
> -- Original Message --
> From: "Stephane Bortzmeyer"
> To: "Adrien de Croy"
> Cc: "Philip Homburg" ; "dnsop@ietf.org"
> ; "Ted Lemon"
> Sent: 8/04/2016 3:06:43 a.m.
> Subject: Re: [DNSOP] Alternative Special-Use TLD proble
This version contains changes due to IESG review.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
On Tue, Apr 5, 2016 at 6:49 PM, wrote:
>
> A New Internet-Draft is available from the on-l
Hi Stephen,
On Wed, Jan 20, 2016 at 7:10 AM, Stephen Farrell
wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-dnsop-cookies-09: No Objection
>
> ...
>
> --
> COMMENT:
> -
Hi Alissa,
On Tue, Jan 19, 2016 at 8:59 PM, Mark Andrews wrote:
>
> In message <20160120001031.9209.94235.idtrac...@ietfa.amsl.com>, "Alissa
> Cooper
> " writes:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-dnsop-cookies-09: Yes
>>
>> ...
>>
>> ---
I endorse and support Stuart Cheshire's remarks below.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
On Tue, Dec 29, 2015 at 4:32 PM, Stuart Cheshire wrote:
> Hi Joe, Peter, Alain,
>
> I
This revision resolves SECDIR review comments and one IETF Last Call
comment on the IETF discuss list.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
On Thu, Dec 24, 2015 at 12:29 PM, wro
On Wed, Nov 4, 2015 at 9:37 PM, Joe Abley wrote:
> Hi all,
>
> I couldn't quite interpret the questions and hums in the room; was the
> consensus
>
> (a) this clarification is not needed; the existing spec is clear enough, or
>
> (b) a clarification might be useful, but the proposed clarification
Revised version has been uploaded.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
On Thu, Oct 29, 2015 at 2:17 AM, Tim Wicinski wrote:
>
>
> On 10/28/15 7:03 AM, Donald Eastl
Hi Stephane,
Sorry for slow response, I've been traveling on vacation.
On Sat, Oct 24, 2015 at 3:49 PM, Stephane Bortzmeyer wrote:
> On Mon, Oct 19, 2015 at 05:33:49PM -0400,
> Donald Eastlake wrote
> a message of 59 lines which said:
>
>> This revision incorporated
This revision incorporated editorial improvements and improvements in
explanatory and motivational text based on comments on the WG mailing
list.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.co
Hi Jinmei,
On Fri, Aug 7, 2015 at 2:40 PM, 神明達哉 wrote:
> ...
>
> I've read draft-ietf-dnsop-cookies-05 (a post-WGLC version).
>
> It basically looks good to me to ship: I agree the idea is at least
> worth trying, and I see the document is generally well written.
Thank you.
> I have some commen
Hi,
On Wed, Aug 5, 2015 at 4:58 AM, Ralf Weber wrote:
> ...
>
> But lets focus on the way the server handles cookies. I think I
> discussed that with you or Donald in Prague. There are two ways to
> do this so that each client gets a different cookie, which is what
> the draft suggest:
> - provid
On Tue, Aug 4, 2015 at 4:21 PM, Ted Lemon wrote:
> On Aug 4, 2015, at 3:01 PM, Paul Hoffman wrote:
>> +1 to Donald's response, and -1 to Ted Lemon calling cookies a "kludge".
>
> Sigh. The actual proposal, particularly the key rollover bit, is quite
> elegant, if a bit underspecified, so you’re
On Tue, Aug 4, 2015 at 12:39 PM, Ted Lemon wrote:
> On Aug 4, 2015, at 12:30 PM, Donald Eastlake wrote:
>> I think Mark was pointing out that if you
>> are under attack and want to use weak authentication to help resist
>> that attack, there is no particular reason to p
Hi Ted,
On Tue, Aug 4, 2015 at 11:47 AM, Ted Lemon wrote:
>...
>
> To recap, the reason that I think cookies are more expensive than DNSSEC in
> practice is that for cookies to be deployed in the real world, the DNS
> server implementing them will need to maintain state: the fact that a client
>
Hi Ted,
On Tue, Aug 4, 2015 at 11:50 AM, Ted Lemon wrote:
> On Aug 4, 2015, at 4:20 AM, Mark Andrews wrote:
>> If you are under attack the current method drop or send back TC=1. TC=1
>> means managing many more TCP session on both the server and client side.
>> With cookies it is drop or BADCOO
Hi Ted,
On Mon, Jul 20, 2015 at 8:03 AM, Ted Lemon wrote:
>
> I sent this out on July 20, but unfortunately just to Paul Hoffman. I was
> puzzled as to why it didn’t get any response on the mailing list, but this
> explains it… :}
Your headers still seem a bit messed up as when reply-all in
This revisions incorporates the early allocation of 23 as the BADCOOKIE
RCODE and the changes agreed to on this mailing list.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
On Sat, Aug 1, 20
Hi Hosnieh,
On Mon, Jul 20, 2015 at 10:55 AM, Hosnieh Rafiee wrote:
>> > This is not highlighted in the draft which makes it confusing for the
>> > reader which causes to raise such question regarding NAT.
>>
>> Because it is irrelevent has to how the attacker chooses the address to
>> attack.
>
Hi Ralf,
On Mon, Jul 20, 2015 at 7:19 AM, Ralf Weber wrote:
> Moin!
>
> On 20 Jul 2015, at 4:39, Mark Andrews wrote:
>> No. The server takes the fake_client_cookie + IP client (victim) +
>> server secret + maybe parts of server cookie itself. Computes a
>> server cookie and compares that with wh
Hi,
I think Mark has done a good job in responding, so I don't really have
much to add.
If you can conveniently do configuration at the client and server,
then you can get strong authentication with TSIG. If you can't, the
weak authentication provided by Cookies is about the best you can do.
See
I see two cases:
There are codes from the unified DNS error code space that are not
visible at the top level of a DNS message. For example, the Error
field of TSIG (RFC 2845) or TKEY (RFC 2930). For things like that I
have no problem with Specification Required or Expert Review.
However, for top
Hi,
I'll just reply where Mark did not:
On Sun, Jul 5, 2015 at 7:48 PM, Paul Hoffman wrote:
> Greetings. This is a WG LC review of draft-ietf-dnsop-cookies, which I had
> not looked at carefully in some time. In short: it looks great, the document
> is complete and easy-to-read, and we probabl
Hi Tony,
On Mon, Mar 30, 2015 at 3:55 AM, Tony Finch wrote:
> In the security considerations, it says:
>
>
>1. Work Factor - To make brute force inversion hard, a cryptographic
> hash should be computationally expensive, especially for a general
> purpose processor. But FNV is des
Hi,
I've made some progress on the FNV code. I expect to be able to
advance it, presumably as AD sponsored, before the next IETF.
On DNS Cookies errors, I agree that the utility of the error field, as
far as we can see right now, is quite limited. Still, there can be
error conditions in the Cooki
Hi,
A new version of the DNS Cookies draft has been posted as below.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
-- Forwarded message --
From:
Date: Sat, Oct 11, 2014
Hi,
On Sun, Oct 23, 2011 at 7:49 PM, Mark Andrews wrote:
>
> In message <96472fb7-8425-4928-8f55-2abf2cb59...@conundrum.com>, Matthew
> Pounse
> tt writes:
>>
>> On 2011/10/22, at 15:21, Keith Moore wrote:
>>
>> >
>> > On Oct 22, 2011, at 2:42 PM, Doug Barton wrote:
>> >
>> >> 1. I think we're a
72 matches
Mail list logo
