[Cryptography] IPsec DH parameters, other flaws

[Phillip Hallam-Baker]

On Sat, Jul 11, 2020 at 11:49 PM William Allen Simpson <
william.allen.simpson at gmail.com> wrote:

> [Another heavy sigh]  As I've recounted before on this list, back when
> Netscape was
> located near the Stanford campus (I walked there from the computing
> center), Paul
> Mockapetris got me to visit.  I sat down with Taher Elgamal and others, to
> critique
> their early SSL.
>
>         Eventually, it became obvious that they weren't really open
>         to changes/suggestions.  To the best of my memory, we
>         thought it would be better to:
>
>          1) Authenticate the list of supported methods/transforms.
>         We did that in Photuris to avoid modification attacks
>         choosing the lowest common denominator.
>
>          2) Encrypt the certificates/users.  We called that "party
>         privacy protection".  We used the initial D-H exchange to
>         create a temporary stream key, and "masked" the data with
>         the stream (simply an MD5 hash).
>
>          3) Require Perfect Forward Secrecy.  We'd not managed to
>         get IPsec to do that.  It was a big argument at the time.
>
>          4) Authenticate outside of encryption, so we could quickly
>         and cheaply check before doing a more computationally
>         intensive decryption.  We managed to force that into IPsec,
>         and hoped to get Netscape to do the same for SSL (now TLS).
>         IIRC, that's since been proven to be more secure, but we
>         didn't know it at the time.  We were mostly interested in
>         practicality.
>

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200719/b8900ec7/attachment.htm>