Re: [TLS] simplistic renego protection

On Sun, Nov 22, 2009 at 1:15 PM, David-Sarah Hopwood <
david-sarah@jacaranda.org> wrote:

> Ben Laurie wrote:
> > On Sat, Nov 21, 2009 at 2:18 PM, David-Sarah Hopwood <
> > david-sarah@jacaranda.org> wrote:
> >
> >> Ben Laurie wrote:
> >>> On Fri, Nov 20, 2009 at 10:41 AM, David-Sarah Hopwood <
> >>> david-sarah@jacaranda.org> wrote:
> >>>
> >>>> Stefan Santesson wrote:
> >>>>> On 09-11-20 5:24 AM, "Michael D'Errico" <mike-list@pobox.com> wrote:
> >>>>>
> >>>>>> Some servers apparently cannot function without renegotiation.
> >>>>>> They will need to continue providing service to unpatched
> >>>>>> clients for some amount of time and thus remain vulnerable.
> >>>>> I fully agree,
> >>>>>
> >>>>> However, just because a server accepts renegotiation with an
> unpatched
> >>>>> client, does not necessarily mean that the service provided over TLS
> is
> >>>>> vulnerable.
> >>>>>
> >>>>> One example is if authentication is performed with proper channel
> >>>>> binding in a layer above TLS and the service is provided under that
> >>>>> security context.
> >>>>
> >>>> I'm skeptical. How can "proper channel binding" be done correctly in a
> >>>> layer above TLS, if the TLS library merges renegotiated sessions?
> >>>> Since the session merging will result in the client and server's state
> >>>> at the higher layer(s) being out of sync, nothing can be assumed about
> >>>> the correct functioning of those layers.
> >>>
> >>> The depends on those layers. If, for example, clients and servers
> simply
> >>> numbered their requests/responses, they would be immune to the attack.
> >>
> >> That's not sufficient. They'd also have to make sure that renegotiation
> >> boundaries coincide with request/response boundaries. That requires that
> >> the app be notified by the TLS library precisely when a renegotiation
> >> occurs, and that individual reads and writes cannot extend across a
> >> renegotiation boundary. This contradicts the assumption that I stated
> >> explicitly above: "if the TLS library merges renegotiated sessions".
> >> It's also rather prone to application error even in cases where it would
> >> theoretically work.
> >
> > I don't believe your argument. For example, if each byte were numbered,
> then
> > the application would not care one whit about boundaries (other than
> > reconnections, which it manages anyway).
>
> Numbering each byte is not what you suggested above. You haven't given
> enough detail to tell whether this could work, but if for the sake of
> argument it could, it would require incompatible changes to the application
> protocol. Therefore, it's not an argument that justifies the original
> point by Stefan Santesson above, about servers that accept renegotiations
> with unpatched clients not necessarily being vulnerable. In practice, such
> servers will be vulnerable for existing protocols.
>

I agree. I was disputing that this was not fixable at the application layer.

>
> --
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>