[Cryptography] IPsec DH parameters, other flaws

[Phillip Hallam-Baker]

On Mon, Jul 20, 2020 at 3:23 PM Paul Wouters <paul at cypherpunks.ca> wrote:

> On Sun, 19 Jul 2020, Phillip Hallam-Baker wrote:
>
> > the people who made sure everyone with PKI knowledge was made unwelcome
> in DANE
>
> Phillip,
>
> The whole point of DNSSEC was to skip the PKI middle-men. When DANE was
> looking to get serious, the WebPKI people litterally invaded the small
> room we had looking for the red emergency shutdown button. It is not
> that DANE needed X.509/webPKI expertise.


The DANE group needed Google's support to get in the Browser so why
make such a deliberate effort to kick Ben Laurie out of the effort?

You assumed that the only purpose the PKI world would have was to
sabotage DANE. What we were in fact looking to do was to upsell our
existing certificate customers with managed DNSSEC.


The only part of x.509 was
> that webservers had to keep serving keys in x.509 containers, and all
> the tools handled x.509 containers and not raw public keys. So the
> DANE record just needed to say "just pull the public key, and drop the
> rest".
>
> What happend was actually exactly what people who wouldn't want everyone
> to have universal cryptography got, another delay of DANE and some
> proposal more complicated than needed with the messy PKIX-EE/PKIX-CA
> versys DANE-EE/DANE-PKIX. I had to fight Richard Barnes of BBN to
> keep a DANE type that did not (need to) trust a CA, a battle that I
> had to figh tall over again with him when doing tls-dnssec-chains,
> which got at least 3 years delay because they blocked it in the TLS WG.
>

There were multiple issues. One of them was the insistence on DNSSEC. The
other
was welding the policy aspect of 'must use TLS' to the publication of the
keys.
Yet another problem was the restriction to TLS policy



> I'd say the reverse of what you claim, actually happened.
>
> > , the folk who persuaded the IAB to dig their heels in and prevent
> deployment
> > of DNSSEC in 2001, etc. etc.
>
> I was not participating at IETF during this time, so I don't know, but I
> do know I was the first Dutch ISP to run DNSSEC in production with 150
> domains in the .nl.nl shadow tree, and the rollover issues were just
> unsolved at that time. So I can see technical reasons why it was not
> ready. I have no opinion or knowledge about the IAB motivation or
> actions at that time though.
>

VeriSign's ATLAS infrastructure was originally built to deploy DNSSEC. But
the
lack of opt-in on the NXT record made it impossible to deploy using the
technology
of the day. 64 bit machines were only just becoming available and the NXT
record
more than quadrupled the size of the .COM zone.

> 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.
>
> I'm pretty sure both you and I both feel that the two of us have  zero
> chance of secretly working for goverments to prevent cryptographic
> deployments to the masses.
>

I think it highly unlikely as well. Not least because the NSA got a severe
wake up
call in the wake of the Manning and Snowden breaches. They failed in their
mission
to protect US secrets.

Yet, the fact that we see the above in complete different ways, suggest
> perhaps that instead of crediting NSA and GCHQ for the sabotaging our
> communities, that our biggest enemy is in fact us, and not them.
>

And who was it persuaded you of the need to hit the red emergency button and
kick out the PKI people? Same guy who managed to persuade DPRIV to adopt
an asinine set of requirements.




> > 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.
>
> Again, I wasn't there for that, but the IETF really believed IPv6 would
> be there soon and NAT would die and don't develop for it. I would again
> not give credit to TLA's for the simple incomptence of the IETF[1] :)
>

They failed to understand that if you have two networks with different
addressing
schemes, any interoperability capability must inevitably involve
translation of
addresses...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200721/a2494e02/attachment.htm>