Re: [TLS] [EXTERNAL] Re: SSL cert - CA issuer question - WIndows Event Reporting CA
@M K Saravanan: if you export (w/o private key) and share the cert with me, I can take a look. Windows does not MITM TLS connections. Cheers, Andrei -Original Message- From: TLS On Behalf Of Martin Thomson Sent: Wednesday, June 7, 2023 2:17 PM To: tls@ietf.org Subject: [EXTERNAL] Re: [TLS] SSL cert - CA issuer question - WIndows Event Reporting CA On Wed, May 10, 2023, at 10:36, M K Saravanan wrote: > When I first access that website, for e.g. https://www.cloudflare.com/ > the issuer CA is shown as "Windows Event Reporting CA". What you have there is known as interception. Something on your machine (Windows Event Reporting maybe) has installed a CA and is intercepting connections. Some people call this bad, or a MitM attack. ___ 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] SSL cert - CA issuer question - WIndows Event Reporting CA
On Wed, May 10, 2023, at 10:36, M K Saravanan wrote: > When I first access that website, for e.g. https://www.cloudflare.com > the issuer CA is shown as “Windows Event Reporting CA”. What you have there is known as interception. Something on your machine (Windows Event Reporting maybe) has installed a CA and is intercepting connections. Some people call this bad, or a MitM attack. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: NomCom 2023 Call for Volunteers
TLS participants: Please strongly consider volunteering for this years NOMCOM. It’s is not that much time and it is very important to the IETF to have good people on the NOMCOM. And as you see below, you will get to spend some more time with Martin. Cheers, spt > Begin forwarded message: > > From: NomCom Chair 2023 > Subject: NomCom 2023 Call for Volunteers > Date: June 5, 2023 at 19:50:08 EDT > To: "IETF Announcement List" > Reply-To: nomcom-chair-2...@ietf.org > > The IETF Nominating Committee (NomCom) appoints people to fill the open slots > on the IETF LLC, IETF Trust, the IAB, and the IESG. Ten voting members for > the NomCom are selected from a pool of volunteers. A large pool of > volunteers helps make the process work better. > > CLICK HERE TO VOLUNTEER: https://datatracker.ietf.org/nomcom/volunteer > > NomCom activity is expected to start in July and run through to November. > The goal is to do the bulk of the work at IETF 117 and 118, with supplemental > conference calls between those times. Remote participation will be supported. > > The NomCom activities involve collecting requirements from the community, > reviewing candidate responses, reviewing feedback from community members > about candidates, interviewing candidates, and nominating a slate of > candidates. > > RFC 8713 details the NomCom process. With the recent publication of RFC > 9389, this is the first year of new qualification criteria, after a few years > of trials. People qualify for NomCom participation in one of three ways: > attendance at IETF meetings (online or virtual), service as a working group > chair or secretary, or publication of IETF RFCs. > > https://datatracker.ietf.org/accounts/profile/ lists your eligibility, but > you can still volunteer even if that says "No". You can also volunteer by > sending me an email. > > Within the next week or two, I will add more details on the timeline and the > selection process. > > Thank you! > Martin Thomson > nomcom-chair-2...@ietf.org > > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
> > I mean, is there a cryptographic reason for it? No. > (However, absent cryptographic reasons, this all is way premature.) > Indeed. We like to have a concrete proposal, but thinking through these details is premature at this point. [snip] What that in effect does > is to make it much more difficult to exploit chosen-prefix collisions in > hash function. However, that requirement holds irrespective of the hash function used, and it has in fact been held for SHA-256 (regardless of there not being > any known even remotely feasible attacks) instead of just being a dead > letter from the past with much worse hash functions. > Ah, it would indeed be neat if we could design this, so that we do not require (chosen prefix) collision resistance of the hash. I'd say it's nice to have, but not a must. Tracking in https://github.com/davidben/merkle-tree-certs/issues/45 Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Editorial Errata Reported] RFC5054 (7538)
The following errata report has been submitted for RFC5054, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7538 -- Type: Editorial Reported by: Mingye Wang Section: 2.1 Original Text - The version of SRP used here is sometimes referred to as "SRP-6" [SRP-6]. Corrected Text -- The version of SRP used here is sometimes referred to as "SRP-6a" [SRP-6a]. [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005, http://srp.stanford.edu/design.html Notes - The protocol described uses a non-constant k, which is an innovation of SRP-6a -- never published formally in a technical report (until this RFC) and dating to ~2005 if we go by the libsrp version history. Actual [SRP-6] of 2002 uses a constant k = 3. Reference to the [SRP-6] text is still valuable for rationale, but is not accurate. Confusion between these two versions is harmful and may impeded interoperability. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC5054 (draft-ietf-tls-srp-14) -- Title : Using the Secure Remote Password (SRP) Protocol for TLS Authentication Publication Date: November 2007 Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin Category: INFORMATIONAL Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
