Re: [TLS] Third Option?

Just to clarify my own position on this.

I believe we should fix this issue and I would personally favor the mrex
draft approach as it provides better security properties, is cleaner and
more generic.

However, if the consensus for some reason would be to NOT provide a fix,
then I think it would be better to just clarify the security properties of
current renegotiation rather than attempting to ban it.

/Stefan

On 09-12-17 5:01 PM, "Martin Rex" <mrex@sap.com> wrote:

> Yoav Nir wrote:
>> 
>> What do you (as a vendor) tell your customers when they know they are
>> vulnerable and call you for a fix?
>> 
>> Have TLS 1.3 code ready and tell them to upgrade to it.  Asking customers
>> to move to newer release in order to fix security problems is something
>> the market understands. (did not say 'likes').
> 
> I haven't seen a market that understand this.
> Vendors have been shipping very annoying auto-update functionality
> in order to get at least a part of the installed base to upgrade.
> 
> Outside of the commodity market, you may get to see some customer's
> lawyers if you suggest "moving to a newer release" instead of providing
> a patch to defects in your products.
> 
> 
>> - There's no signaling that renegotiations are disabled.
>>   The browser cannot show me that I'm talking to a secured server.
> 
> Yes, I feel so much safer when I know that I'm talking to an TLS-updated
> rogue server.  The difference this update will make is much smaller
> as some try to make you believe.  It is definitely not like you
> are competely and hopelessly insecure without it, and
> top-notch invincible as soon as you deploy it.
> 
> The endpoint identifications used by application protocols on top of
> TLS contains plenty of weaknesses itself.  So it's not like you
> should stop worrying.  It's just that your focus shifts and you
> have to worry more about other things now, some of which may me
> much harder to fix.
> 
> 
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 