[dns-privacy] OARC 42 Call for Presentations
OARC 42 will be a two-day hybrid meeting and the dates are *8th and 9th February 2024,* to be co-located with NANOG 90 in *Charlotte, North Carolina, USA.* The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: *Operations*: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). *Deployment*: DNS config management and release process. *Monitoring*: Log ingestion pipeline, analytics infrastructure, anomaly detection. *Scaling*: DNS performance management and metrics. Increasing DNS Server Efficiency *Security/Privacy*: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either 10 or 20 minutes in length (plus 5 minutes for Q). Proposals for in-person lightning presentations will be opened closer to the Workshop dates. Workshop Milestones: 2023-09-07 Submissions open via Indico *2023-11-22 Deadline for submission (23:59 UTC)* 2023-11-29 Preliminary list of contributions published 2023-12-13 Full agenda published 2024-01-10 Deadline for slideset submission and Rehearsal 2024-02-08 OARC 42 Workshop - Day1 2024-02-09 OARC 42 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc42> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Example guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 42 your talk will be broadcast live and recorded for future reference your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting Remote speakers have mandatory rehearsal (Date and Time TBD). It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net *Manu Bretelle, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 41 - Call for Contribution -- deadline extension
Deadline for OARC 41 abstract submission is extended to June 20th, 23:59 UTC. Please note that, we are looking for contributions and remote participation is actively supported * OARC 41 will be a two-day hybrid meeting and the dates are 6th and 7th September to be co-located with ICANN DNS Symposium in Da Nang, Vietnam. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either 10 or 20 minutes in length (plus 5 minutes for Q). Proposals for in-person lightning presentations will be opened at the Workshop. Workshop Milestones: 2023-04-16 Submissions open via Indico 2023-06-20 Deadline for submission (23:59 UTC) 2023-06-27 Preliminary list of contributions published 2023-07-11 Full agenda published 2023-08-08 Deadline for slideset submission and Rehearsal 2023-09-06 OARC 41 Workshop - Day1 2023-09-07 OARC 41 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc41> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Example guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 41 - your talk will be broadcast live and recorded for future reference - your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net Manu Bretelle, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 41 - Call for Contribution
OARC 41 will be a two-day hybrid meeting and the tentative dates are between 4-8th September to be co-located with ICANN DNS Symposium.in Asia. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) *Workshop Milestones:* 2023-04-16 Submissions open via Indico 2023-06-10 Deadline for submission (23:59 UTC) 2023-06-27 Preliminary list of contributions published 2023-07-11 Full agenda published 2023-08-08 Deadline for slideset submission and Rehearsal 2023-09-<> OARC 41 Workshop - Day1 2023-09-<> OARC 41 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc41> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Example guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 41 - your talk will be broadcast live and recorded for future reference - your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - *Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC.* It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net Manu Bretelle, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 40 - Call for Contribution - deadline extension
*Deadline for OARC 40 abstract submission is extended to January 5, 23:59 UTC * Please note that, we are looking for contributions and remote participation is actively supported OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in Atlanta (GA), USA at 10:00 AM (Local time - EST (UTC-05:00)). The onsite part of the meeting will be colocated with NANOG 87. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) *Workshop Milestones:* 2022-10-22 Submissions open via Indico 2022-01-05 Deadline for submission (23:59 UTC) 2023-01-10 Preliminary list of contributions published 2023-01-17 Full agenda published 2023-01-30 Deadline for slideset submission and Rehearsal 2023-02-16 OARC 40 Workshop - Day1 2023-02-17 OARC 40 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc40> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 40 - your talk will be broadcast live and recorded for future reference - your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - *Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC.* It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net Manu Bretelle, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Reminder OARC 40 - Call for Contribution
*Reminder: Deadline for OARC 40 abstract submission - December 20, 23:59 UTC * Please note that, we are looking for contributions and remote participation is actively supported OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in Atlanta (GA), USA at 10:00 AM (Local time - EST (UTC-05:00)). The onsite part of the meeting will be colocated with NANOG 87. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) *Workshop Milestones:* 2022-10-22 Submissions open via Indico 2022-12-20 Deadline for submission (23:59 UTC) 2023-01-10 Preliminary list of contributions published 2023-01-17 Full agenda published 2023-01-30 Deadline for slideset submission and Rehearsal 2023-02-16 OARC 40 Workshop - Day1 2023-02-17 OARC 40 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc40> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 40 - your talk will be broadcast live and recorded for future reference - your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - *Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC.* It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net Manu Bretelle, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 40 - Call for Contribution
OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in Atlanta (GA), USA at 10:00 AM (Local time - EST (UTC-05:00)). The onsite part of the meeting will be colocated with NANOG 87. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT The presentations can be either a full-length presentation - 20 mins (+5 mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) *Workshop Milestones:* 2022-10-22 Submissions open via Indico 2022-12-20 Deadline for submission (23:59 UTC) 2023-01-10 Preliminary list of contributions published 2023-01-17 Full agenda published 2023-01-30 Deadline for slideset submission and Rehearsal 2023-02-16 OARC 40 Workshop - Day1 2023-02-17 OARC 40 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc40> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Guidelines for presentation slides: https://www.grammarly.com/blog/presentation-tips/ Additional information for speakers of OARC 40 - your talk will be broadcast live and recorded for future reference - your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - *Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC.* It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net Manu Bretelle, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 39 - Call for Contribution - deadline extension
*Extension: Deadline for OARC 39 abstract submission is extended to September 13, 23:59 UTC * Please note: 1) We are looking for contributions and remote participation is actively supported. 2) OARC 39 will be a joint conference with CENTR and abstract submissions from CENTR members are welcome. The abstracts can be submitted using this link: https://indico.dns-oarc.net/event/44/abstracts/ Thank you, Manu Bretelle, for the DNS-OARC Programme Committee ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Reminder OARC 39 - Call for Contribution
*Reminder: Deadline for OARC 39 abstract submission - September 06, 23:59 UTC * Please note that, we are looking for contributions and remote participation is actively supported --- OARC 39 will be a two-day hybrid meeting held on* 22 & 23 October in Belgrade, Serbia *at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be *co-located with RIPE** 85.* The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT *Note: OARC 39 will be a joint conference with CENTR and abstract submissions from CENTR members are welcome.* As it is a *hybrid *workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** *2022-09-06Deadline for submission (23:59 UTC)* 2022-09-08Preliminary list of contributions published 2022-09-20Full agenda published 2022-10-03Deadline for slideset submission and Rehearsal 2022-10-22OARC 39 Workshop - Day1 2022-10-23OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc39> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers at OARC 39: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * *Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. *It would be very useful to have your slides (even if draft) ready for this. *Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens.* If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via *Manu Bretelle, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 39 Call for Contributions
OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be colocated with RIPE 85. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is a hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** 2022-07-30 Submissions open via Indico 2022-09-06 Deadline for submission (23:59 UTC) 2022-09-08 Preliminary list of contributions published 2022-09-13 Final Contribution list published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc39> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers at OARC 39: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Manu Bretelle, for the DNS-OARC Programme Committee ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Reminder OARC 38 - Call for Contribution
*Reminder: Deadline for abstract submission - June 20, 23:59 UTC * *Please note that we are looking for contributions and remote participation is actively supported.* OARC38 will be a two-day hybrid meeting held on July 30th and 31st, 2022 starting at 10 am (Eastern). The onsite part of the meeting will be co-located with IETF 114 (Philadelphia). The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is an *hybrid* workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** 2022-05-01 Submissions open via Indico 2022-06-20Deadline for submission (23:59 UTC) 2022-06-21Initial Contribution list published 2022-06-28Full agenda published 2022-07-12Deadline for slideset submission and Rehearsal 2022-07-30OARC 38 Workshop - Day 1 2022-07-31OARC 38 Workshop - Day 2 The Registration page and details for presentation submission are published at:https://www.dns-oarc.net/oarc38 <https://www.dns-oarc.net/oarc38> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARC 38: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * *Remote speakers have mandatory rehearsal on 2022-07-12 at* *15:00 UTC*. It would be very useful to have your slides (even if draft) ready for this. *Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens.* If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via *Manu Bretelle, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 38 Call for Contributions
OARC 38 will be a two-day hybrid meeting held on July 30th and 31st, 2022 starting at 10 am (Eastern)*. *The onsite part of the meeting will be colocated with IETF 114 (Philadelphia). The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is an *hybrid *workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** 2022-05-01 Submissions open via Indico 2022-06-20Deadline for submission (23:59 UTC) 2022-06-21Initial Contribution list published 2022-06-28Full agenda published 2022-07-12Deadline for slideset submission and Rehearsal 2022-07-30OARC 38 Workshop - Day1 2022-07-31OARC 38 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc38> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARC 38 * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * *Remote speakers* *have mandatory** rehearsal on** 2022-07-12 at 15:00 UTC.* It would be very useful to have your slides (even if draft) ready for this. *Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens.* If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via *Manu Bretelle, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 37 Schedule is Published
Hello friends, The schedule for OARC 37 is now published and can be viewed here: https://www.dns-oarc.net/oarc37. Registration is required to be able to attend. The attendees have an option to attend in-person or online. In-person attendees please read about the Covid-19 protocol that's published on the OARC 37 website. Please remember to sign-up for Mattermost chat <http://chat.dns-oarc.net/> and join the Workshops channel. Thank you, Manu Bretelle DNS-OARC Programme Committee ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 37 Workshop, Extending Call for Contributions
The Program Committee has decided to extend the Call for Contributions until 17 Jan 2022 23:59 UTC. The OARC Board has decided that OARC 37 will be a one day hybrid conference. Thank you if you've already submitted a proposal. We still haven't filled the capacity and are able to accept more content. Please note that remote participation is actively supported. Revised Workshop Milestones: * 27 December 2021 - Submissions open via Indico * 17 January 2022 - Deadline for submission (23:59 UTC) * 19 January 2022 - Initial Contribution list published * 21 January 2022 - Full agenda published * 3 February 2022 - Deadline for slideset submission and Rehearsal * 17 February 2022 - OARC 37 Workshop ( One day conference) The details for presentation submission are published at the Workshop website: https://www.dns-oarc.net/oarc37 If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Manu Bretelle for the DNS-OARC Programme Committee ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] OARC 37 Call for Contributions
OARC 37 will be an *online/hybrid* meeting on *February 17th and 18th 2022** starting **at 16:00 UTC (10:00 CST)**. *The onsite part of the meeting will be held in Austin, Texas. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: Managing DNS changes and propagation, release process, change management. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: Managing service capacity, failovers, disaster recovery. As it is an *online/hybrid *workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** * 27 December 2021 - Submissions open via Indico * 10 January 2022 - Deadline for submission (23:59 UTC) * 11 January 2022 - Initial Contribution list published * 18 January 2022 - Full agenda published * 3 February 2022 - Deadline for slideset submission and Rehearsal * 17 & 18 February 2022 - OARC 37 Workshop The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc37> DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups at DNS-OARC. See the registration page for details. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers of OARC 37: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * you will be expected to attend a rehearsal on *3rd February 2022**.* It would be very useful to have your slides (even if draft) ready for this. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via *Manu Bretelle, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] WG Call for Adoption: draft-pp-recursive-authoritative-opportunistic
I support adoption. I think opportunistic encryption will help drive adoption with safe fallbacks which in turn will help building operational experience, as well as will provide opportunities for a feedback loop between implementers and operators, learn, iterate, tweak, and come with best practises that will inform long term solutions. As someone working at an authoritative that provides ADoT [0], I would love to see more diverse adoptions than the current handful of resolver operators as the current data is currently skewed toward 1 specific use-case. Manu [0] https://engineering.fb.com/2018/12/21/security/dns-over-tls/ On Fri, Jan 29, 2021 at 5:24 AM Brian Haberman wrote: > All, > This starts a DPRIVE WG call for adoption for > draft-pp-recursive-authoritative-opportunistic > ( > https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/ > ). > The focus of the call is the protocol defined in the draft. Please reply > to the mailing list with your views on the WG adopting the document and > your supporting arguments. > > This call will end on February 12, 2021 at 11:59pm UTC. > > Regards, > Brian & Tim > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT? (with github url)
On Wed, Nov 11, 2020 at 4:00 PM Tony Finch wrote: > Manu Bretelle wrote: > > > > Totally fair, pretty sure there were no speaker notes ;) . The > > presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 . > > Originally, there was this draft > > > https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01 > > and the solutions in the slide deck were compiled from feedback/ideas > that > > came up while talking with other folks. > > Ooh, that video has lots of ideas, thanks! I think most of them are > slightly different angles on approaches that I rejected in my notes. (how > do I do a wry emoticon?) I'll try to summarise - please forgive me if I > have misunderstood... > > * DSPKI: vaguely dnscurve flavoured delegations, but putting an X.509 > SPKI into a new delegation RRtype. Comes under my "new kind of > delegation" heading. > The penultimate slide is a dnscurve like approach. > > (There's a twist that DSPKI seems to have an authenticator per zone, > so all servers are expected to share the same private key?) > yes and no, you could have multiple DSPKI records, but it is definitely an all or nothing, as in all servers would need to provide DoT. > > * Do9: per-server encryption hint without authenticator inside DS > records. Most of the badness under my "new DS algorithm" heading, > but with less key rollover churn. WebPKI authentication. > yop > > Joe Abley emphasized what I called the scalability issue. Wes Hardaker > made a slightly different point about correctness and synchronization of > apex and delegation records. Wes's point kind of strengthens the > scalability issue: a design that avoids per-zone configuration of any > kind for scalability reasons also avoids delegation mismatch problems. > yes, anything that will involve the parent will be a nightmare to keep synchronized unless stuff like CDS, CDNSKEY ... hence CDSPKI work, well as much as synchronisation is concerned. The "cloud provider" case, e.g few name servers for many zones is also tricky. I think in those cases, TLSA may be the best bet as this is under control of the nameserver, not the zone operator. Then there may be issue with being able to opt people in/out. I think in any cases, if you want to be able to gradually enroll your customers while giving the the choice to not be enrolled, you essentially need to provide them with a new NS that supports ADoT and have them move over. > Watson Ladd made a good point about decoupling signalling from > authentication. My prejudice was that if you are publishing a 1 bit ADoT > signal in the DNS you might as well publish a 256 bit authenticator; now > that I have gone through the options in detail I still think that is true. > And I think it implies that any approach to ADoT based on in-band > signalling should avoid relying on any records published in the DNS, > because then the in-band signal no longer does anything useful. > Decoupling signalling from authenticating could actually let zone owner decide to not do ADoT even though the provider supports it. > > [ I've been very bad at looking for and citing previous work, sorry > everyone... I belatedly realise the datatracker doesn't list expired > drafts, oops ] > > > Speaking of which, I think Brian Dickson did a good job of describing an > > "hybrid" approach which I had notes of, but never got to write down > > properly. Here is the link: > > > https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/ > > Yes, I think Brian's description is basically the same as what I have in > mind. On top of that I've added a little complication, `dot--` hints so > that when a delegation requires glue, a resolver can still connect > directly over TLS without first getting the TLSA records. I am unsure if > these hints are really needed... > That hint could be downgraded, but if not, can be used to fetch the TLSA record over an unauthenticated TLS connection and then validating it. I suppose it just obfuscate the zone, which may be useful *if* multiple name server names are behind the same IP and/or name server name matches the zone name (because TLSA record would be against name server name, not zone). Unless the query to the parent zone was using ADoT, that information may already be known from someone on-path. Manu > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Channel Islands: South to southeast 6 to 7, locally gale 8 with gusts to > 50kt, > veering west to southwest 5 to 7 before midnight, decreasing 4 to 5 around > dawn, locally 6 mid-channel, backing southwest to south in the afternoon. > Rather rough to rough, occasionally moderate in th
Re: [dns-privacy] how can we ADoT? (with github url)
On Wed, Nov 11, 2020 at 1:20 PM Tony Finch wrote: > Manu Bretelle wrote: > > > Having this as an ID or possibly a github repo may make it easier to > refer > > to/iterate than just this email. > > Yes! https://github.com/fanf2/draft-dprive-adot Thanks! > > > > I had attempted to quickly categorize some of those approaches (albeit a > > much smaller list) in a matrix in [0] but did not follow through since. > > > > [0] > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 > > Ah, I haven't been paying enough attention to meetings so I missed this! I > think I need the speaker notes to understand it properly :-) > Totally fair, pretty sure there were no speaker notes ;) . The presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 . Originally, there was this draft https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01 and the solutions in the slide deck were compiled from feedback/ideas that came up while talking with other folks. > > Your title "DoT for insecure delegations" is interesting: one of the > problems with what I have written so far is that it is too much a post-hoc > justification for using TLSA records to support ADoT. So I have built > nameserver authentication on top of TLSA on top of DNSSEC. > Speaking of which, I think Brian Dickson did a good job of describing an "hybrid" approach which I had notes of, but never got to write down properly. Here is the link: https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/ My TL;DRed notes, in the context of serving zones across name servers in (multiple) out-of-bailiwick zones, that I think echoes Brian's more throughout description: Other approaches to signalling DoT support to the recursive nameservers may be through the presence of TLSA record, special record at the name server side. In the end, the name server zone owner will have to be authoritative, such authoritative answer can only be validated if it is signed. By separating zones from nameservers, one can provide DNSSEC signing at the name server zone level without having to enforce it at the zones which are served. Having multiple name server zones would: - allow enabling DNSSEC on a subset of the nameservers without risking impacting all the DNS traffic. - allow to stage key roll on a subset of the nameservers, and ensuring that in the worst case, only a subset of the traffic is impacted in case of mishap. > One of my unstated assumptions is that DoT will be problematic for TLDs, > and (with QNAME minimization) it matters more for leaf zones, so it is > likely to be deployed there first. But DNSSEC is deployed to a much higher > proportion of TLDs than leaf zones, so there's a good chance I'm wrong. > yeah, and this is where zones hosted by DNS providers may benefit of this hybrid approach if the providers are supporting DNSSEC for their name server zones. But I just quickly checked Route53 and Google Domain, and none of them have their NS names signed. Manu > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Shetland Isles: Southerly 6 to gale 8, decreasing 4 or 5 later in west. > Rough > or very rough. Rain or drizzle. Moderate or poor, becoming good later in > west. > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT?
Thanks Tony for the exhaustive list of approaches with their pros and cons, helping in deciding where the tradeoff may be made. Having this as an ID or possibly a github repo may make it easier to refer to/iterate than just this email. I had attempted to quickly categorize some of those approaches (albeit a much smaller list) in a matrix in [0] but did not follow through since. Thanks, Manu [0] https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote: > I haven't seen anything written down that explains why it is difficult to > do DoT to authoritative servers. There was a good discussion earlier this > year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some > of the issues. I have done a braindump that attempts to cover all the > angles reasonably systematically. I expect I haven't quite reached that > goal though, so I hope this will provoke some informative comments :-) > Since draft submission is closed, I'll paste it here for your delectation. > > > ## Explicit encryption support signal > > How can a resolver know an authoritative server supports encryption? > There are three basic alternatives: > > 1. No explicit signal: the resolver tries to make an encrypted > connection, and falls back to cleartext if it gets an ICMP > unreachable error or connection timeout. > > This is problematic because connection timeouts can be very slow, > especially if the resolver tries multiple encrypted transports. > This is also is vulnerable to downgrade attacks. > > The working group consensus is that an explicit signal is > required. > > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the > resolver starts by connecting in the clear, and upgrades to an > encrypted connection if the authoritative server supports it. > > This is vulnerable to downgrade attacks. The initial cleartext > connection adds latency, and would need to be specified carefully > to avoid privacy leaks. > > 3. Signal in DNS records: the resolver makes extra queries during > iterative resolution to find out whether an authoritative server > supports encryption, before the resolver connects to it. > > The extra queries add latency, though that can be mitigated by > querying concurrently, and by placing the new records on the > existing resolution path. > > DNSSEC can provide authentication and downgrade protection. > > This specification takes the last option, since it is best for > security and not too bad for performance. > > > ## Where can nameserver encryption records go? > > Where can we put the new DNS records to signal that a nameserver > supports encryption? There are a number of issues to consider: > > 1. Performance: we don't want the extra queries to slow down > resolution too much; > > 2. Scalability: is encryption configured per nameserver? per zone? > > 3. Authentication: DNSSEC does not protect delegation NS records or > glue address records; > > 4. DNS data model: we ought to re-use existing RRtypes according to > their intended purpose; > > 5. DNS extensibility: make use of well-oiled upgrade points and > avoid changes that have a track record of very slow deployment; > > 6. EPP compatibility: a zone's delegation is usually managed via the > Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731] > [@?RFC5732] so any changes need to work with EPP. > > The following subsections discuss the possible locations, and explain > why most of them have been rejected. > > > ## In the reverse DNS? > > Given a nameserver's IP address, a resolver might make a query like > > _853._tcp.1.2.0.192.in-addr.arpa.TLSA? > > This possibility is rejected because: > > * It would be very slow: after receiving a referral, a resolver > would have to iterate down the reverse DNS, instead of immediately > following the referral. > > * At the moment the reverse DNS refers to the forward DNS for NS > records; this would also make the forward DNS refer to the reverse > DNS for TLSA records. Dependency loops are best avoided. > > * It's often difficult to put arbitrary records in the reverse DNS. > > * Encryption would apply to the server as a whole, whereas the > working group consensus is that it should be possible for > different zones on the same server to use encrypted and > unencrypted transports. > > > ## A new kind of delegation? > > In theory, DNSSEC provides a way to update the DNS data model, along > the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea > is to introduce new DNSSEC algorithm types which indicate that a zone can > include new types of records that need special validation logic. > Existing validators will be able to resolve names in the zone, but > will treat it as insecure. > > We might use this upgrade strategy to introduce new
Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative
Yes. I think it is worth doing. Manu On Thu, Aug 6, 2020 at 7:59 AM Paul Hoffman wrote: > Greetings again. The following is a short text-based version of my slides > from last week's WG meeting. I'd like to find out if this is one of the use > cases that the WG would be interested in dealing with. > > Use case: Opportunistic encryption for recursive to authoritative > > In this use case, a resolver operator says “I’m happy to use encryption > with the authoritative servers if it doesn’t slow down getting answers by > much”, and an authoritative server says “I’m happy to use encryption with > the recursive resolvers if it doesn’t cost me much”. > > Opportunistic encryption is defined in RFC 7535. From the abstract: > "Protocol designs based on Opportunistic Security use encryption even when > authentication is not available, and use authentication when possible, > thereby removing barriers to the widespread use of encryption on the > Internet." > > The assumptions behind the use case are: > • More encryption is good for the Internet > • Resolver vendors are smart and motivated > • Most resolvers don’t validate with DNSSEC and may never want to > • Authoritative operators don’t care much about encryption, but some would > turn it on because more encryption is good for the Internet > • Other use cases for authentication stronger than opportunistic may > appear and would co-exist with this one > > The other slides had thoughts about possible solutions that implement this > use case, but before we go there, I wanted to find out if more than a > handful of people here are interested in this use case. If so, I could turn > the above into a draft with some possible solutions for us to bang on. > > --Paul Hoffman > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for Adoption: draft-huitema-dprive-dnsoquic
I support adoption and I am willing to review. Manu On Wed, Apr 8, 2020 at 9:41 AM Tim Wicinski wrote: > > This starts a Call for Adoption for draft-huitema-dprive-dnsoquic > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huitema-dprive-dnsoquic/ > > Please review this draft to see if you think it is suitable for adoption > by DPRIVE, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 22 April 2020 > > Thanks, > tim/brian > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] ADoT signalling
FYI, I tried to cover some alternatives with their pros/cons during IETF104 DPRIVE meeting: https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01.pdf Seems there is a fair intersection with the one available in this draft. Manu On Mon, Nov 4, 2019 at 11:55 AM John R Levine wrote: > On Sun, 3 Nov 2019, John Levine wrote: > > I thought it might be useful to make a list of possible ways to signal > > that a server offers ADoT: > > > > https://datatracker.ietf.org/doc/draft-levine-dprive-signal/ > > Did another version with more possibilities. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
