<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 11, 2020 at 11:49 PM William Allen Simpson <<a href="mailto:william.allen.simpson@gmail.com">william.allen.simpson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[Another heavy sigh]  As I've recounted before on this list, back when Netscape was<br>
located near the Stanford campus (I walked there from the computing center), Paul<br>
Mockapetris got me to visit.  I sat down with Taher Elgamal and others, to critique<br>
their early SSL.<br>
<br>
        Eventually, it became obvious that they weren't really open<br>
        to changes/suggestions.  To the best of my memory, we<br>
        thought it would be better to:<br>
<br>
         1) Authenticate the list of supported methods/transforms.<br>
        We did that in Photuris to avoid modification attacks<br>
        choosing the lowest common denominator.<br>
<br>
         2) Encrypt the certificates/users.  We called that "party<br>
        privacy protection".  We used the initial D-H exchange to<br>
        create a temporary stream key, and "masked" the data with<br>
        the stream (simply an MD5 hash).<br>
<br>
         3) Require Perfect Forward Secrecy.  We'd not managed to<br>
        get IPsec to do that.  It was a big argument at the time.<br>
<br>
         4) Authenticate outside of encryption, so we could quickly<br>
        and cheaply check before doing a more computationally<br>
        intensive decryption.  We managed to force that into IPsec,<br>
        and hoped to get Netscape to do the same for SSL (now TLS).<br>
        IIRC, that's since been proven to be more secure, but we<br>
        didn't know it at the time.  We were mostly interested in<br>
        practicality.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">At the time of SSL, 20MHz was still a common CPU speed. We were having real difficulty with the number of public key operations required to process cert chains. I am not surprised they were unwilling to do PFS then.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But when we did eventually do PFS, why did the design throw away the initial key agreement completely? Why not feed the PFS output and the RSA encrypted output into the KDF to form the session key? Then you can do 512 bit PFS without compromise to a 2048 bit RSA exchange.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We now know that $250 million a year was being spent on BULLRUN to sabotage standards work. I rather doubt that the individuals doing the sabotage were the obvious ones though. Much more likely it was those individuals whose means of financial support was always cloudy but were always ready to write a document, the people who made sure everyone with PKI knowledge was made unwelcome in DANE, the folk who persuaded the IAB to dig their heels in and prevent deployment of DNSSEC in 2001, etc. etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are a few individuals who seemed to be always there to pour poison in people's ears and to encourage them to 'stand their ground' when insisting on some asinine security requirement that makes the whole thing undeployable.</div><br></div><div><div class="gmail_default" style="font-size:small">Take the decision to make sure IPSEC wouldn't pass through NAT. I am certain neither security AD at the time was working for the NSA. But someone managed to reinforce their prejudices against NAT and the result was a failed design. </div><br></div><div> </div></div></div>