SCRAM Iteration Count Attack I'm not sure if this questions belongs here or in the Information Security Stack Exchange, but here goes...

With SCRAM (RFC5802), is there anything that prevents an attacker masquerading as the server from sending an iteration count of one?

If there's nothing preventing this, then it seems that such an attacker could get hold of a weakly hashed password and easily crack it:

Client              Server
------              ------
username,nonce  -&gt; 
                &lt;-  nonce,salt,iterations=1
ClientProof     -&gt;


then, offline,

AuthMessage     = client-first-message-bare + "," +
                  server-first-message + "," +
                  client-final-message-without-proof

foreach password in dictionary
    SaltedPassword  = Hi(Normalize(password), salt, i) // with i==1
    ClientKey       = HMAC(SaltedPassword, "Client Key")
    StoredKey       = H(ClientKey)
    ClientSignature = HMAC(StoredKey, AuthMessage)
    ClientProof     = ClientKey XOR ClientSignature
    check(ClientProof == StolenClientProof)


The problem I see with SCRAM is that the client has to trust the server with the iteration count before the the client can even authenticate the server.

I suppose the client could enforce a minimum iteration account to mitigate this attack, but this is not mentioned anywhere in the SCRAM spec.
You are correct.  This is mentioned somewhat obliquely at the beginning of §9 ‘Security considerations’:


  If the external security layer used to protect the SCRAM exchange
     uses an anonymous key exchange, then the SCRAM channel binding
     mechanism can be used to detect a man-in-the-middle attack on the
     security layer and cause the authentication to fail as a result.
     However, the man-in-the-middle attacker will have gained sufficient
     information to mount an offline dictionary or brute-force attack.


Thus, you should really avoid using SCRAM to authenticate the server to the client.  You might prefer to look into a password-authenticated key exchange like SRP or SPAKE2+ instead.