Hi Joe,
On Tue, Jun 03, 2025 at 02:21:47PM +0100, Joe Clarke (jclarke) wrote:
When you say, the choice may be offered as a configuration option to the user,
who is the user in this case? Is this the client, initiator, responder? This
felt vague to me.
What we mean by "user" is the user of the TLS implementation.
[JMC] Thanks for the changes. I’m still wondering where this would
need to be. There are two “users” of a TLS implementation (client and
server). Would this be more of a config on the client side where they
wouldn’t want lag (for example)?
ISTM the configurability should be symmetrical, there is no preferred
angle.
My overarching question on the OPS front is, while it might be out of scope for
this document, would it be valuable to mention any operational logging or
statistics that may be required around RRC? that is, logging RRC failures,
counting the number of times an RRC is needed, recording the time it takes to
validate RRCs? The details might spawn other work, but noting any interesting
operational events could be helpful for implementors.
I am not an OPS person, and I am not particularly familiar with what
SNMP/NETMOD provides regarding the export of statistics about TLS/DTLS
sessions.
I am not familiar with QLOG either, but I guess it might have modelled
events that are very similar to what RRC would need and could be used as
a starting point.
As you say, though, this would be separate work, so I wouldn't know how
to act on it at this point other than discussing your intriguing
observation with other implementers :-)
[JMC] We’re actually working on a revision to RFC 5706 right now 😊 .
Thanks for the reference. This is a whole new world opening up before
my eyes! :-)
This also prompted me to look into RFC9312 to see what QUIC has to say
about path validation. Its section 4.3 looks like it may contain some
relevant information, at least conceptually. In particular, it seems to
me that the boxes that could interfere with RRC are probably L4+, i.e.,
load balancers and firewalls, rather than routers or switches.
Would that be operational consideratiosn worth capturing?
The specifics would certainly be fodder for new work, but would It be
helpful to have a sentence or short paragraph to implementors in this
draft that recommends logging RRC failures? For example, Initiators
MAY wish to log any unsuccessful RRC operations for Security
Information and Event Management (SIEM) and troubleshooting purposes.
In general, adding metrics about path validation seems like a good
suggestion. This applies to both successful and unsuccesful attempts, I
think.
It's just a drop in the ocean of stats that a stack might care about,
but it's a start :-)
As I pointed out upthread, it'd be interesting to have a comprehensive
look at QLOG and see if we can transplant any of that into (D)TLS.
cheers, t
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
