Re: Authenticated cipher modes

["Sara Golemon" <ietf-secsh%libssh2.org@localhost>]

> >If the client notices that there's a common cipher
> >available that allows for data integrity, it can send a new KEXINIT
> >requesting just that cipher and a mac of 'none'.  The server could then
> >respond with it's own KEXINIT which agrees with that request, or perhaps
> >another response rejecting the renegotiation (a KEXINIT with empty
methods
> >would probably suffice for an explicit rejection).
>
> Is this actually necessary?  In the example above, the server could reject
> the overture by just sending the same KEXINIT it sent the first time.
>
Sending the same methods may (and most likely would) yield an agreeable set
of methods and allow the renegotiation to take place.  My intent with
sending blank methods is to allow the endpoint to say, "No, I don't support
renegotiation at all, even if it makes sense to do so."

> >If the server never
> >sends a KEXINIT in response then it can just be assumed by the client
that
> >renegotiation is not supported.
>
> All servers are already required to support it.
>
I'm sorry, where in the draft does it say that?  It mentions KEY re-exchange
(and recommends it be done regularly), but not methods.  Of course, method
renegotiation isn't explicitly prohibited either...

Given that method renegotiation is appearantly part of the spec, I'd be
inclined to ask: "So why not use it for this ciphers containing data
integrity issue?"  It seems like a much more straightforward approach than
adding per-cipher specific logic to the method selection criteria.

> My worry here is that this kind of renogotiation opens up the possibility
of
> the two ends getting into a loop, with one end thinking it can do better
> after each negotiation.
>
Excellent point.  Given that method renegotiation is already allowed, what
is the accepted policy for dealing with such a situation?  Left to
individual vendor implementation to 'be the bigger stack' and give up
eventually?

Taking another tack, how about a psuedo-mac?  e.g. none-ocb  Which is "none
MAC available only when coupled with an ocb cipher".  This could be placed
at the front of the methods list (avoiding any major changes to the
selection criteria), but its use would be dependant on the selected cipher.
This is similar to the coupling between kex method and hostkey method (If
kex requires an encryption capable hostkey method, then signing only methods
are ignored).

-Sara


-Sara