Analogously, if we specify a keyexchange algorithm with integrated server authentication (say, using SRP or something like that for the key exchange), we can say that the hostkey algorithm is moot and ignored.
Actually, we very nearly do this; see RFC4462. What saves us with keyex and host key algorithms is that the base spec defines several properties of host key algorithms (can sign, can encrypt), and keyex methods specify which ones they depend on; the host key algorithm chosen is the first one that meets the requirements of the selected keyex algorithm. This lets RFC4462 specify that the GSS keyex methods depend on neither signing nor encrypting. Since the null host key algorithm (also defined in RFC4462) provides neither of those capabilities, we can list it (last). This means we can negotiate (DH,RSA) or (GSS-KRB5,NULL) without having to worry about getting (DH,NULL). However it also means we will get (GSS-KRB5,RSA) if both sides advertise both GSS-KRB5 and RSA. That's actually desirable for the GSS keyex families.
We could do something analogous for encryption and host key algorithms, but I don't think it would get you what you want; in particular, it leads to negotiating a superfluous MAC.
What I'd suggest instead is defining a unique MAC alogrithm for each AEAD encryption algorithm, which has the same effects as null but is usable _only_ when the corresponding encryption algorithm is selected. This is a simple and straightforward modification to the negotiation rules which allows the new MAC algorithms to be listed _first_ to ensure you don't do extra MAC's when an AEAD encryption algorithm is selected, but without adversely affecting the MAC negotiation when an AEAD encryption algorithm is _not_ selected -- even when one of the peers is not AEAD aware.
I also find it brittle to renegotiate with a subset of the previous algorithms, in particular when you exclude one of the *selected* algorithms. Imagine that both sides attempt renegotiation, and that they do it slightly differently. Then the connection may fall apart. And if you want to avoid such problems by specifying in more detail what the policy behind the renegotiation should be, then I'd much prefer to specify *explicitly* what it is you want to achieve, e.g., that no mac should be used together with AEAD, and then implement that policy at both ends with no extra negotiation.
Agree. -- Jeff