Thanks for this! You captured my intent perfectly.
Joe
From: Thomas Fossati <thomas.fossati@xxxxxxxxxx>
Date: Wednesday, June 11, 2025 at 03:24
To: Joe Clarke (jclarke) <jclarke@xxxxxxxxx>
Cc: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>, draft-ietf-tls-dtls-rrc.all@xxxxxxxx <draft-ietf-tls-dtls-rrc.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, tls@xxxxxxxx <tls@xxxxxxxx>
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
|
