# UTA@IETF-114 {#utaietf-114} Wednesday, July 27, 2022 Session II, 12:15-13:15 Local time (16:15-17:15 UTC), Liberty B Chairs: Leif Johansson, Valery Smyslov # Agenda {#agenda} * **5 min**. Administrativia (zulip scribes, note takers), Note Well, Agenda bashing * **15 min**. IP Address SANs in 6125-bis (*draft-ietf-uta-rfc6125bis*) * **15 min**. TLS/DTLS 1.3 Profiles for the Internet of Things (*draft-ietf-uta-tls13-iot-profile*) * **15 min**. Updates to the Cipher Suites in Secure Syslog (*draft-ietf-uta-ciphersuites-in-sec-syslog*) * **5 min**. Open Mic * **5 min**. Closing Note takers: # IP Address SANs in 6125-bis {#ip-address-sans-in-6125-bis} Chair: What is the timeline impact of the proposed change? Rich: Probably not that much time. Could still be done before the next IETF meeting. Alessandro Ghedini: We do have use cases for HTTPS and other secure TLS connections to IP addresses. For example, https://1.1.1.1/. So ideally, I would want to see this supported. I can help to review PRs, etc. Martin Thomson: It is a little bit more work than just adding one bullet point and removing "we don't do IPs". I wasn't able to identify everything that needs to be change very confidently, but I think the most interesting section is the one about service identifiers, but the rest of it seems easy. This PR should get us 90% of the way, although the last 10% is the hardest part. HTTP has what it needs, but I don't think the text in RFC 9110 is particularly good. This document is that much better job, so I think the work is worth doing even if it means one more cycle. I'm happy to help, I tried to help, but that's about the extent of it because (Rich knows the document better). Rich: BTW, we're preparing another document that would propose using IP addresses in SNI via in-addr.arpa. Alexey Melnikov: I would like this done, but I am not convinced that doing it in the same document is a good idea. Chair: Would you write it? Alexey Melnikov: I could help, yes. Martin Thomson: Alexey, why? Alexey Melnikov: I think your comments about certain things not applying to IP addresses makes me a bit concerned. If it doesn't fit quite right, just make it a different document. Martin: Have you looked at the changes that I've proposed? Alexey: I haven't looked at them yet. Martin: I think this document is a better place for that because there are some interactions with the existing pieces. It's not super-complicated, but having another document that surgically amends the pieces of anexisting document to add suppor for IP addresses is somewhat more complicated than doing it here while the patient is open. Alexey: I can commit to reviewing the proposed text in the next few days? Chair: Does anyone feel strongly against progressing PR 54? Rich: I've sort of come around to Martin's viewpoint. Viktor Dukhovni: Are there name constraint issues that would add some complexity for IP-ID? Do we have a specification for IP-ID name constraints? Would that be in this document or a new one? Rich: This document doesn't discuss name constraints. That would be RFC 5280 bis, which is not going to happen. There's nothing workable about name constraints for IP addresses. Martin Thomson: It sounds like there are no name constraints for IP-IDs, nor will there ever be given that RFC 5280 is set in stone. Maybe that's a good thing. Rich: I can do this so long as the group doesn't expect anything before IETF 115. Martin: Let's not expect Rich to do all of the work. The editors can collaborate. If they want me to do something I can do that. If Alexey or anyone else wants to do the same, we can do that. I propose we leave it to the editors, and if we get more feedback from people who've committed to review then we'll discuss that. Rich: Please review the current draft. I think it's pretty simple, and as we add IP addresses I'd like not to lose that any more than necessary. Erik Nygren: RFC 5280 does define name constraints for IP addresses. # TLS/DTLS 1.3 Profiles for the Internet of Things {#tlsdtls-13-profiles-for-the-internet-of-things} Hannes: There were also several other comments from Michael Richardson that we are working to address, but we haven't incorporated the changes because we are waiting to confirm that they are satisfactory. Hannes (on renegotiation): We are considering whether renegotiation was really the right approach for checking whether certificates are still valid. If we define an extension Martin Thomson: Have you considered using Exported Authenticators for this purpose? Hannes: No. How would that work? Martin: At the application layer, one side would challenge the other to produce an Exported Authenticator, and it would return something that is essentially a certificate, or just the authenticator. Hannes: It's probably worthwhile to explore with Steffen Fries of Siemens. Martin: There are a number of things you can do that might help. Rekeying gives you fresh keys and forward secrecy, and confirms the validity of the credentials. What it doesn't do is give you fresh entropy for the session. But in an IoT use case that may be desirable. Hannes: We need to enumerate the attacks that we care about. Is it compromise of the long-term key? This can't detect whether the long-term keys have been compromised. So maybe we can use this to start a conversation about what the requirements are. Martin: (+1) Steffen Fries: The requirement for renegotiation is used to trigger a Certificate Revocation check. When checking to TLS 1.3, we would offload that functionality to the application because there is no trigger coming from the TLS stack, because renegotiation is no longer allowed in TLS 1.3 So basically we would have a timer in the application, and when the time is up we would repeat the revocation check. In TLS 1.3 we have the possibility to take the certificate that comes out of the handshake and the application must store it so it can repeat the revocation check. The requirement comes from the problem that the certificate for a long-lived connection must be checked for its revocation state. Viktor Dukhovni: Steffen, what threats motivate the desire to know if the certificate is expired once the session is established? It would be good to discuss that on-list, to know the real reason rather than just continuing to do what we've been doing. > Technical difficulties preventing Steffen from replying. In Zulip, > Steffen wrote: > One of the reasons to recheck a certificate was that for expired > certificates or revoked certificates shall not be used to open a TLS > session. This requirement was taken over for long lived connections. > With renegotiation this could be checked in ongoing connections. In > TLS 1.3 it requires the application to do this verification, as > renegotiation cannot be used to trigger this. This in turn requires > the application to store the certificate Hannes: Regardless of the conclusion, we need to tell people who have been using renegotiation in TLS 1.2 what they should do in TLS 1.3. Hannes: We noticed that some of the default DTLS timer recommendations didn't work for IoT mesh networks, so they were adjusted in the recommendations for TLS 1.2. We need to decide on similar adjustments in DTLS 1.3. We would like input from people using DTLS 1.3 in these kinds of networks. # Updates to the Cipher Suites in Secure Syslog {#updates-to-the-cipher-suites-in-secure-syslog} Chair: Volunteers for review? Viktor Dukhovni and Hannes Tschofenig volunteered to review. # Open Mic {#open-mic} Ben Schwartz: Seeking interest in certificate identities that cover IP ranges. This would be useful for ISP-driven DDR for encrypted DNS via home gateways with IPv6 support. Viktor Dukhovni: Some servers for interop reasons prefer not to ask for client certificates by default. So if the client knows that it is desirable to present a certificate, but the server won't ask for it by default, it would be nice to offer something early on like "I have a certificate, please ask for it". I'm interested in doing this for email. I could do this in the EHLO, but it seems like the wrong layer. Should this be in UTA? TLS? Another working group? Chair: So the question is: where do TLS extensions go that might be applicable to specific application domains? Roman: I think it's hard to have a universal answer to that. We would have to look at the charter. Martin: There's nothing stopping anyone here, or even outside of the IETF, from defining new TLS extensions. However, the UTA charter may prevent that. In that case, we can simply recharter. Roman: Personally I view UTA as a catch-all, and we can recharter to cover whatever is needed to make use of the expertise in this group. Chair: I would encourage you to bring a proposal to the group, and then we can discuss adoption.