Re: draft-ietf-secsh-agent-02.txt

[Damien Miller <djm%mindrot.org@localhost>]

Sorry for not looking at this sooner. Some comments:

1. Why not make the SSH_AGENT_CONSTRAINT_* constraints strings? They are
not performance critical, and this will allow us to use the same
extension@vendor.domain mechanism used elsewhere in the protocol.

2. We should also have some text describing what should happen when an
agent is asked to process an unrecognised extension. I.e should
constraint extensions be "critical"? (I think so)

3. I also have concerns about how "forwarding steps" and "forwarding
path" extensions could be safely implemented beyond one hop. I don't
know of any implementation that does this, so I'd be wary of the
specification anticipating reality.

4. I don't see any value in the SSH_AGENT_RANDOM exchange. If a remote
agent doesn't have a good local randomness source, then it shouldn't be
talking ssh. Trusting random numbers from a remote source could lead to
things like DSA private key exposure.

Furthermore, the ability for a remote attacker to perform arbitrary
requests on your randomness source would increase your exposure to any
implementation vulnerabilities at your end.

5. I'd prefer to see section "4.  Agent Forwarding With Secure Shell"
moved to near the start of the document, but that is just my taste. OTOH
I don't think that it should break the vendor extension section from the
rest of the agent protocol description.

-d