Thanks for this! You captured my intent perfectly. Joe
From: Thomas Fossati <[email protected]> Date: Wednesday, June 11, 2025 at 03:24 To: Joe Clarke (jclarke) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: draft-ietf-tls-dtls-rrc-13 ietf last call Opsdir review Hi Joe, We have just published -15, which adds an "Operational Considerations" section [1] that discusses logging anomalies and middlebox interference. Let us know if you have any questions or further suggestions. Thanks again for your time, cheers! [1] https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-15.html#section-10 On Wed, Jun 04, 2025 at 04:44:26PM +0100, Thomas Fossati wrote: >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 -- [email protected] To unsubscribe send an email to [email protected]
