Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

[Steve Dispensa <[e-mail]>]

On 12/16/09 12:57 PM, "Steven Bellovin" <[e-mail]> wrote:

> 
> On Dec 15, 2009, at 10:11 AM, Steve Dispensa wrote:
> 
>> On 12/15/09 4:43 AM, "Ben Laurie" <[e-mail]> wrote:
>>> On Mon, Dec 14, 2009 at 7:19 PM, Russ Housley <[e-mail]> wrote:
>>>> Comment:
>>>> 
>>>>  As a protocol climbs the IETF standards-track maturity ladder, we
>>>>  sometimes drop features.  I would rather see renegotiation dropped
>>>>  from TLS than see this complexity added to TLS protocol.
>>> 
>>> That would break any website that does per-directory client
>>> certificates. Which may not be many, but its far more than zero.
>>> 
>> Also, it breaks support for varying crypto strength requirements (e.g., some
>> docs require DES/MD5, some require AES/SHA-1). I certainly wouldn't specify
>> a new system this way, but I'm sure there are existing systems that do this.
>> 
> I'm hard-put to justify a protocol feature for that scenario.  It's not just
> improbable, it's probably bad application design -- the performance
> differences in the different algorithms are just too small to justify it, and
> we don't have to support it just to deal with this niche case.  Ben's scenario
> is more compelling and bears further thought.

First off, I agree that Ben's scenario is more compelling; what I said is
significantly less important in my opinion.

That said, I wouldn't think only in terms of "application design." There are
other use cases that are considerably more complex from a network
infrastructure standpoint that do bear consideration. Think about
intercepting load balancers (with a variety of different servers behind
them), or about shared hosting accounts (e.g. .htaccess files in public_html
directories), or about servers that are hosting different off-the-shelf "web
applications" that check the configuration checkboxes differently, and so
on. I think this is one of those cases where real-world deployments are
messier than we'd like.

And, as Marsh has said on other threads, to remove a widely used feature is
tantamount to forking the protocol.

 -Steve