[ipxe-devel] Using a modern TLS library

[Demi M. Obenour]

On 7/1/19 3:39 PM, Christian Nilsson wrote:
> On Mon, 1 Jul 2019 at 21:24, Demi Obenour <demiobenour at gmail.com> wrote:
>>
>> Has there been any interest in using a modern TLS library, such as mbedTLS or BearSSL, to replace the internal crypto in iPXE?  I have zero trust in iPXE’s internal crypto and TLS/ASN.1 stacks.
>>
>> Demi
> 
> Awesome start on that email, really love the "zero trust" part.

There are three reasons that I do not trust iPXE’s crypto:

* It is vulnerable to timing attacks.  This does not affect verifying
  signatures or hashes, but does affect anything involving secrets.

* It does not support modern ciphersuites.  In particular, it does not
  support forward secrecy.

* To my knowledge, it has never been audited for security.

> 
> Now feel free to send patches, remember that the code should be
> compatible with the UBDL license:
> https://git.ipxe.org/ipxe.git/blob_plain/HEAD:/COPYING.UBDL

BearSSL is under the MIT license.  I am not sure about mbedTLS, though.

I am in no position to send patches right now, not least because I have
no ability to test them unless I can do so entirely in QEMU.

> 
> Now since iPXE runs in a limited environment, do measure the footprint
> it takes up,
> Most constraining environment is pcbios mode.
> And are still struggling with .rom builds that must fit in 64KiB flash chips.
> So make sure to test those scenarios properly.

One option would be to compress the code using a slow but efficient
compression algorithm.

> 
> There is both pros and cons of using external code,
> It's great if it has more features without being much larger than existing code.
> But I can imagine that it would cause an even larger headache in terms
> of having for example MS accept iPXE for EFI cross-signing.
> 

BearSSL is the best option in my opinion, despite being experimental.
Some of its features:

* Designed for bootstrap code from day 1
* Zero memory allocations.  This eliminates use-after-free and
  double-free vulnerabilities entirely.
* MIT license
* Non-blocking streaming API.
* All crypto is constant-time by default, at least on x86.
* Very small code size (<=25kB last I checked).
* C API.  All code is either written in C or compiled to C.
* Written by a well-regarded cryptographer.
* Extensively tested.
* Allows iPXE to remove its in-tree cryptography and X.509 code.
* Known-key mode, where the public key of the server is known in
  advance.  This is often the case in iPXE deployments, as the public
  key of the server can be provided by an iPXE script.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20190701/fbaf9319/attachment.sig>