[Cryptography] IPsec DH parameters, other flaws

[Thierry Moreau]

Thanks for this interecting historical perspective.

See below for a few comments.

On 02/07/20 05:27 PM, William Allen Simpson wrote:
> [reading some older list items, branching off]
>
> On 6/3/20 2:29 AM, Peter Gutmann wrote:
>> [1] I've never understood why IPsec and the cargo-cult protocols that
>> reused
>>      the parameters from it fixed on a single set of DH parameters.
>> IPsec is
>>      possibly one of the most unnecessarily flexible protocols in the
>> world
>>      where absolutely everything is up for negotiation, but there's
>> one single
>>      set of parameters that every single user has to share to create a
>> single
>>      point of failure for attackers to exploit.
>
> The original IPsec (Karn, Metzger, and Simpson) did not!
>
> Photuris was designed around negotiating variable DH parameters
> and avoiding easy denial of service attacks.  From the beginning!
>
> Karn also insisted the option field be limited to 8 bits, so there
> would never be many options.  We'd only assign a few combinations
> that were well vetted together.
>
> All of that went by the wayside after NSA (and BBN) got involved.
>
> Also, among other things, requiring the IV sent in the clear was
> another Steve Kent innovation.  Even though he'd been on a paper
> years earlier that the IV should be secret.
>
> And there was the Null encryption option.  And the ability to
> negotiate a downgrade.  And the serious problems we published via
> Usenix, because IETF wouldn't....

To me as an applied cryptography practitioner, the documentation of the 
NULL encryption option was a convenient (i.e. readily identified upon a 
first look at the document) that the whole thing was not aimed at 
end-to-end security for the benefit of users.

> We knew so many things to be wrong.  The best explanation is that
> flaws in the resulting IPsec were deliberate.

At layer 9, IPsec was envisioned as a mandatory requirement for IPng (to 
become IPv6) which would not fit the US (and allies) dedication to 
preserve "national security" network traffic interception capability. 
Thus a flawless IPsec was institutionally/constitutionally impossible.

>
> Thankfully, after a quarter century, TLS 1.3 has almost all the
> features we originally presented in 1995.

Your "almost all" qualification turns down my interest in the detailed 
TLS 1.3 design study. I do not see a rationale for giving up *any* of 
the security features present in the basic cryptographic protocol 
science available in the 1995-2005 period.

More specifically: Only from the current challenges of Internet presence 
for large organizations, I presume the TLS 1.3 design addresses the 
requirements for heavy server side loads (connection setups and overall 
encrypted data throughput), the ultimate end-to-end security being 
subordinated to server side efficiency.

Still without any definite rationale, I expect that some of the TLS 1.3 
options would meet the ultimate end-to-end security criteria, but the 
corresponding profiles would not be readily deployed by servers and thus 
perhaps not well supported by browsers. Am I right with this expectation?

- Thierry