[TLS] Re: draft-ietf-tls-dtls-rrc-13 ietf last call Opsdir review

[Thomas Fossati <[e-mail]>]

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