[DNSOP] Re: [Last-Call] Re: Re: Comments from IETF Last Call about draft-ietf-dnsop-structured-dns-error

On Wed, May 7, 2025 at 7:04 AM Paul Wouters wrote: > > I would really like to hear from the browser vendors on whether they > would support displaying custom error strings in DNS replies to their > endusers, and how they would handle the potential security issues with > this. > More generally, I

[DNSOP] Re: Last Call: (Structured Error Data for Filtered DNS) to Proposed Standard

On Fri, May 2, 2025 at 2:44 PM Mark Nottingham wrote: > Hi EKR, > > > On 3 May 2025, at 3:20 am, Eric Rescorla wrote: > >> If a DNS resolver starts inserting ads / phishing / etc. into responses > using this mechanism, I suspect we'd see a couple of responses: >

[DNSOP] Re: Last Call: (Structured Error Data for Filtered DNS) to Proposed Standard

On Thu, May 1, 2025 at 6:11 PM Mark Nottingham wrote: > Hi Dan, > > > On 2 May 2025, at 4:31 am, Dan Wing wrote: > > > > On Apr 30, 2025, at 01:09, Mark Nottingham wrote: > >> > >> Hi Dan, > >> > >> Can you spell out how this intersects with enshittification? I > understand that there are vari

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

CB draft, other > than that I am concerned about the > illusion of ECH privacy being lost because of a "trusted by the network > via ADD" resolver being used. > > Paul > > On Mon, Oct 7, 2024 at 9:36 PM Eric Rescorla wrote: > >> Paul, >> >> I don

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

y when the client already is using a TRR. -Ekr [0] DNSSEC validation at the recursive might help, but that's not what we're talking about. On Mon, Oct 7, 2024 at 9:16 AM Paul Wouters wrote: > > On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote: > >> >>

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote: > > On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote: > >> This is explicitly prohibited rfc9460 as it would provide linkability. >>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

On Sun, Oct 6, 2024 at 9:09 AM Paul Wouters wrote: > [kind of off-topic here, and also speaking as just an individual] > > On Fri, Oct 4, 2024 at 3:28 PM Erik Nygren wrote: > >> >> On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell >> wrote: >> >>> >>> On 10/4/24 19:30, Paul Wouters wrote: >>> > Wh

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

ve onto these kind of networks and use ECH without > requiring to do further DNS lookups :P > > Maybe just an aggressive prefetch of ECH related records :P > > Which makes me wonder if it makes sense to advise long TTLs on these > records so that they move along on your phone

[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

I don't really think it's helpful to re-litigate the broader topic of the merits of ECH; nothing we say in security considerations will make a material difference there. With that said, I don't love the last sentence as we know users don't really choose their resolvers. How about simply stating th

[DNSOP] Re: AD review draft-ietf-tls-svcb-ech

On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters wrote: > Hi, > > I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well > summarized by the Document > Shepherd: > > Please note that the text in this I-D was initially developed in the DNSOP WG, > went through IETF LC, and IESG rev

[DNSOP] CDS/CDNSKEY Deployment

Hi folks Does anyone have stats on the deployment of CDS and/or CDNSKEY? I see that Chung et al. report very low deployment in 2017, but maybe things have changed? -Ekr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

answers and continuing to listen for the real answer. > > -- > Mark Andrews > > On 9 Oct 2021, at 06:12, Eric Rescorla wrote: > >  > Hi Mark, > > Thanks for your response. > > On Wed, Oct 6, 2021 at 7:41 PM Mark Andrews wrote: > >> You should also note

Re: [DNSOP] Question on interpretation of DO and CD

works around > bad time/trust-anchors in the validating resolver. > Can you elaborate on this a bit? I.e., if I sent DO + CD, then won't I just get an unfiltered view and be able to sort it out locally? What am I missing? -Ekr Mark > > > On 7 Oct 2021, at 10:47, Eric Rescorla

[DNSOP] Question on interpretation of DO and CD

Hi folks, We've been trying to take some measurements of the success of endpoint DNSSEC validation and run into some confusion about the implications of the DO and CD bits. Sorry if these are dumb questions. In the section on stub resolvers RFC 4035 says: A validating security-aware stub reso

Re: [DNSOP] Structured Data for DNS Access Denied Error Page

On Fri, Jul 9, 2021 at 7:43 AM Dan Wing wrote: > We just published Structured Data for DNS Access Denied Error Page which > defines computer-parsable error information for DNS filtering: > >DNS clients using services which perform filtering may wish to >receive more information about such

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Jan 6, 2021 at 2:15 PM Paul Wouters wrote: > On Jan 6, 2021, at 17:01, Eric Rescorla wrote: > > > > > > This is not strictly correct: TLS allows both the client and the server > to advertise their supported signature algorithms, which can be used by the >

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Jan 6, 2021 at 1:30 PM Paul Hoffman wrote: > On Jan 6, 2021, at 1:19 PM, Paul Wouters wrote: > > Remember also that TLS ciphers are negotiated. > > A better analogy might be "although TLS key exchange and encryption > ciphers are negotiated, the signing algorithm on the server's certific

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Mon, Jan 4, 2021 at 3:31 AM Vittorio Bertola wrote: > > > > Il 01/01/2021 19:42 Stephen Farrell ha > scritto: > > > > > > Hiya, > > > > On 01/01/2021 17:58, Paul Hoffman wrote: > > > The WG has already adopted the revised GOST document as a WG item; > > > what you are proposing (if the curren

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

On Wed, Dec 30, 2020 at 7:23 PM Paul Wouters wrote: > On Dec 30, 2020, at 22:11, Daniel Migault wrote: > > > >  > > > > If I understand clearly the comment, it seems to say that TLS ( for > example ) is using RFC Required and that DNSSEC should do the same. Quickly > going through RFC 8447, I

Re: [DNSOP] [Last-Call] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

On Sat, Dec 5, 2020 at 6:58 AM Salz, Rich wrote: > There is a fair amount of academic study around SipHash, and while > everyone can make mistakes, its creators have a pretty good reputation. I > don't think we can say SipHash is unknown in the industry. > > The TLSWG made it a practice to ask CF

Re: [DNSOP] [Last-Call] Secdir last call review of draft-ietf-dnsop-server-cookies-04

On Thu, Dec 3, 2020 at 9:52 AM Salz, Rich wrote: > > https://www.aumasson.jp/siphash/ > > > > >- It seems like kind of a problem to have a normative algorit

Re: [DNSOP] [Last-Call] Secdir last call review of draft-ietf-dnsop-server-cookies-04

On Thu, Dec 3, 2020 at 6:29 AM Willem Toorop wrote: > Op 02-12-2020 om 23:31 schreef Stephen Farrell: > > > > > FWIW, I'd say it's worth a few more words to try reduce > > the probability of such failures happening, e.g. maybe > > just highlighting the "unsigned/2106" point you made > > above wo

Re: [DNSOP] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

On Wed, Dec 2, 2020 at 10:32 AM Ondřej Surý wrote: > Stephen, > > ad 1) the performance is crucial for DNS over UDP and PRF such as SipHash > is more efficient than HMACs. No, it wasn’t consulted with CFRG, and I > can’t speak for Willem, but I am confident enough to make the decision. > SipHash

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020 at 11:39 AM John Levine wrote: > In article 01gd...@mail.gmail.com> you write: > >> Yes. Leveraging the fact that the IETF community is in fact a community > >> seems worth the effort to have the references in registries be useful > to a > >> new developer a decade in the fu

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman wrote: > On Jun 19, 2020, at 9:26 AM, Eric Rescorla wrote: > > What's your reasoning for why there needs to be community review before > there is a code point assigned? > > Historically, the quality of algorithm descripti

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Fri, Jun 19, 2020 at 8:38 AM Paul Hoffman wrote: > On Jun 18, 2020, at 9:20 PM, Martin Thomson wrote: > > > > On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote: > >> It might be better, and faster, for this WG to adopt a one-paragraph > >> draft that makes the DS registry "RFC required", lik

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters wrote: > On Thu, 18 Jun 2020, Eric Rescorla wrote: > > > The way that TLS has handled this is to have the registries have a > column called Recommended and we just mark things Y or N. This is slightly > > different from RFC 2119 l

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Thu, Jun 18, 2020 at 9:13 AM Paul Wouters wrote: > On Thu, 18 Jun 2020, Eric Rescorla wrote: > > > On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski wrote: > > Eric > > > > One of the reasons we've published 8624 was to offer usage > recommen

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski wrote: > Eric > > One of the reasons we've published 8624 was to offer usage recommendations, > and especially this table: > > https://tools.ietf.org/html/rfc8624#page-5 > > I believe I saw that one of the authors mentioned earlier they are looking > t

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

On Wed, Jun 17, 2020 at 8:51 PM Martin Thomson wrote: > I agree with Olafur on this. The reason we standardize is so that we can > have a single - ideally very small - set of algorithms that are widely > implemented. Because you want every one of those algorithms in every > implementation. > >

Re: [DNSOP] port number in HTTPSSVC

I agree. I do not think we should make this change. -Ekr On Fri, Jan 3, 2020 at 12:02 PM Erik Kline wrote: > I think removing port number flexibility might unduly constrain some data > center use cases where service reachability might not have the more common > 443-only limitations. > > On Fri

Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

On Tue, Jul 16, 2019 at 4:04 PM Alejandro Acosta < alejandroacostaal...@gmail.com> wrote: > > > > On 7/8/19 2:36 PM, Andy Grover wrote: > > Hi all, > > > > FYI from the ADD list, please post there or to the authors with feedback. > > > > > > Forwarded Message > > Subject: [Add]

Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

On Mon, Jul 15, 2019 at 8:53 PM Rob Sayre wrote: > > > On Mon, Jul 15, 2019 at 8:14 AM Paul Vixie wrote: > >> On Monday, 15 July 2019 02:17:04 UTC Rob Sayre wrote: >> > On Sun, Jul 14, 2019 at 6:59 PM Paul Vixie wrote: >> > > ... >> > >> > I'm surprised that you seem to view DoH as a problem. I

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

On Fri, Mar 22, 2019 at 12:53 AM Vittorio Bertola wrote: > > > > Il 22 marzo 2019 alle 4.40 Christian Huitema ha > scritto: > > > > Much of the debate is on the second point. One position is that users > should be forced to trust the DNS resolver provided by the local > infrastructure. Another p

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

on is that enterprises which want to do conditional inspection will disable ESNI on the client. This should not be problematic as they already need access to the client to install their own trust anchor. -Ekr > > -Tiru > > > > *From:* Eric Rescorla > *Sent:* Tuesday, March 12, 20

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie wrote: > > > nalini elkins wrote on 2019-03-11 10:26: > > Tiru, > > > > Thanks for your comments. > > > > > Enterprise networks are already able to block DoH services, > i wonder if everyone here knows that TLS 1.3 and encrypted headers is > going to p

Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

On Tue, Nov 27, 2018 at 7:00 AM Paul Hoffman wrote: > On Nov 27, 2018, at 3:05 AM, Alexey Melnikov > wrote: > > > > On Tue, Nov 27, 2018, at 2:10 AM, Paul Hoffman wrote: > >> | filter | O | T | "tcpdump" [pcap] style filter for | > >> | | | | input.

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

On Wed, Nov 21, 2018 at 9:25 AM Sara Dickinson wrote: > > > Begin forwarded message: > > *From: *Eric Rescorla > *Subject: **Eric Rescorla's No Objection on > draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)* > *Date: *21 November 2018 at 02:07:20 GMT &g

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-dnsop-dns-capture-format-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

On Wed, Oct 10, 2018 at 1:18 PM Dave Crocker wrote: > Eric, > > On 10/9/2018 7:23 PM, Eric Rescorla wrote: > >> However some services have defined an operational convention, > which > >> applies to DNS leaf nodes that are under a DNS branch having one

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-dnsop-attrleaf-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-dnsop-refuse-any-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [DNSOP] [Ext] Eric Rescorla's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

That's understandable. I think it would be most helpful to somehow tag those cases so that the reader can see that they are ambiguous rather than just rereading and being confused. -Ekr On Fri, Aug 31, 2018 at 9:22 AM, Paul Hoffman wrote: > Ekr pinged me in Jabber after I sent this, and I want

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-dnsop-terminology-bis-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

On Tue, Jul 31, 2018 at 8:21 PM, Ted Lemon wrote: > > Sorry, has this been changed in a new version? >> > > The text you commented on is the new version, with some additional text to > address a point raised in the gen-art review. We gamed this out pretty > thoroughly—I don't think there's an a

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

On Tue, Jul 31, 2018 at 7:28 PM, Ted Lemon wrote: > On Tue, Jul 31, 2018 at 6:28 PM, Eric Rescorla wrote: > >> IMPORTANT >> S 5.3. >> > field set to zero, and MUST NOT elicit a response. >> > >> > Every DSO request message (QR=0) wi

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

Eric Rescorla has entered the following ballot position for draft-ietf-dnsop-session-signal-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley wrote: > Hi, > > On 2010-10-04, at 10:31, Eric Rescorla wrote: > > > On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote: > > > >> On 2010-10-03, at 13:31, Eric Rescorla wrote: > >> > >> > I'm aski

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley wrote: > Hi, > > On 2010-10-04, at 10:31, Eric Rescorla wrote: > > > On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote: > > > >> On 2010-10-03, at 13:31, Eric Rescorla wrote: > >> > >> > I'm aski

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

I think it would depend on the HSMs. In at least some of them, it's the card keys that are important and you could have a disjoint set of card keys for K_{n+1} -Ekr On Mon, Oct 4, 2010 at 7:52 AM, Paul Hoffman wrote: > At 7:31 AM -0700 10/4/10, Eric Rescorla wrote: > >On Sun,

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote: > > On 2010-10-03, at 13:31, Eric Rescorla wrote: > > > I'm asking because I'm pretty familiar with cryptography and I know that > keys don't suddenly become > > worthless just because they get past their in

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

On Sun, Oct 3, 2010 at 10:18 AM, Joe Abley wrote: > > On 2010-10-03, at 12:32, Eric Rescorla wrote: > > > Why? > > Are you asking because you've reviewed those discussions and have issues > with them, or because you didn't review those discussions? > I'

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

Why? Ekr On Oct 3, 2010, at 8:54, Joe Abley wrote: > > On 2010-10-03, at 07:59, Tony Finch wrote: > >> On 3 Oct 2010, at 08:27, Jakob Schlyter wrote: >>> On 1 okt 2010, at 20.59, Tony Finch wrote: Right, so it's aimed at human consumption rather than automatic tools? >>> >>> Give

Re: [DNSOP] RFC4641-bis: The case for single active key

On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson wrote: > Background #3: Key strengths and life time > RSA and DSA algorithms have the interesting property that the number of bits > in the key can be selected, by adding bits to the key the key gets stronger. > Stronger keys can be used longer.

Re: [DNSOP] RFC4641bis version 02.

On Mon, Mar 1, 2010 at 8:45 AM, Chris Thompson wrote: > On Mar 1 2010, Eric Rescorla wrote: > >> [...] If a key is breakable at cost C in M months, then it's breakable >> at cost Cx in M/x months. > > This isn't true in general (although it may be sufficiently

Re: [DNSOP] RFC4641bis version 02.

On Mon, Mar 1, 2010 at 5:26 AM, Rose, Scott W. wrote: > The 1024 bit key guideline is for response sizes (biggest stumbling block > we've encountered so far in .gov deployment). > > The rollover frequency is largely based on an extended time frame.  The > extended roadmap is to try and migrate to

Re: [DNSOP] RFC4641bis version 02.

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: > >> >>> Basically, you adhere to (B) and suggest 1024-bits/1-month-cryptoperiod, >>> hence you inflate the requirements over NIST's. >> >> I am not in

Re: [DNSOP] RFC4641bis version 02.

On Fri, Feb 26, 2010 at 11:41 AM, Paul Wouters wrote: > On Fri, 26 Feb 2010, Eric Rescorla wrote: > >>  For >>  reasons of signing speed and DNS packet length one may want to keep >>  keylenght at a minimal responsible length and change the key >>  relatively frequen

Re: [DNSOP] RFC4641bis version 02.

S 3.1.1: Finally there is a risk of cryptanalysis of the key material. The cost of such analysis are correlated to the length of the key and the amount of signed material that is available to the analyst. This statement is false for RSA and as far as a I know, for any major signature al

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

On Mon, Feb 22, 2010 at 4:24 PM, Mark Andrews wrote: > > In message , Eric > R > escorla writes: >> Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls >> into the category of "basic assumptions" > > Basic assumptions should be noted. Should we also note the Heisenberg uncert

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

On Mon, Feb 22, 2010 at 11:59 AM, Evan Hunt wrote: >> I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC". >> >> I've seen the opposite by Mark Andrews: >> >>   "Actually NSEC is technically better at proving non-existance." > > Mark was responding to an assertion to the con

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

On Mon, Feb 22, 2010 at 9:23 AM, Evan Hunt wrote: >> This is absurd. If we're going to do this, I'd like the security >> considerations to reflect all of the non-zero probabilities of errors >> occuring (those that have a higher probability). > > I just answered this point in private mail to someo

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends wrote: > On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote: > >>> Using NSEC instead of NSEC3 because you fear SHA1 collisions does not >>> seem sensible, as if you fear SHA1 collisions, you have other more >>> significant problems with DNSSEC to worry about

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews wrote: > > In message <315ad36e-879a-4512-a6a8-b64372e3d...@sinodun.com>, John Dickinson > w > rites: >> Hi, >> >> It might also be worth adding a line at the start reminding of the need for N >> SEC and NSEC3 - namely that the signing and serving of

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

On Fri, Jan 22, 2010 at 12:35 PM, Paul Hoffman wrote: > At 8:18 PM + 1/22/10, bmann...@vacation.karoshi.com wrote: >>On Fri, Jan 22, 2010 at 09:13:22AM -0800, Paul Hoffman wrote: >>> At 4:56 PM + 1/22/10, Tony Finch wrote: >>> >On Thu, 21 Jan 2010, Paul Hoffman wrote: >>> >> >>> >> - Regul

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Eric Rescorla wrote: > >>>> The point is that the numbers depend on your model of the attacker >>>> more than on the cryptography. > >> Yes, but my point is that the safety period d

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

On Thu, Jan 21, 2010 at 3:08 PM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Eric Rescorla wrote: > >>> Also, consider this paper from July 2009: >>> >>> https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf >>> >>>    Next consid

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

On Thu, Jan 21, 2010 at 2:24 PM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Edward Lewis wrote: > >> What I'd like to hear is: >> >> "Crypto-expert __ says an RSA-SHA256 key of 1024 bits is good for >> ___ signatures/days." > > I did ask my local Waterloo based cryptographer (Ian Goldb

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

Again, I don't feel strongly about this, but I don't really find this very convincing. Presumably there are all sorts of other credentials that control access to the ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also propose to roll all of these every month? If not, why n

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman wrote: > At 2:17 PM -0500 1/21/10, Edward Lewis wrote: >>At 11:05 -0800 1/21/10, Eric Rescorla wrote: >>>I still don't understand why this implies the need for regular changes >>>as opposed to changes triggered by p

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

I still don't understand why this implies the need for regular changes as opposed to changes triggered by personnel changes. -Ekr On Thu, Jan 21, 2010 at 10:03 AM, Paul Wouters wrote: > On Thu, 21 Jan 2010, Edward Lewis wrote: > >> If I were to fit this into the text below... >> >> # >> #      

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

I'm not really an active member of the WG, so I certainly wouldn't say that my position has much of an affect on consensus, but I'm unconvinced by the argument offered below. Sure, the ZSK is at greater risk because operators have access to it, but so what? If an operator actually steals the key (

Re: [DNSOP] [dnsext] Why ZSK rollover is a Bad Idea (tm)

On Wed, Oct 7, 2009 at 6:22 AM, Joe Abley wrote: > [from a namedroppers thread, re-pointed as per Olaf's suggestion below] > > On 2009-10-07, at 09:23, Olaf Kolkman wrote: > >> On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote: >> >>> I don't have a ge