[OPSAWG]WG LC: draft-ietf-opsawg-tacacs-tls13
With shepherd in hand (thanks, Med), we are kicking off a two-week working group last call for the TACACS+ secured with TLS 1.3 draft. This draft has received several reviews, and the authors have addressed all outstanding comments. That said, I have re-requested reviews from SEC DIR and OPS DIR to confirm it has resolved previously-raised issues. The question about port seems to have been addressed with a custom port being an appropriate proposal. The chairs would like all comments and feedback by July 8, 2024. We will be re-running the IPR poll in parallel. (Copying TLS in Applications [uta] list for more TLS application-layer visibility.) Thanks. Joe ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]IPR POLL: draft-ietf-opsawg-tacacs-tls13
We’re up to WG LC on this draft. We want to reconfirm any known IPR related to this work: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft” or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules” or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. Also please send the response to the list above, and not unicast it. As of this time, no IPR has been disclosed on this draft. Joe ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Re: WG LC: draft-ietf-opsawg-tacacs-tls13
Grrr, forgot the link for convenience. Please provide WG LC reviews for the following draft: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ Thanks. Joe From: Joe Clarke (jclarke) Date: Monday, June 24, 2024 at 08:36 To: opsawg@ietf.org Cc: u...@ietf.org Subject: [OPSAWG]WG LC: draft-ietf-opsawg-tacacs-tls13 With shepherd in hand (thanks, Med), we are kicking off a two-week working group last call for the TACACS+ secured with TLS 1.3 draft. This draft has received several reviews, and the authors have addressed all outstanding comments. That said, I have re-requested reviews from SEC DIR and OPS DIR to confirm it has resolved previously-raised issues. The question about port seems to have been addressed with a custom port being an appropriate proposal. The chairs would like all comments and feedback by July 8, 2024. We will be re-running the IPR poll in parallel. (Copying TLS in Applications [uta] list for more TLS application-layer visibility.) Thanks. Joe ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Re: WG LC: draft-ietf-opsawg-tacacs-tls13
On Jun 24, 2024, at 8:38 AM, Joe Clarke (jclarke) wrote: > > Grrr, forgot the link for convenience. Please provide WG LC reviews for the > following draft: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ I have general concerns about the document, which I've raised before. The document is extremely small, and offers little guidance around most implementation and operational issues related to OpenSSL. I've made these comments before, and there appears to be few changes which address my concerns. For similar issues with there protocols, I would refer the reader to RFC 9190 for discussions of EAP over TLS, and RFC 6614 / RFC 7360 for discussions of RADIUS over TLS. Both of those documentations contain significantly more content which can guide the reader. In contrast, this document comes across as "send TACACS over TLS". Almost every operational or implementation consideration is left as an exercise for the reader. Experience shows that this is a way to get non-interoperable implementations. The document is also Standards Track. Has anyone implemented it? Given the lack of guidance in the draft, and the lack of experience with implementations, I'd suggest that "Experimental" is more appropriate. Alan DeKok. ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-16.txt
Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-16.txt is now available. It is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title: Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements Authors: Mohamed Boucadair Benoit Claise Name:draft-ietf-opsawg-ipfix-tcpo-v6eh-16.txt Pages: 26 Dates: 2024-06-24 Abstract: This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-tcpo-v6eh-16.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-16 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Re: process forward for draft-ietf-opsawg-mud-iot-dns-considerations
Hi Michael, Thank you for addressing Paul’s and Roman’s comments. I will wait for Roman to confirm whether the changes you have made, mostly deleting the paragraphs that he put a DISCUSS on, whether he is ok with removing his DISCUSS on the document. At the same time, looking at the number of diffs between -13 and the latest version of the draft, including a completely new section on “Interactions with mDNS and DNSSD”, another WG LC, albeit shorter (1 week), would be in order. Cheers. > On Jun 19, 2024, at 2:48 PM, Michael Richardson wrote: > > > Hi, I posted a -15 document that I hope addresses Roman's DISCUSS. > Paul has changed his Abstain to a No Objection a few weeks ago. > > As Mahesh (the OPSAWG AD) returned the document to the WG in early April, my > understanding, however, is that the WG may need to do another WGLC on it. > Perhaps Mahesh will decide to skip that or not. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > Mahesh Jethanandani mjethanand...@gmail.com ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Re: process forward for draft-ietf-opsawg-mud-iot-dns-considerations
Mahesh Jethanandani wrote: > Thank you for addressing Paul’s and Roman’s comments. I will wait for > Roman to confirm whether the changes you have made, mostly deleting the > paragraphs that he put a DISCUSS on, whether he is ok with removing his > DISCUSS on the document. Fantastic. Probably have to poke him directly to get an answer. > At the same time, looking at the number of diffs between -13 and the > latest version of the draft, including a completely new section on > “Interactions with mDNS and DNSSD”, another WG LC, albeit shorter (1 > week), would be in order. Works for me. > Cheers. >> On Jun 19, 2024, at 2:48 PM, Michael Richardson >> wrote: >> >> >> Hi, I posted a -15 document that I hope addresses Roman's DISCUSS. >> Paul has changed his Abstain to a No Objection a few weeks ago. >> >> As Mahesh (the OPSAWG AD) returned the document to the WG in early >> April, my understanding, however, is that the WG may need to do >> another WGLC on it. Perhaps Mahesh will decide to skip that or not. >> >> -- >> Michael Richardson . o O ( IPv6 IøT consulting >> ) Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> > Mahesh Jethanandani mjethanand...@gmail.com > > Alternatives: > -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Roman Danyliw's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-15: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-15: 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 https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/ -- COMMENT: -- Thank you to Chris Wood for the SECDIR review. Thank you for addressing my DISCUSS feedback and select COMMENT. ** Section 4.1 The current firmware model of the device is sometimes provided and then the authoritative server provides a determination if a new version is required and, if so, what version. What’s the authoritative server in this model? Is it the “vendor system” mentioned in the previous sentence? ** Section 5. What is the actionable BCP or design guidance from this section? ** Section 6. The difficult part is determining what to put into the MUD file itself. There are currently tools that help with the definition and analysis of MUD files, see [mudmaker]. The remaining difficulty is now the actual list of expected connections to put in the MUD file. An IoT manufacturer must now spend some time reviewing the network communications by their device. How is this germane to MUD and DNS? ** Section 7. I found this Privacy Considerations lacking a basic explanation of the DNS-focused threat model. I think the start of that threat assessment is that “many IoT devices are automatically configured to connect to the public internet to enable automatic updates, send telemetry to the manufacturers, or enable integration with manufacturer or third-party services”. Using the tradeoff template of the security considerations in Section 8, a privacy consideration trade-off might be that “device owners/operators want to leak as little onto the internet and to the device manufacturer while still getting the functionality of the IoT device”. ** Section 7. IoT devices that reach out to the manufacturer at regular intervals to check for firmware updates are informing passive eavesdroppers of the existence of a specific manufacturer's device being present at the origin location. -- Is it common in an enterprise setting for IoT devices to be able to auto-updated themselves from firmware download off the internet? In my limited enterprise experience, other end-points and network device are typically managed. Is there some nuance that these devices can only be managed the manufacturer? -- In an enterprise setting wouldn’t it be best practice to prevent devices from beaconing out to the internet with DNS blackholing or IP address filters? ** Section 7. IoT device manufacturers are encouraged to find ways to anonymize their update queries. For instance, contracting out the update notification service to a third party that deals with a large variety of devices would provide a level of defense against passive eavesdropping. This is good advice. -- Is the DNS footprint of most IoT devices predominately queries for updates? To revisit the previous comment about the threat model, don’t some IoT devices use DNS to initiate traffic for more things than just update queries negating the benefit of a third-party update infrastructure? -- Not knowing much about this is done in production, is this realistic guidance based on current IoT manufacturer practices? Collecting less data from device owner/operators seems to be opposite of the trends I have seen. ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
