>>> Surely you jest. Why get so complicated when the much simpler >>> negotiation through alg names will do? What value is there in this >>> complication? >> - generality >> - allowing the feature to be negotiated for any algorithm, not just >> a particular gcm algorithm, without a cross product explosion > I'd rather have a magic alg name that does this. It's less code, a > lot less code. That's not the only metric that matters. > We don't need no stinking generality here :) given that we weren't > given it to begin with :) That's why we're trying to design a clean mechanism that provides it, rather than throwing in a kludge for this case, another kludge for next case, and pretty soon you're shoehorning protocol version numbers into the authentication username string or some such horror. > BTW, I would love to use the reserved field of KEXINIT to negotiate > retriable key exchagne (a big deal for gss keyex). Why? Why not just have the gss kex define its kex-method-specific messages so as to permit multiple back-and-forths, retrying as much as necessary to find something suitable? Actually, perhaps the best way to answer that would be to sketch the semantics for the retryable-kex bit you'd like to define; then I could probably see what the issue is (or suggest a way that doesn't break interoperability that badly, using existing facilities). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.