Re: [TLS] Working Group Last Call for SSLKEYLOG File
Noted in the Shepherd write-up. spt > On Apr 2, 2024, at 20:30, Stephen Farrell wrote: > > > Hiya, > > This is basically for the record and not an objection to proceeding. > > On 02/04/2024 17:34, Sean Turner wrote: >> This WGLC has concluded. There is consensus to move this document forward. >> The material change was to add a security consideration about forward >> secrecy guarantees being negated if the key material is leaked: >> https://github.com/tlswg/sslkeylogfile/pull/7/files >> We will not be asking the formal analysis folks to weigh in on this I-D; we >> all know the file’s content are the keys to the kingdom. >> Martin: If you can spin a new version, I can get the Shepherd write-up >> drafted. > > I like the addition in -01 but would still have preferred if we > weren't so awfully oblique about the consequences of running a > production system with this logging enabled. > > Were it up to me (and it's not) I'd suggest an additional addition > along the lines of: > > "Systems that enable logging as described here are (while logging > is enabled) unlikely to be consistent with requirements to make use > of state-of-the-art protections, as e.g. is called-for by GDPR > article 32 [1]" > > I suppose one could also re-do the above suggested text to refer > to RFC6919, section 3:-) [2] > > Again, I'm not objecting to proceeding, just bemoaning what I see > as us being so oddly timid in calling out real issues. > > Cheers, > S. > > [1] https://gdpr-info.eu/art-32-gdpr/ > [2] https://datatracker.ietf.org/doc/html/rfc6919#section-3 > >> spt >>> On Mar 28, 2024, at 09:24, Sean Turner wrote: >>> >>> Just a reminder that this WGLC ends soon! >>> >>> spt >>> On Mar 12, 2024, at 10:57, Sean Turner wrote: This is the working group last call for the SSLKEYLOGFILE Format for TLS Internet-Draft [1]. Please indicate if you think the I-D is ready to progress to the IESG and send any comments to the list by 31 March 2024. The GH repo for the I-D can be found at [2]. Thanks, Joe, Deirdre, and Sean [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ [2] https://github.com/tlswg/sslkeylogfile >>> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Hiya, This is basically for the record and not an objection to proceeding. On 02/04/2024 17:34, Sean Turner wrote: This WGLC has concluded. There is consensus to move this document forward. The material change was to add a security consideration about forward secrecy guarantees being negated if the key material is leaked: https://github.com/tlswg/sslkeylogfile/pull/7/files We will not be asking the formal analysis folks to weigh in on this I-D; we all know the file’s content are the keys to the kingdom. Martin: If you can spin a new version, I can get the Shepherd write-up drafted. I like the addition in -01 but would still have preferred if we weren't so awfully oblique about the consequences of running a production system with this logging enabled. Were it up to me (and it's not) I'd suggest an additional addition along the lines of: "Systems that enable logging as described here are (while logging is enabled) unlikely to be consistent with requirements to make use of state-of-the-art protections, as e.g. is called-for by GDPR article 32 [1]" I suppose one could also re-do the above suggested text to refer to RFC6919, section 3:-) [2] Again, I'm not objecting to proceeding, just bemoaning what I see as us being so oddly timid in calling out real issues. Cheers, S. [1] https://gdpr-info.eu/art-32-gdpr/ [2] https://datatracker.ietf.org/doc/html/rfc6919#section-3 spt On Mar 28, 2024, at 09:24, Sean Turner wrote: Just a reminder that this WGLC ends soon! spt On Mar 12, 2024, at 10:57, Sean Turner wrote: This is the working group last call for the SSLKEYLOGFILE Format for TLS Internet-Draft [1]. Please indicate if you think the I-D is ready to progress to the IESG and send any comments to the list by 31 March 2024. The GH repo for the I-D can be found at [2]. Thanks, Joe, Deirdre, and Sean [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ [2] https://github.com/tlswg/sslkeylogfile ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
This WGLC has concluded. There is consensus to move this document forward. The material change was to add a security consideration about forward secrecy guarantees being negated if the key material is leaked: https://github.com/tlswg/sslkeylogfile/pull/7/files We will not be asking the formal analysis folks to weigh in on this I-D; we all know the file’s content are the keys to the kingdom. Martin: If you can spin a new version, I can get the Shepherd write-up drafted. spt > On Mar 28, 2024, at 09:24, Sean Turner wrote: > > Just a reminder that this WGLC ends soon! > > spt > >> On Mar 12, 2024, at 10:57, Sean Turner wrote: >> >> This is the working group last call for the SSLKEYLOGFILE Format for TLS >> Internet-Draft [1]. Please indicate if you think the I-D is ready to >> progress to the IESG and send any comments to the list by 31 March 2024. >> >> The GH repo for the I-D can be found at [2]. >> >> Thanks, >> >> Joe, Deirdre, and Sean >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ >> [2] https://github.com/tlswg/sslkeylogfile > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Minor suggestion to refer to -rfc84446bis: https://github.com/tlswg/sslkeylogfile/pull/8 aka let’s make a cluster! spt > On Mar 12, 2024, at 10:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to the list by 31 March 2024. > > The GH repo for the I-D can be found at [2]. > > Thanks, > > Joe, Deirdre, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ > [2] https://github.com/tlswg/sslkeylogfile ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Just a reminder that this WGLC ends soon! spt > On Mar 12, 2024, at 10:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to the list by 31 March 2024. > > The GH repo for the I-D can be found at [2]. > > Thanks, > > Joe, Deirdre, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ > [2] https://github.com/tlswg/sslkeylogfile ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
On 15/03/2024 03:43, Martin Thomson wrote: Reasonable statement. It's a variation on what we already have, but the focus on forward secrecy is worth a small paragraph: How about this: https://github.com/tlswg/sslkeylogfile/pull/7/files I think that's a good addition (with or without Dennis's comment). Thanks, S. On Thu, Mar 14, 2024, at 22:51, Dennis Jackson wrote: I have a suggestion which keeps things technical but hopefully addresses Stephen's concern: In Security Considerations: "TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it records the used session key and so invalidates many of the security claims made in RFC 8446. If SSLKEYLOGFILE is in use, the transferred data does not benefit from the security protections offered by RFC 8446 and systems using SSLKEYLOGFILE cannot be considered compliant with RFC 8446 or offering similar security to the protocol outlined in that draft." I don't think the wording there is quite right, but I do think the Security Considerations should clearly call out the impact on forward secrecy and RFC 8446 in general and so dissuade use. Best, Dennis On 12/03/2024 23:07, Eric Rescorla wrote: On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell wrote: I'll argue just a little more then shut up... On 12/03/2024 22:55, Martin Thomson wrote: Sorry also for a late suggestion, but how'd we feel about adding some text like this to 1.1? "An implementation, esp. a server, emitting a log file such as this in a production environment where the TLS clients are unaware that logging is happening, could fall afoul of regulatory requirements to protect client data using state-of-the-art mechanisms." I agree with Ekr. That risk is not appreciably changed by the existence of a definition for a file format. I totally do consider our documenting this format increases the risk that production systems have such logging enabled, despite our saying "MUST NOT." So if there's a way to further disincentivise doing that, by even obliquely referring to potential negative consequences of doing so, then I'd be for doing that. Aside from this particular case, I don't think technical specifications should "obliquely" refer to things. Technical specifications should be clear. -Ekr Hence my suggestion. S. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Reasonable statement. It's a variation on what we already have, but the focus on forward secrecy is worth a small paragraph: How about this: https://github.com/tlswg/sslkeylogfile/pull/7/files On Thu, Mar 14, 2024, at 22:51, Dennis Jackson wrote: > I have a suggestion which keeps things technical but hopefully > addresses Stephen's concern: > > In Security Considerations: > > "TLS1.3 requires the use of forward secret key exchanges (RFC 8446, > 1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it > records the used session key and so invalidates many of the security > claims made in RFC 8446. If SSLKEYLOGFILE is in use, the transferred > data does not benefit from the security protections offered by RFC 8446 > and systems using SSLKEYLOGFILE cannot be considered compliant with RFC > 8446 or offering similar security to the protocol outlined in that > draft." > > I don't think the wording there is quite right, but I do think the > Security Considerations should clearly call out the impact on forward > secrecy and RFC 8446 in general and so dissuade use. > > Best, > Dennis > > On 12/03/2024 23:07, Eric Rescorla wrote: >> >> >> On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell >> wrote: >>> >>> I'll argue just a little more then shut up... >>> >>> On 12/03/2024 22:55, Martin Thomson wrote: >>> > >>> >> Sorry also for a late suggestion, but how'd we feel about adding >>> >> some text like this to 1.1? >>> >> >>> >> "An implementation, esp. a server, emitting a log file such as this >>> >> in a production environment where the TLS clients are unaware that >>> >> logging is happening, could fall afoul of regulatory requirements >>> >> to protect client data using state-of-the-art mechanisms." >>> >>> > I agree with Ekr. That risk is not appreciably changed by the >>> > existence of a definition for a file format. >>> I totally do consider our documenting this format increases >>> the risk that production systems have such logging enabled, >>> despite our saying "MUST NOT." So if there's a way to further >>> disincentivise doing that, by even obliquely referring to >>> potential negative consequences of doing so, then I'd be for >>> doing that. >> >> Aside from this particular case, I don't think technical specifications >> should "obliquely" refer to things. Technical specifications should be >> clear. >> >> -Ekr >> >>> Hence my suggestion. >>> >>> S. >>> ___ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
I have a suggestion which keeps things technical but hopefully addresses Stephen's concern: In Security Considerations: "TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it records the used session key and so invalidates many of the security claims made in RFC 8446. If SSLKEYLOGFILE is in use, the transferred data does not benefit from the security protections offered by RFC 8446 and systems using SSLKEYLOGFILE cannot be considered compliant with RFC 8446 or offering similar security to the protocol outlined in that draft." I don't think the wording there is quite right, but I do think the Security Considerations should clearly call out the impact on forward secrecy and RFC 8446 in general and so dissuade use. Best, Dennis On 12/03/2024 23:07, Eric Rescorla wrote: On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell wrote: I'll argue just a little more then shut up... On 12/03/2024 22:55, Martin Thomson wrote: > >> Sorry also for a late suggestion, but how'd we feel about adding >> some text like this to 1.1? >> >> "An implementation, esp. a server, emitting a log file such as this >> in a production environment where the TLS clients are unaware that >> logging is happening, could fall afoul of regulatory requirements >> to protect client data using state-of-the-art mechanisms." > I agree with Ekr. That risk is not appreciably changed by the > existence of a definition for a file format. I totally do consider our documenting this format increases the risk that production systems have such logging enabled, despite our saying "MUST NOT." So if there's a way to further disincentivise doing that, by even obliquely referring to potential negative consequences of doing so, then I'd be for doing that. Aside from this particular case, I don't think technical specifications should "obliquely" refer to things. Technical specifications should be clear. -Ekr Hence my suggestion. S. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
This document does a good job of documenting current practice, and hence I support (and my thanks to Martin for addressing an issue I communicated to him off-list). I think that timestamping and/or autosegmenting entries in the file format would be a useful extension (current implementations, such as Wireshark, need to linearly search through potentially large SSLKEYLOG files). Y(J)S (usually just lurking on this list) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
LGTM On Tue, Mar 12, 2024 at 7:58 AM Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to the list by 31 March 2024. > > The GH repo for the I-D can be found at [2]. > > Thanks, > > Joe, Deirdre, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ > [2] https://github.com/tlswg/sslkeylogfile > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Astra mortemque praestare gradatim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell wrote: > > I'll argue just a little more then shut up... > > On 12/03/2024 22:55, Martin Thomson wrote: > > > >> Sorry also for a late suggestion, but how'd we feel about adding > >> some text like this to 1.1? > >> > >> "An implementation, esp. a server, emitting a log file such as this > >> in a production environment where the TLS clients are unaware that > >> logging is happening, could fall afoul of regulatory requirements > >> to protect client data using state-of-the-art mechanisms." > > > I agree with Ekr. That risk is not appreciably changed by the > > existence of a definition for a file format. > I totally do consider our documenting this format increases > the risk that production systems have such logging enabled, > despite our saying "MUST NOT." So if there's a way to further > disincentivise doing that, by even obliquely referring to > potential negative consequences of doing so, then I'd be for > doing that. Aside from this particular case, I don't think technical specifications should "obliquely" refer to things. Technical specifications should be clear. -Ekr Hence my suggestion. > > S. > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
I'll argue just a little more then shut up... On 12/03/2024 22:55, Martin Thomson wrote: Sorry also for a late suggestion, but how'd we feel about adding some text like this to 1.1? "An implementation, esp. a server, emitting a log file such as this in a production environment where the TLS clients are unaware that logging is happening, could fall afoul of regulatory requirements to protect client data using state-of-the-art mechanisms." I agree with Ekr. That risk is not appreciably changed by the existence of a definition for a file format. I totally do consider our documenting this format increases the risk that production systems have such logging enabled, despite our saying "MUST NOT." So if there's a way to further disincentivise doing that, by even obliquely referring to potential negative consequences of doing so, then I'd be for doing that. Hence my suggestion. S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
On Wed, Mar 13, 2024 at 09:55:10AM +1100, Martin Thomson wrote: > > > On Wed, Mar 13, 2024, at 08:39, Stephen Farrell wrote: > > > Another thought occurred to me that I don't recall being mentioned > > before: given we're defining a mime type, that suggests sending > > these files by mail or in an HTTP response. Doing that could > > be leaky, [...] > > I see equal opportunity for good things (detecting keylogfiles, deleting > them, generating a warning), than bad as a result of writing this down. See > also RFC 8959 (which the IETF did not publish, which I concede undermines my > position somewhat...) I see RFC 8959 as being in the IETF RFC stream (not ISE). -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
On Wed, Mar 13, 2024, at 08:39, Stephen Farrell wrote: > (Apologies to Martin for the grudging acceptance of > his worthy effort;-) No apology needed. Nose-holding is expected :) > Sorry also for a late suggestion, but how'd we feel about adding > some text like this to 1.1? > > "An implementation, esp. a server, emitting a log file such > as this in a production environment where the TLS clients are > unaware that logging is happening, could fall afoul of regulatory > requirements to protect client data using state-of-the-art > mechanisms." I agree with Ekr. That risk is not appreciably changed by the existence of a definition for a file format. And we do better keeping to the technical implications of choices. > Another thought occurred to me that I don't recall being mentioned > before: given we're defining a mime type, that suggests sending > these files by mail or in an HTTP response. Doing that could > be leaky, [...] I see equal opportunity for good things (detecting keylogfiles, deleting them, generating a warning), than bad as a result of writing this down. See also RFC 8959 (which the IETF did not publish, which I concede undermines my position somewhat...) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
On Tue, Mar 12, 2024 at 3:45 PM Stephen Farrell wrote: > > > On 12/03/2024 22:06, Eric Rescorla wrote: > > I don't think we should make statements about regulatory requirements > > in this kind of specification. That's not our lane. > > I'd weakly disagree about making statements such as suggested, > while agreeing with "not out lane." I don't think the text I > suggested crosses that line, but it's fine if others disagree > of course. > > I'd also be ok if we only stated that emitting these logs in > production systems means not deploying state of the art security > and letting the rest of the world connect the dots. > Lots of things don't constitute not deploying state of the art security, including, arguable, not using PQ algorithms. I think we should be very clear about the technical consequences of implementing this specification in the Security Considerations (which I think they are) but that either this statement or the one you previously proposed is not helpful. -Ekr > > Cheers, > S. > > PS: to be clear, I'm not objecting to progression if my > suggestion isn't adopted. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
On 12/03/2024 22:06, Eric Rescorla wrote: I don't think we should make statements about regulatory requirements in this kind of specification. That's not our lane. I'd weakly disagree about making statements such as suggested, while agreeing with "not out lane." I don't think the text I suggested crosses that line, but it's fine if others disagree of course. I'd also be ok if we only stated that emitting these logs in production systems means not deploying state of the art security and letting the rest of the world connect the dots. Cheers, S. PS: to be clear, I'm not objecting to progression if my suggestion isn't adopted. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
On Tue, Mar 12, 2024 at 2:40 PM Stephen Farrell wrote: > > Hiya, > > On 12/03/2024 14:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for > > TLS Internet-Draft [1]. Please indicate if you think the I-D is ready > > to progress to the IESG and send any comments to the list by 31 March > > 2024. > > This is not my fav thing, but I guess I've also benefited from > it during development, so with a bit of nose-holding, I suppose > it's ready. (Apologies to Martin for the grudging acceptance of > his worthy effort;-) > > Sorry also for a late suggestion, but how'd we feel about adding > some text like this to 1.1? > > "An implementation, esp. a server, emitting a log file such > as this in a production environment where the TLS clients are > unaware that logging is happening, could fall afoul of regulatory > requirements to protect client data using state-of-the-art > mechanisms." > I don't think we should make statements about regulatory requirements in this kind of specification. That's not our lane. -Ekr > Another thought occurred to me that I don't recall being mentioned > before: given we're defining a mime type, that suggests sending > these files by mail or in an HTTP response. Doing that could > be leaky, esp. if only one side of the TLS connection reflected in > the file were aware that logging was being done and if the other > side then sends the file via unencrypted email. I guess one > could also envisage a weird case where a server did this and > also located the log file inside the DocRoot enabling some > clients to see the secrets of some other clients (or their own). > I'm not sure if either scenario, or any similar scenario justifies > an additional warning to be careful where you send files using > that mime type? If it seems worth including, grand. If not, that's > ok. > > Cheers, > S. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Hiya, On 12/03/2024 14:57, Sean Turner wrote: This is the working group last call for the SSLKEYLOGFILE Format for TLS Internet-Draft [1]. Please indicate if you think the I-D is ready to progress to the IESG and send any comments to the list by 31 March 2024. This is not my fav thing, but I guess I've also benefited from it during development, so with a bit of nose-holding, I suppose it's ready. (Apologies to Martin for the grudging acceptance of his worthy effort;-) Sorry also for a late suggestion, but how'd we feel about adding some text like this to 1.1? "An implementation, esp. a server, emitting a log file such as this in a production environment where the TLS clients are unaware that logging is happening, could fall afoul of regulatory requirements to protect client data using state-of-the-art mechanisms." Another thought occurred to me that I don't recall being mentioned before: given we're defining a mime type, that suggests sending these files by mail or in an HTTP response. Doing that could be leaky, esp. if only one side of the TLS connection reflected in the file were aware that logging was being done and if the other side then sends the file via unencrypted email. I guess one could also envisage a weird case where a server did this and also located the log file inside the DocRoot enabling some clients to see the secrets of some other clients (or their own). I'm not sure if either scenario, or any similar scenario justifies an additional warning to be careful where you send files using that mime type? If it seems worth including, grand. If not, that's ok. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Ship it. From: TLS on behalf of Salz, Rich Date: Tuesday, 12 March 2024 at 16:00 To: Sean Turner , TLS List Subject: Re: [TLS] Working Group Last Call for SSLKEYLOG File > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to the list by 31 March 2024. No notes. Ship it. ___ TLS mailing list TLS@ietf.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7Cjohn.mattsson%40ericsson.com%7C4d888a8f3f29471ae23d08dc42a52bbd%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638458524368830039%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=sLCz0150gmqtACov7UYrMN07ya%2FzW89ZCvtFM9spdg4%3D=0<https://www.ietf.org/mailman/listinfo/tls> ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
> This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to the list by 31 March 2024. No notes. Ship it. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Working Group Last Call for SSLKEYLOG File
This is the working group last call for the SSLKEYLOGFILE Format for TLS Internet-Draft [1]. Please indicate if you think the I-D is ready to progress to the IESG and send any comments to the list by 31 March 2024. The GH repo for the I-D can be found at [2]. Thanks, Joe, Deirdre, and Sean [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ [2] https://github.com/tlswg/sslkeylogfile ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
