[TLS] Re: TLS WG Virtual Interim on FATT Process
Thanks to all those who participated in the poll. Unfortunately, we couldn’t schedule a time where everybody could attend. The following time slot had the most people: > Begin forwarded message: > > From: IETF Meeting Session Request Tool > Subject: interim-2024-tls-02 interim approved > Date: October 1, 2024 at 20:09:13 EDT > To: , > > > An interim meeting for tls has been approved or does not require additional > approval. > A message has been sent to the secretariat requesting the interim be > announced. > > > - > Working Group Name: Transport Layer Security > Area Name: Security Area > Session Requester: Sean Turner > > Meeting Type: Virtual Meeting > > Session 1: > > Date: 2024-10-16 > Start Time: 14:00 America/New_York > Duration: 02:00 > Remote Participation Information: > https://meetings.conf.meetecho.com/interim/?group=7627d881-2175-4086-899f-657548e64b52 > Agenda Note: > > I will make sure to send reminders out prior to meeting. We will also record this session. And, we plan to have “the plan” out in advance (like a week) so that those that can’t make it in person can provide comments. Cheers, spt > On Sep 23, 2024, at 16:53, Sean Turner wrote: > > Hi! Thanks to all those who have already filled out the poll. I am hoping to > close this out by Friday so I will send daily reminders until then. > > Cheers, > spt > >> On Sep 23, 2024, at 12:05, Sean Turner wrote: >> >> The chairs would like to have an interim to review the FATT (Formal Analysis >> Triage Team) process. We are still working out the proposal, but we would >> like to get this meeting scheduled to review any feedback / comments once we >> do post the process. Please fill out the following with your available times >> if you are interested in attending: >> >> https://doodle.com/meeting/participate/id/aMoXAp1d >> >> Thanks, >> Deirdre, Joe, & Sean > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [DNSOP] Re: Re: AD review draft-ietf-tls-svcb-ech
Deirdre Connolly wrote on 2024-09-30 10:59: > We could add a recommendation like "Clients using ECH SHOULD select a DNS resolver that they trust to preserve the confidentiality of their queries and return authentic answers, and communicate using an authenticated and confidential transport", but this draft seems like an odd place for that text. I support this more than the DNSSEC recommendation i would not. much of the world now relies upon inauthentic dns responses for defense against bad actors. here's how US NCCIS puts it: https://www.cisa.gov/news-events/alerts/2021/03/04/joint-nsa-and-cisa-guidance-strengthening-cyber-defense-through it is precisely to prevent protective dns from being bypasses that many of us block all off-net DNS including off-net HTTPS to known DoH services. malicious insiders, intruders, malware, and poisoned supply chains do not want their DNS lookups to be monitored or blocked. we can argue about where the advice should and shouldn't appear, but we mustn't appeal to "response authenticity" when recommending a recursive DNS service. response authenticity is what our attackers need. -- P Vixie ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Reminders
Hi! Here’s a list of a select goings on: 1. TLS Virtual Interim concerning the Trust Tussle; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/et9dCsZYHhmoXaAdybeXdq37PnE/ It’s today in under an hour from now. 2. Poll for TLS Virtual Interim concerning the FATT Process; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/76yqBw5rOLlByPtPGXU8YJl6xO4/ Plan to close this poll out today! 3. Consensus Call for an early code point for draft-ietf-tls-key-share-prediction; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/se4Lj79-6pTLGTQ6kleE9ZwTs4o/ Closes 8 October. 4. Consensus Call for an early code point for draft-ietf-tls-tlsflags; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/0pCMGxpHxPSPnDPKGCFQmCE9b_I/ Closes 11 October. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech
On Mon, Sep 30, 2024 at 3:12 PM Ben Schwartz wrote: > OK, done: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 > Looks good other than some minor suggestions I made. Thanks for correctly pointing out that DNSSEC doesn't help you when you are dealing with privacy and untrusted DNS servers. As for the RFC1034 reference, Warren suggested to maybe use: "DNS (see RFC1034, BCP219)" (where BCP219 is the latest DNS Terminology doc). Paul -- > *From:* Salz, Rich > *Sent:* Monday, September 30, 2024 1:29 PM > *To:* Ben Schwartz ; Eric Rescorla ; Paul > Wouters > *Cc:* draft-ietf-tls-svcb-ech.auth...@ietf.org < > draft-ietf-tls-svcb-ech.auth...@ietf.org>; ; > dn...@ietf.org WG > *Subject:* Re: [TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech > > We could add a recommendation like "Clients using ECH SHOULD select a DNS > resolver that they trust to preserve the confidentiality of their queries > and return authentic answers, and communicate using an authenticated and > confidential transport", > > We could add a recommendation like "Clients using ECH SHOULD select a DNS > resolver that they trust to preserve the confidentiality of their queries > and return authentic answers, and communicate using an authenticated and > confidential transport", but this draft seems like an odd place for that > text. > > > > When DNS SVCB has an ech entry, DNS is being used a little differently > than your conventional DNS for ipaddress, since you can use TLS to > authenticate what DNS told. For ECH you cannot. In other words, I think > recommendation, or warning in security considerations, is exactly right for > this document. > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] I-D Action: draft-ietf-tls-wkech-06.txt
Internet-Draft draft-ietf-tls-wkech-06.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: A well-known URI for publishing service parameters Authors: Stephen Farrell Rich Salz Benjamin Schwartz Name:draft-ietf-tls-wkech-06.txt Pages: 16 Dates: 2024-10-01 Abstract: We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Note This note is to be removed before publishing as an RFC. The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-06 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-wkech-06 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-wkech-06.txt
This version addresses the issue raised by David Benjamin, in that there is really nothing ECH specific about the data structures so it's more generic. Comments appreciated ... On 10/1/24, 3:14 PM, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-tls-wkech-06.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: A well-known URI for publishing service parameters Authors: Stephen Farrell Rich Salz Benjamin Schwartz Name: draft-ietf-tls-wkech-06.txt Pages: 16 Dates: 2024-10-01 Abstract: We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. ... ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
