Re: [TLS] NIST on addressing visibility challenges with TLS 1.3
Hi folks, This line of discussion is not appropriate for this mailing list. Please take it elsewhere. Best, Chris, for the chairs On Thu, Sep 30, 2021, at 6:54 AM, Tony Rutkowski wrote: > Ruslan, > > Speaking as as a lawyer has participated in many EU proceedings over > several decades, your assertion here is not accurate. A European > Council Resolution is by definition a "legal document." It was adopted > on 14 Dec 2020 after an extensive policy making proceeding and > consultations among EU Members over more than a year, and the subject > of > a vote by a EU governing body. See > https://www.consilium.europa.eu/en/press/press-releases/2020/12/14/encryption-council-adopts-resolution-on-security-through-encryption-and-security-despite-encryption/# > > As the Council's site notes, its Resolutions "set up political > commitments or positions." See > https://www.consilium.europa.eu/en/council-eu/conclusions-resolutions/ > > The point here was that the NCCoE activity - as many similar ones in > other technical bodies - is fully consonant with adopted European policy > (paid for by EU Member taxpayers). It is also properly the subject of > notice by the IETF. What seem inappropriate is characterising > alternative views on these matters as "not fine," or "I'm glad I'm not a > tax payer in a jurisdiction that's encouraging people to weaken the > security properties this WG has tried hard to improve" or denigrating > the integrity of a government agency because they don't agree with your > views. > > It is also worthy of note that shutting down discussion on the IETF TLS > list seems highly dependent on the views being articulated. > > --tony > > On 30-Sep-21 2:30 AM, Ruslan N. Marchenko wrote: >> First of all EC Resolution is not a legal document, it's a legal >> initiative. The resolution is a "call for action" but not an action >> per se - there's no legal consequence other than it is possible to >> bring this initiative now to european parliament. > > ___ > 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] NIST on addressing visibility challenges with TLS 1.3
(I've no problem if the chairs want to shut this down as we have gone over this ground a number of times - OTOH it is I think important to not let such things pass by as if they were fine, since they are not fine.) Ruslan is correct wrt the EU stuff IMO. Other than that, I don't consider it inappropriate to criticise organisations that act as NIST are doing here. Claims that that's tonally dodgy are IMO off the mark. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST on addressing visibility challenges with TLS 1.3
Hi all, Just wondering why anyone thinks this armchair lawyering is appropriate to send to this list (not that I disagree with Ruslan here). Perhaps someone could, I don’t know, act as a chair. ymmv thanks, Rob On Wed, Sep 29, 2021 at 11:31 PM Ruslan N. Marchenko wrote: > Hi Tony, > > First of all EC Resolution is not a legal document, it's a legal > initiative. The resolution is a "call for action" but not an action per se > - there's no legal consequence other than it is possible to bring this > initiative now to european parliament. > Second - any member of any security body, be them management or common > member, should raise similar concerns as Stephen as to why on earth I > should support [unvoluntary, with my taxes] the initiative to degrade the > level of my confidentiality . > > The resolution raised the similar discusision in non-security groups - > such as this > https://www.europarl.europa.eu/doceo/document/P-9-2020-006076_EN.html - > and I would expect IETF to raise such questions in the first place before > even starting technical discussion on the subject - which is raised by > Stephen. > > Although I agree the tone might be tuned to be more inviting for > discussion I personally do no see anything to discuss, such requirement > [visibility to third party] simply cannot be made part of the protocol > which claims to provide confidentiality. It must be separate protocol then > which does not put such claim. > > > Regards, > Ruslan > > Am Mittwoch, dem 29.09.2021 um 18:21 -0400 schrieb Tony Rutkowski: > > Hiya, > > Assuming you live in the EU, your assertion is not accurate. In November > of last year, the European Council adopted a EU wide Resolution on > Encryption. See at > https://data.consilium.europa.eu/doc/document/ST-13084-2020-REV-1/en/pdf > Clause 6 establishes a regulatory framework, and clause 7 calls for the > same kind of development activity being undertaken by the NCCoE - which is > ensuing in multiple venues, including ETSI. > > Worth notice are the use cases discussed at the related workshop last > September in which IETF representatives participated. See > https://www.nccoe.nist.gov/events/virtual-workshop-challenges-compliance-operations-and-security-tls-13 > . > > Perhaps there is another jurisdiction somewhere in the world that might be > absolute in their commitment to extreme IETF TLS 1.3 implementations, > although its existence is not clear. Historically, in the late 80s and > early 90s, the IETF was more helpful in implementing the early TLS > protocols eventually adopted by ISO/CCITT without extreme rhetoric. See at > https://www.nist.gov/publications/secure-data-network-system-sdns-network-transport-and-message-security-protocols > > Inquiring minds might also ask if such a posting to this list is > appropriate for anyone involved in IETF management. > > best, > tony > > > On 28-Sep-21 5:32 PM, Stephen Farrell wrote: > > > Hiya, > > On 28/09/2021 17:53, Salz, Rich wrote: > > This will be of interest to some on this list. Quoting: “The NCCoE > at NIST recognizes the challenges associated with compliance, > operations, and security when enterprises employ encrypted protocols, > in particular Transport Layer Security (TLS) 1.3, in their data > centers. This project will use commercially available technologies to > demonstrate a range of approaches for enabling necessary > intra-enterprise access to unencrypted/decrypted information. > > > I'm glad I'm not a tax payer in a jurisdiction that's > encouraging people to weaken the security properties this > WG has tried hard to improve. I wonder do other parts of > NIST sponsor work like that - it'd be a bit like [1] > producing specs on how to get your thumb on the scales;-) > > From my perspective this kind of thing also makes it harder > to figure out what overall evaluation to associate with the > agency that produced AES, dual-ec, this stuff, and presumably > some PQ alg "winners" in the near future. Quite the mixed > bag that. > > Cheers, > S. > > [1] https://www.nist.gov/pml/weights-and-measures > > > > > More at > > https://www.nccoe.nist.gov/projects/building-blocks/applied-cryptography/addressing-visibility-challenges-tls-13 > including how to participate. > > > ___ 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST on addressing visibility challenges with TLS 1.3
Hiya, Assuming you live in the EU, your assertion is not accurate. In November of last year, the European Council adopted a EU wide Resolution on Encryption. See at https://data.consilium.europa.eu/doc/document/ST-13084-2020-REV-1/en/pdf Clause 6 establishes a regulatory framework, and clause 7 calls for the same kind of development activity being undertaken by the NCCoE - which is ensuing in multiple venues, including ETSI. Worth notice are the use cases discussed at the related workshop last September in which IETF representatives participated. See https://www.nccoe.nist.gov/events/virtual-workshop-challenges-compliance-operations-and-security-tls-13. Perhaps there is another jurisdiction somewhere in the world that might be absolute in their commitment to extreme IETF TLS 1.3 implementations, although its existence is not clear. Historically, in the late 80s and early 90s, the IETF was more helpful in implementing the early TLS protocols eventually adopted by ISO/CCITT without extreme rhetoric. See at https://www.nist.gov/publications/secure-data-network-system-sdns-network-transport-and-message-security-protocols Inquiring minds might also ask if such a posting to this list is appropriate for anyone involved in IETF management. best, tony On 28-Sep-21 5:32 PM, Stephen Farrell wrote: Hiya, On 28/09/2021 17:53, Salz, Rich wrote: This will be of interest to some on this list. Quoting: “The NCCoE at NIST recognizes the challenges associated with compliance, operations, and security when enterprises employ encrypted protocols, in particular Transport Layer Security (TLS) 1.3, in their data centers. This project will use commercially available technologies to demonstrate a range of approaches for enabling necessary intra-enterprise access to unencrypted/decrypted information. I'm glad I'm not a tax payer in a jurisdiction that's encouraging people to weaken the security properties this WG has tried hard to improve. I wonder do other parts of NIST sponsor work like that - it'd be a bit like [1] producing specs on how to get your thumb on the scales;-) From my perspective this kind of thing also makes it harder to figure out what overall evaluation to associate with the agency that produced AES, dual-ec, this stuff, and presumably some PQ alg "winners" in the near future. Quite the mixed bag that. Cheers, S. [1] https://www.nist.gov/pml/weights-and-measures More at https://www.nccoe.nist.gov/projects/building-blocks/applied-cryptography/addressing-visibility-challenges-tls-13 including how to participate. ___ 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] NIST on addressing visibility challenges with TLS 1.3
On Tue, Sep 28, 2021 at 2:32 PM Stephen Farrell wrote: > On 28/09/2021 17:53, Salz, Rich wrote: > > This will be of interest to some on this list. > I mean, maybe, but what's the list policy on this stuff? It just looks like conference spam to me. I'd guess the government folks on the list would already know about this NIST effort. > I'm glad I'm not a tax payer in a jurisdiction that's > encouraging people to weaken the security properties this > WG has tried hard to improve. > Unfortunately, I am such a taxpayer. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST on addressing visibility challenges with TLS 1.3
Hiya, On 28/09/2021 17:53, Salz, Rich wrote: This will be of interest to some on this list. Quoting: “The NCCoE at NIST recognizes the challenges associated with compliance, operations, and security when enterprises employ encrypted protocols, in particular Transport Layer Security (TLS) 1.3, in their data centers. This project will use commercially available technologies to demonstrate a range of approaches for enabling necessary intra-enterprise access to unencrypted/decrypted information. I'm glad I'm not a tax payer in a jurisdiction that's encouraging people to weaken the security properties this WG has tried hard to improve. I wonder do other parts of NIST sponsor work like that - it'd be a bit like [1] producing specs on how to get your thumb on the scales;-) From my perspective this kind of thing also makes it harder to figure out what overall evaluation to associate with the agency that produced AES, dual-ec, this stuff, and presumably some PQ alg "winners" in the near future. Quite the mixed bag that. Cheers, S. [1] https://www.nist.gov/pml/weights-and-measures More at https://www.nccoe.nist.gov/projects/building-blocks/applied-cryptography/addressing-visibility-challenges-tls-13 including how to participate. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST on addressing visibility challenges with TLS 1.3
On Tue, Sep 28, 2021, 12:54 PM Salz, Rich wrote: > This will be of interest to some on this list. Quoting: “The NCCoE at > NIST recognizes the challenges associated with compliance, operations, and > security when enterprises employ encrypted protocols, in particular > Transport Layer Security (TLS) 1.3, in their data centers. This project > will use commercially available technologies to demonstrate a range of > approaches for enabling necessary intra-enterprise access to > unencrypted/decrypted information. “ > > > > > > More at > https://www.nccoe.nist.gov/projects/building-blocks/applied-cryptography/addressing-visibility-challenges-tls-13 > including how to participate. > ___ > 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] NIST on addressing visibility challenges with TLS 1.3
This will be of interest to some on this list. Quoting: “The NCCoE at NIST recognizes the challenges associated with compliance, operations, and security when enterprises employ encrypted protocols, in particular Transport Layer Security (TLS) 1.3, in their data centers. This project will use commercially available technologies to demonstrate a range of approaches for enabling necessary intra-enterprise access to unencrypted/decrypted information. “ More at https://www.nccoe.nist.gov/projects/building-blocks/applied-cryptography/addressing-visibility-challenges-tls-13 including how to participate. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
