[Cryptography] IPsec DH parameters, other flaws

[Paul Wouters]

On Tue, 21 Jul 2020, Phillip Hallam-Baker wrote:

>       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?

I cannot recall any issue or concern to "kick Ben Laurie out". Perhaps
more details would help, although not sure if that is still on topic for
this list.

> You assumed that the only purpose the PKI world would have was to 
> sabotage DANE.

I did not assume that. I _experienced_ a continued attempt to let WebPKI
overrule DNSSEC, thereby defeating the whole point of DNSSEC, which was
to build a trust hierarchy that does not depend on a Cab/forum Cabal and
500+ (yes we disagree on that) private keys able to sign anything
anywhere anytime.

>       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.

Well duh. Without DNSSEC, you would not be obsoleted the webpki Bag of
500+ all powerful keys.

> The other 
> was welding the policy aspect of 'must use TLS' to the publication of the keys.

Indeed, I argued for that. And I still think it would have been best to
do so, but it was actually dropped as compromise. It would have done an
excellent job at obsoleting port 80. There is no gain in publishing
security keys when it can be made optional by an attacker.

Combining your two points is even more fatal! Publish keys without
DNSSEC, and you basically have a TLA MITM machine that's every
dicatator's dream.

>       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.

Sure. People I guess realised it and came up with OPT-OUT for them.
Although for the life of me I cannot image why that isn't being moved
to Historic now and supported for it dropped. I just bought a 3rd hand
machine with 57GB of RAM and 32 CPU's for $150. There is no reason for
any real TLD to still use optout and reduce the security of the children
in their zone.

> And who was it persuaded you of the need to hit the red emergency button and
> kick out the PKI people?

You just said the "PKI people" wanted "optional DNSSEC" and "webpki
still in the picture". We gave the webpki their "must comply to webpki
processing rules" modifiers for TLSA. May they rest in Historic soon.

> Same guy who managed to persuade DPRIV to adopt
> an asinine set of requirements.

The whole encrypted DNS thing has been badly handled by the IETF. Very
early on, I pointed out that you could simply do this with IPsec limited
to port 53 selectors, with the public key in an IPSECKEY record. I
demoed it. But people wanted their DNS-native solution, which at least
got rejected. Adding TLS makes less sense than IPsec to me, but fine. It
works.

But for encrypted DNS, I wouls say the IETF was not the biggest issue.
With LetsEncrypt and browsers causing the majority of traffic to be TLS,
the only choke point for government censorship became DNS. And thus,
whatever happens with DNS will be ruled by the governments, and not the
standards bodies.

>       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...

With everyone on unique (public) IP, I don't think your argument holds.
But people see NAT as a strong defense, and you can't argue against
that. Additionally, it protected ISPs from having customers run servers.
And lastly, the breaking of true end-to-end reachability, ensured
everyone's lightswitch, TV, microwave, thermostat, car, and teaspoon
cannot work without a continued service by the vendor. Free $$$$$

Paul