I'm trying to plan security routine for my new Linux install and few questions came up during searching for solution which meet my needs.
The TPM support is very rudimentary at this time. You'll need a bootloader that can extend the chain of trust and I only know of TrustedGRUB which is a pretty old version of GRUB with TPM-related functionalities added.
On the other hand, I believe the TPM is just all hype related to Bitlocker, practically it provides very little security (maybe that's by design to please the three-letter agencies?) as the machine now has all it needs to boot and decrypt its content without any other secret, allowing an attacker who stole the machine (even off) to boot it and then attack it with DMA or cold-boot attacks to retrieve the keys. TPM doesn't protect against that. Also, a theoretical attack I always think about is to simply sniff the low-speed serial bus the TPM is attached to and wait for it to transmit the encryption key. Only requires some wires to solder on the board, very easy and doesn't require expensive equipment.
An USB flash drive + keyfile/password would be way safer as the material needed to unlock the machine is now separate from it, if the computer is stolen off it's essentially an useless brick, there is absolutely nothing on the machine that holds the key.
Now, to answer your specific questions.
1) No, some unencrypted code has to be run before an encrypted partition can be decrypted and mounted, so the /boot, no matter where it is, should be unencrypted. The firmware (BIOS/UEFI) itself has no support for encrypted filesystems. Also, in case of disk encryption we're using symmetric crypto, so there is no notion of public key and all the TPM does is check if the data supplied to it (hashes of every component executed thus far and their configurations, so the firmware, its configuration, the bootloader, etc) and gives back a data block if the hashes match when the TPM was "sealed". This data block is the decryption key.
2) First, GRUB doesn't do encryption. The Linux kernel handles the crypto, which means everything before the kernel should be unencrypted. Finally there is no way to require both a password and keyfile with LUKS, but you can encrypt your keyfile with some program (GPG?) which you bundle into the (unencrypted) initrd and call it before passing the (decrypted) keyfile to LUKS to continue booting.
3) Sure. LUKS allows to transparently encrypt a block device by exposing its unencrypted version as a separate device node, so the system uses that instead of the real block device which now contains encrypted data. Whether it's an internal device, external, or some voodoo magic like an disk image file from an NFS server mounted as a loop device with LUKS on top, it'll work just as well (performance not guaranteed for the last one though). Whether you use keyfiles or passwords doesn't change anything either.
