We've posted a followup blog post: Certificate Transparency’s improved gossip protocols show promise
https://blog.okturtles.com/2015/03/certificate-transparencys-improved-gossip-protocols-show-promise/ I also updated our previous blog post to make a note of this new information. Great work folks. đź‘Ť Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Mar 27, 2015, at 4:56 PM, Tao Effect <[email protected]> wrote: > Dear Paul, > > This is fantastic news. Great work list! > > I am working on a new blog post on this topic to post to the okTurtles blog > and am getting ready to publish it. > > If you (or anyone else on this list) would like to proof read a draft of it > before it's published (sometime today, or tomorrow at the latest), please > contact me off-list at this email. > >> Yes, but I'm sure the authors would love to received improved text for this >> section of the document. > > I'll see if I can come up with something. :) > > Cheers, > Greg > > -- > Please do not email me anything that you are not comfortable also sharing > with the NSA. > > On Mar 27, 2015, at 3:36 PM, [email protected] wrote: > >> On Fri, 27 Mar 2015, Tao Effect wrote: >> >>> To illustrate: >>> A = server's real certificate >>> B = malicious MITM certificate >>> T1. Client receives A. >>> T2. Client receives B, sends back A. >>> T3. MITM pretends to leave, sends A. Client sends B. >> >> T3 cannot happen. The draft states: >> >> SCTs and corresponding certificates are POSTed to the originating >> HTTPS server at the well-known URL: >> >> https://<domain>/.well-known/ct/v1/sct-feedback >> >> This means you must have a valid TLS connection to send the data. As >> long as the attacker does not have the private key of the attacked >> web server, this cannot happen. >> >>> So, my question is: does your document properly take that into account and >>> state that the data sent in 3.1.3 *must* be sent after a >>> fully encrypted TLS connection has been established? >> >> Yes, but I'm sure the authors would love to received improved text for >> this section of the document. >> >>> P.S. FYI Paul, any time I CC your email I get a bounced "Undelivered Mail" >>> response: >>> >>> Final-Recipient: rfc822; [email protected] >>> Original-Recipient: rfc822;[email protected] >>> Action: failed >>> Status: 5.1.1 >>> Remote-MTA: dns; 193.110.157.102 >>> Diagnostic-Code: smtp; 550 5.1.1 <[email protected]>: Recipient address >>> rejected: User unknown in local recipient table >> >> Sorry about that. I added an alias to fix it. (my home DSL is down so >> mail is rerouted temporarily, and I'm far from home) >> >> Paul >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
