Re: Authenticated cipher modes

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <012801c5444f$18d1b970$5c8be5a9%ohr.berkeley.edu@localhost> you write:
>> >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...

transport-24, section 9, second paragraph, fourth sentence:

                                                   It is permissible to
   change some or all of the algorithms during the re-exchange.

>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.

1: I'm scared of infinite loops.
2: It's expensive.  Diffie-Hellman takes quite a lot of CPU, and doing it
   several times is going to make session set-up quite a lot slower.

>Excellent point.  Given that method renegotiation is already allowed, what
>is the accepted policy for dealing with such a situation?

I think the accepted policy is not to trigger a re-key based on the results
of a previous key-exchange.  That way, you can never end up in a loop.

>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).

I don't think there's anything intrinsically wrong with that idea, but I
don't see that it has any advantage over having OCB just override the
selected MAC (which is equivalent to always having "none-ocb" at the start
of the MAC list).  Are there circumstances where one might want to use OCB
(or similar) with an external MAC?

-- 
Ben Harris