Re: [TLS] WG Adoption for TLS Trust Expressions
Hi Dennis, At 04:20 PM 29-04-2024, Dennis Jackson wrote: Thankfully these efforts have largely failed because these national CAs have no legitimate adoption or use cases. Very few website operators would voluntarily use certificates from a national root CA when it means shutting out the rest of the world (who obviously do not trust that root CA) and even getting adoption within the country is very difficult since adopting sites are broken for residents without the national root cert. There are ways to promote adoption of a government-mandated CA. The stumbling point is usually browser vendors, e.g. https://blog.mozilla.org/netpolicy/files/2021/05/Mozillas-Response-to-the-Mauritian-ICT-Authoritys-Consultation.pdf I see that you already mentioned BCP 188. Regards, S. Moonesamy ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS]Re: Adoption call for Extended Key Update for TLS 1.3
Hi Sean, At 09:39 AM 25-07-2024, Sean Turner wrote: At the IETF 120 TLS session there was interest in adopting the Extended Key Update for TLS 1.3 I-D (https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/). This message starts a two-week call for adoption. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this I-D, please send a message to the list and indicate why. There is an enthusiastic discussion on a well-established mailing list on what to do with STD 8. Meanwhile, the TLS working group is considering the adoption of a draft to document a debugging feature. Between you and I, it does not sound like a good idea to go down that path. Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Missing minutes for interim meeting (was: Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process))
Hi Deirdre, Joseph, Sean , At 06:30 PM 17-10-2024, Sean Turner wrote: Whoops - Corrected! spt > On Oct 17, 2024, at 17:14, Russ Housley wrote: > > The minutes have not been posted to that page yet. > > Russ > >> On Oct 17, 2024, at 2:24 PM, Sean Turner wrote: >> >> Hi! We had a quick (45min) interim to discuss the FATT Process. Slides & minutes for (and eventually a recording of) the session can be found here: >> https://datatracker.ietf.org/meeting/interim-2024-tls-02/session/tls There is a sub-heading with the following text rendered in bold: "Agenda, Minutes, and Bluesheets". There are three links under it. The first one takes me to https://datatracker.ietf.org/doc/agenda-interim-2024-tls-02-tls-01/ The second one takes me to https://www.ietf.org/proceedings/interim-2024-tls-02/bluesheets/bluesheets-interim-2024-tls-02-202410161800-00.txt and the third one takes me to https://datatracker.ietf.org/doc/bluesheets-interim-2024-tls-02-202410161800/ I could not find any minutes for the interim meeting [1]. Regards, S. Moonesamy 1. https://mailarchive.ietf.org/arch/msg/ietf-announce/Qzs2Sv72RRV5ETRLv5 K9F7OGxUQ/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
Hello, At 12:19 AM 21-12-2024, D. J. Bernstein wrote: Salz, Rich writes: > No, the IETF does not require controversies to be resolved. It > requires "rough consensus." I don't know what dividing line you're drawing here. Whatever terminology is used, WG action requires general agreement. This doesn't necessarily mean unanimity, but the WG is obliged to fairly consider each objection and to try to resolve each objection. If resolution fails and an objection ends up being overridden then there has to be documentation explaining why that objection was overridden. My source for these statements is authoritative and binding upon IETF, but naming the source here would be risky given threats by the WG chairs (currently under appeal), so I'm not naming the source in this message. I will, however, point to a non-authoritative source that's well worth reading on these topics, namely RFC 7282. For example, that RFC says the following: "What can't happen is that the chair bases their decision solely on hearing a large number of voices simply saying, 'The objection isn't valid.' That would simply be to take a vote. A valid justification needs to me made. ... Simply having a large majority of people agreeing to dismiss an objection is not enough to claim there is rough consensus; the group must have honestly considered the objection and evaluated that other issues weighed sufficiently against it." Eric Rescorla pointed out yesterday that the procedures under which a working group operates is described in RFC 2418. Those procedures have been in use since 1998. From what I understand of the discussions, the working group was asked whether there were any documents it wishes to work on. The person taking the decision (it's generally a working group Chair) would have to figure out whether the persons within the working group are sufficiently motivated to complete the work on one or more documents. The person may have other considerations as there might be some planning to be done. The person taking the decision is generally allowed some leeway. It may happen that there are different opinions on procedural/technical outcome(s). A course of action [1] would be to seek general agreement. RFC 7282 tried to outline how decisions are taken in general. That document also mentioned some pitfalls for the reader to think about. Regards, S. Moonesamy 1. It may happen that it is not an a viable alternative. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
Dear Professor Bernstein, At 08:13 PM 21-12-2024, D. J. Bernstein wrote: RFC 2418 does _not_ update RFC 2026, "The Internet Standards Process -- Revision 3". My question is about compliance with the standards process: "Can the WG chairs please clarify which procedure from RFC 2026 (or from RFCs updating RFC 2026) is being followed here?" My reading of the question (please see above) is that the appropriate person(s) to answer the question would be the working group chair(s). I assume that it's okay if I express an opinion on the question. The working groups in which I participated used the procedures which are described in BCP 25. If I am not mistaken, the TLS working group would also follow BCP 25 as there was community consensus on that document set. Furthermore, there is an expectation that people participating in the "Standards Process" were duly informed that BCP 25 is the set of documents used to describe the guidelines for a (IETF) working group. Here's an example of non-withdrawn email advocating standardization: https://mailarchive.ietf.org/arch/msg/tls/_D1BzH4T_7RFdduZECmEXj0blqg/ From what I understood, the persons on the thread were discussing what they would like to see, e.g. I would like to see X standardized. I don't have much of an opinion, currently, on what was being discussed/advocated/etc. Any action within IETF regarding standardization has to follow IETF's standardization procedures. The email at the top of this thread is certainly formal action (it's signed by "The Chairs"); I don't find the email very clear, but it _seems_ to be calling for votes on the idea of subsequently calling for votes on the idea of adopting a document to consider for standardization. I don't see how IETF's standardization procedures allow this. My quick response to the first sentence (please see text quoted above) would be Yes. The email at the top of this thread included some background information and a question at the end. I found the background information useful. The question at the end has something to do with adoption calls. In my opinion, the question were somewhat open-ended. I read the replies to the email to get a sense of whether people viewed the question as a request for votes. I don't have a strong opinion, in this context, about how the persons replied. I would agree with you on the point that calling for a vote is not a good idea. The reality is that content discussion such as https://mailarchive.ietf.org/arch/msg/tls/AWdRH_-V-GxaFNLLBeWB93HjlOc/ was disrupted by this strange chair action. Why didn't the chairs simply stay quiet regarding the signature and non-hybrid drafts, and wait to see whether discussion resolves those controversies? I would have to ask a Chair to know why he/she did not remain quiet. The Chair might ask me why I was asking the question, or he/she may ask me some other question. This is where it gets a bit complicated (for me). It's easier for me not to ask the question and do other stuff. My view of that content is that someone believes that A is the future, someone else believes that B is the future. It reminded me a FT podcast which was appeared around March 2023. Anyway, the point which you might be arguing for is that there are two schools of thought on the topic and it may be better to let the discussion follow its course. Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Q uantum Key Agreement for TLS 1.3
Hi Uri, At 10:23 AM 17-04-2025, Blumenthal, Uri - 0553 - MITLL wrote: You consider pure-PQ risks then don't usee it. I consider risks associated with hybrids, so my deployment will not use them. To each his own. According to a draft authored by Reddy and Tschofenig, "Pure PQC Key Exchange may be required for specific deployments with regulatory or compliance mandates". The authors then go on to list "high-security environments" as an example of where Pure PQC Key Exchange is required. An assessment of risks would be different in such environments. The web browser vendors decide which algorithm(s) to deploy at my location. That's usually how it works for everyday use. I doubt that the everyday user would be asking for compliance with the (U.S.) FIPS 203 standard (please see Section 1.1 of draft-connolly-tls-mlkem-key-agreement-05); It's unlikely that the user would have heard of "FIPS". It could be different in other parts of the world. Don't try to stuff your perception of risks and correctness into everybody else's throat. The above sentence seems a bit strong. Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agree ment for TLS 1.3
Hi Thomas, At 03:01 AM 17-04-2025, Bellebaum, Thomas wrote: I am counting 22 expressions in favor of adoption and 7 opposing adoption. This amounts to about every fourth person objecting the draft in its current state at this time, which seems more than can be explained by mere blocking of few individuals. First of all, I would like to thank you for sharing the count of those who expressed an opinion about the draft. I am not questioning that this is a sound majority, but consensus is a harsh word. Neither am I threatening to appeal, but I do share the view that merely declaring concerns such as "hybrids are way more conservative" as hypothetical/irrelevant to whether or not to publish this is not a reasonable way forward. The feeling (I am not saying "the fact") of this happening is valid. However, openly accusing others of playing games or ignoring procedures does not result in good specifications. It is quite tedious to attain genuine consensus. The alternative, well, one of them, would be to let the voters decide. This is where one could end up with a majority, a sound majority, etc. On reading your email I would not describe it as "consensus" even though you did not express the wish to appeal. I assume that having one or two persons blocking a decision is not an ideal means of moving forward. Ignoring one or two persons is not an ideal means of keeping a group cohesive. Someone has to figure out how to resolve that. It is very difficult to do it through email. I am a bit curious about whether the dispute is about the usage of the word "consensus" or something else. Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Additional uses for SSLKEYLOGFILE entries
Hi Ilari, At 12:18 AM 28-02-2025, Ilari Liusvaara wrote: What kind of private keys? Is that just the known trouble (TLS_RSA_*, TLS_PSK_* and the session ticket extension), or is it also other key types? Of those, only the pure-PSK stuff remains in TLS 1.3 (TLS 1.3 does have session tickets, but the mechanism is not a security disaster). Thank you for asking those questions. I don't have any information about the key types. Those three are especially suited for large-scale monitoring, because all destroy any forward secrecy, avoiding attacker having to steal keys on per-connection basis. Which is certainly highly convinient for attacker. I don't think putting non-ephemeral keys into SSLKEYLOGFILE would be even remotely reasonable. One of the advantages, in my opinion, of having an open discussion could be to figure out all that. Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Additional uses for SSLKEYLOGFILE entries
Hi Brian, Stephen, At 06:18 AM 27-02-2025, Stephen Farrell wrote: From my POV yes: fundamentally it is a bad idea for the IETF to standardise ways to exfiltrate keys even if there may be innocuous uses for those. And this latest ask (extending the exfiltration from being a TLS-only thing, to cover other protocols such as EDHOC) IMO nicely demonstrates the danger of the TLS WG publishing this document. According to Sheffer, Holz and Saint-Andre, "It is known that stolen (or otherwise obtained) private keys have been used as part of large-scale monitoring [RFC7258] of certain servers." Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS
Hi Thomas, Andrei, At 06:43 AM 21-02-2025, Andrei Popov wrote: I agree with Stephen and Tomas on this one. Additionally, in my opinion, this WG should not have published any SSLKEYLOGFILE documents, because they effectively standardize a backdoor. It is understood that there is a need for debugging, and it is understood that certain SW vendors want to agree on a common log data format and publish this format. However: - Debugging can (and should) be accomplished without a complete compromise of the security protocol (arguably, with less ease/convenience). - Backdoor specifications can be agreed upon outside the IETF process and published as part of the respective SW vendor's documentation, without involving the IETF. I agree with the comments which Thomas and you sent in regards to SSLKEYLOGFILE. I also agree with the authors on the point that debugging or analyzing protocols can be challenging when TLS is used. There was an extensive discussion about that during the discussion on the perpass and ietf mailing lists. It ended with the publication of RFC 7258. Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Reminder: Mail List Procedures
Dear TLS Working Group Chairs, I sent the email below on 1 March to the three email addresses which were listed in the datatracker. I did not receive a reply. I am resending the email. - email - Thank you for the reminder about the procedures. There is the following sentence in RFC 2418: "WG participants should specifically note the requirements for disclosure of conflicts of interest in [2].". The referenced document is RFC 2028. I could not find any requirements in RFC 2028 or the document which replaced it. Are there any requirements for disclosure of conflict of interests? Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Reminder: Mail List Procedures
Hi Rich, At 12:12 PM 04-04-2025, Salz, Rich wrote: I spoke with Scott Bradner. He said the error was there from the very first draft and it should probably be RFC 2026 which talks about disclosure. So you should probably assume that this has been overtaken by the Note Well. Thanks for the above. I'll forget the question which I sent to the TLS Working Group Chairs given the explanation in the first sentence. Regards, S. Moonesamy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
