Re: [TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> Martin Rex wrote:
> > 
> > Requiring people to implement generic TLS extensions, something
> > that was completely undefined even for TLSv1.0 and is still optional
> > in TLSv1.2, 
> 
> Not that it matters, but his is incorrect. TLS 1.2 requires extension
> processing. See S 7.4.1 of RFC 5246:
> 
>    Servers MUST NOT send this extension.  TLS servers MUST support
>    receiving this extension.

You're refering to the signature algorithms extensions, which
clients MUST NOT send if they're offering to talk TLSv1.1?
OK, I wasn't aware of that.  Count the servers on the Internet
that support TLSv1.2 today with your left hand and substract
them for the rest of the servers out there.

Do you realize how much implementation and testing is involved when
shipping the fix as a TLS extension.

If someone with an old server, who doesn't implement renegotiation and
TLS extensions wants to add this patch, he will need to add the entire
TLS extensions handling in a generic fashion and require a significantly
larger interop testing scenario to make sure that it acutally works:

1.  client without Extensions
2.  client with 1 Extension   no RI

3.  client with 1 Extension   RI
4a. client with 2 Extensions  RI as first
4b. client with 2 Extensions  RI as 2nd
5a. client with 3 Extensions  RI as first
5b. client with 3 Extensions  RI as 2nd
5c. client with 3 Extensions  RI as 3rd

So that means that poor server maintainer will also have to build
a client with all that stuff in order to test whether the server
implementation is correct.


Compare this to the extension less approach:

1.  client without patch
2.  client with    patch

and all he needs to check is whether the signaling works.


> 
> > Think about the lines of code for a client:
> 
> I don't agree with your analysis of code complexity, but even if
> you were correct the implementation effort is in any case so
> minimal compared to the size of the deployment problem
> that it strikes me as largely irrelevant. Moreover, we already
> have implementations of RI, so the marginal implementation
> effort is even lower compared to doing something new.

You're going to waste network bandwith eternally in a completely
useless fashion.


So you want the IETF to rubber-stamp an obviously inferior approach
because you prefered to come up with a solution in secret?


-Martin