UTA@IETF-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

• 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

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

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

Chair: Volunteers for review?
Viktor Dukhovni and Hannes Tschofenig volunteered to review.

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.