Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Stephen Farrell <[e-mail]>]

On 22/10/17 21:48, Steve Fenter wrote:
> The main problem with not addressing the TLS visibility issue now is
> that no one knows when a vulnerability will be discovered in TLS 1.2
> that forces enterprises to upgrade to TLS 1.3. We've had guarantees
> that TLS 1.2 and the RSA key exchange are going to be fine for 5 to
> 10 years, but nobody knows that, particularly in today's security
> environment. I've also learned that getting a solution in place
> through the IETF is a multi-year process, and then vendor adoption
> time has to be added on top of that.  Enterprises don't want to be
> caught in a position where a vulnerability is forcing us to upgrade,
> and we are starting at ground zero on a multi-year process to restore
> TLS visibility. We have to get out in front of this problem so we're
> not caught unprepared.

Wait. What?

One of your arguments for needing snooping is that you
claim a lack of competence in debugging applications that
use TLS.

So to solve that, you propose we introduce a rarely used,
sporadically supported method of leaking keys to third
parties. IOW, you add what's called a vulnerability and
do so in a complex manner in code paths that'll hardly
ever be used (according to the proponents, they'll only
be used in the "proper" places, or at least, none of you
have so far ever acknowledged the falsity of that "proper"
places magical thinking).

Rarely used complex code for leaking keys... hmm, now
what is that likely to lead to? Oh yes, bugs.

But now you claim that a well tested protocol with fairly
mature implementations (TLS1.2) might have bugs that cause
you to need to add your additional complex key-leaking
vulnerability feature which'll magically have no bugs?

I think you can fairly claim a worst argument of the year
prize for that one;-)

S.

PS: Your claim about "guarantees" is just false afaics. I
saw no such thing on the list. Please desist from inventing
statements that were not made, or point me at where someone
said something that is even remotely possible to confuse
with such a guarantee. (Combining risible argument and false
claims really isn't wise.)


> 
> Sent from my iPad
> 
>> On Oct 20, 2017, at 11:57 AM, "Salz, Rich" <[e-mail]>
>> wrote:
>> 
>> 
>> 
>> So it sounds like we are in agreement that continuing to use TLS
>> 1.2 is not a viable long term  alternative.
>> 
>> 
>> Long-term is a subjective term, and using it can lead to
>> misunderstandings.
>> 
>> Based on current and previous actions around SSL and TLS versions,
>> you can use TLS 1.2 for at least five, likely at least 10, years.
>> 
>> 
>> 
>> _______________________________________________ TLS mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>