Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security <[e-mail]>]

Hi Brian--Thanks for the practitioner comment.  

Something perhaps worth mentioning here is that there often isn't just one support team inside an enterprise.  There are application support teams for each application, network support people, security engineering support people, server support people, desktop support people, mainframe support people, packet analysis teams.  All of them use different methods, and often each doesn't know details about how the other teams work.  Some of these teams do work at the endpoints but many gain visibility through other means (at least in the FS industry).  

-Andrew 




-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Brian Sniffen
Sent: Saturday, September 24, 2016 11:31 PM
To: [e-mail]; Watson Ladd <[e-mail]>; Ackermann, Michael <[e-mail]>
Cc: [e-mail]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

[e-mail] writes:

> [ Unknown encryption status ]
> [ Unknown signature status ]
>
>
>
>>>
>>> What I am saying,  in relation to your "Delivering a stable product"  comment is that over time various industries have learned what it takes to "Deliver a stable product".    We did not >>want to invest millions in these debugging networks.  But  we learned the hard way,  that it was necessary.
>>> I am not a member of the banking coalition that started this subject,  nor of the banking industry at all,  but I certainly understand their perspective and am concerned about  the same >>unmanageable future they described.
>
>>Do  Akami, Cloudlflare and Google magically not have these problems?
> It would be very interesting to get the network diagnostic and 
> operations people (rather than the architects) of the above companies 
> involved in this conversation.

Hi, technical person most directly responsible for incident response and urgent debugging here.  We modify endpoints to get what we need.  We did have taps that relied on knowing the RSA Kx secret... but haven't used them in about a decade.

I think the banks have an answer not available to the global passive
adversaries: modify the server or client to use a fixed ECDH share, then use tech much like their current choices.  It'll take a while to develop, but nobody in that environment plans to move to TLS 1.3 for operational systems any time soon anyway.

-Brian


> Also, you know, companies don't really enjoy spending money on network 
> diagnostic products which might be considered overhead.   So, if they are, we might do them the courtesy of not thinking that they are foolish to do so. Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).
> Isn't our goal to have the best standards possible?   Any organism (including the IETF), needs feedback to thrive.
> Nalini
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -----Original Message-----
>> From: Jeffrey Walton [mailto:[e-mail]]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <[e-mail]>
>> Cc: BITS Security <[e-mail]>; [e-mail]
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <[e-mail]> wrote:
>>> From the perspective an Enterprise that runs these applications and has invested HEAVILY in the debugging networks.........
>>>
>>> The reason we are debugging these networks is so that "The 5-6 order of magnitude of folks using them"  will have good service.  If they do not,  they will consider competitors and/or generate a litany service calls or complaints.        I.E.    When these "Folks"  are slow or not working they are just as unhappy as we are.
>>>
>>
>> Isn't that the market operating as expected? Those who deliver a stable product at a competitive price are rewarded, while those who fail to deliver or deliver at an unreasonable cost are not? (Some hand waiving).
>>
>> If all providers failed to deliver or delivered an inferior product, then it might indicate a major course correction is needed. But I don't think that's the case here.
>>
>> Jeff
>>
>>
>> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>>
>>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>    
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>>>
>>> What I am saying,  in relation to your "Delivering a stable product"  comment is that over time various industries have learned what it takes to "Deliver a stable product".    We did not >>want to invest millions in these debugging networks.  But  we learned the hard way,  that it was necessary.
>>> I am not a member of the banking coalition that started this subject,  nor of the banking industry at all,  but I certainly understand their perspective and am concerned about  the same >>unmanageable future they described.
>
>>Do  Akami, Cloudlflare and Google magically not have these problems?
> It would be very interesting to get the network diagnostic and operations people (rather than the architects) of the above companies involved in this conversation.
> Also, you know, companies don't really enjoy spending money on network 
> diagnostic products which might be considered overhead.   So, if they are, we might do them the courtesy of not thinking that they are foolish to do so. Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).
> Isn't our goal to have the best standards possible?   Any organism (including the IETF), needs feedback to thrive.
> Nalini
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -----Original Message-----
>> From: Jeffrey Walton [mailto:[e-mail]]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <[e-mail]>
>> Cc: BITS Security <[e-mail]>; [e-mail]
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <[e-mail]> wrote:
>>> From the perspective an Enterprise that runs these applications and has invested HEAVILY in the debugging networks.........
>>>
>>> The reason we are debugging these networks is so that "The 5-6 order of magnitude of folks using them"  will have good service.  If they do not,  they will consider competitors and/or generate a litany service calls or complaints.        I.E.    When these "Folks"  are slow or not working they are just as unhappy as we are.
>>>
>>
>> Isn't that the market operating as expected? Those who deliver a stable product at a competitive price are rewarded, while those who fail to deliver or deliver at an unreasonable cost are not? (Some hand waiving).
>>
>> If all providers failed to deliver or delivered an inferior product, then it might indicate a major course correction is needed. But I don't think that's the case here.
>>
>> Jeff
>>
>>
>> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>>
>>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls

--
Brian Sniffen
Akamai Technologies

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls