Re: [TLS] Industry Concerns about TLS 1.3

[Viktor Dukhovni]

> On Sep 26, 2016, at 7:21 PM, Eric Rescorla  wrote:
> 
> There are other ways to accomplish this.  For example, the server might
> use session ticket keys that are stored centrally encrypted under a
> suitable escrow key.  If clients always enable session tickets, then
> every handshake will result in the server returning a session ticket,
> in which case the session can be later decrypted if the session ticket
> keys are available.
> 
> This actually doesn't work in TLS 1.3 because the resumption master secret
> is not sufficient to decrypt the connection in which it was established.

Yes, I know that changed.  It was an example of something that works with
TLS 1.2 even when PFS is used.  With TLS 1.3 server or client implementations
can find other ways to retain long-term records of session keys.  The capability
to do that is not a requisite or desirable protocol feature.  Different user
communities will have different needs, and the best solution is to provide
security by default, and cede control of the result to the endpoints.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Eric Rescorla]

On Mon, Sep 26, 2016 at 4:09 PM, Viktor Dukhovni 
wrote:
>
> There are other ways to accomplish this.  For example, the server might
> use session ticket keys that are stored centrally encrypted under a
> suitable escrow key.  If clients always enable session tickets, then
> every handshake will result in the server returning a session ticket,
> in which case the session can be later decrypted if the session ticket
> keys are available.
>

This actually doesn't work in TLS 1.3 because the resumption master secret
is not sufficient to decrypt the connection in which it was established.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Viktor Dukhovni]

> On Sep 26, 2016, at 3:23 PM, BITS Security  
> wrote:
> 
> That said, at least one of the sites you mentioned was known to have an APT 
> inside their perimeter (Operation Aurora) for about a month and part of the 
> tactics within that attack which was publicly reported was the use of "SSL" 
> to mask C communications. That's the type of threat we are concerned about 
> inside of the enterprise network and we need visibility (and flexibility 
> appropriate to our network design and risk tolerance) to solve for these 
> issues in way that protects people like the ones you mentioned.  

I very much doubt that the APT C traffic went out of its way to use
RSA key exchange to make the traffic enterprise-friendly, or even if
it happened to use RSA key exchange that the private keys were available
to the victim site...

All that RSA key exchange gives you is the ability to use long-term
keys of servers you control to decrypt past traffic through that server
if the private keys are still (or for better or worse become) available.

There are other ways to accomplish this.  For example, the server might
use session ticket keys that are stored centrally encrypted under a
suitable escrow key.  If clients always enable session tickets, then
every handshake will result in the server returning a session ticket,
in which case the session can be later decrypted if the session ticket
keys are available.

There's no need to change to the TLS protocol to make such things
possible, it is sufficient to purchase server devices that in one
way or another record session master secrets for later recovery.

There will surely be vendors who'll be more than happy to be paid
to fulfill any business needs in this space.

Having worked in IT security in the financial services industry for
more than a couple of decades now, I am rather surprised and somewhat
appalled by this thread.  I don't believe that the concerns raised
should in any way influence protocol design.  Products that offer less
forward-secrecy than the protocol would otherwise deliver will be
available to those who control either or both end-points and need
to be able to be able to produce after-the-fact plaintext.

The good news about doing key escrow deliberately, rather than
as an unintended side-effect of RSA key exchange, is that it
can be both more reliable and more secure, since the escrow
private keys need not be the same as the server long-term
authentication keys, and are therefor less vulnerable.

RSA key exchange has a long history of problems, and it is time to
move on.  We should not be overly attached to one particular way of
doing key escrow.

-- 
-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Geoffrey Keating]

BITS Security  writes:

> Outbound TLS connections require MITM for decryption.  Inbound or
> internal TLS connections can be decrypted with an RSA private key
> under TLS 1.2.

It would be unwise to build a security or regulatory structure on the
principle that MITM will always be possible.  This is especially true
for the kinds of popular and frequently attacked services for which
DLP might be important, like Facebook, Twitter, Google, Apple,
Dropbox, Github.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Andrei Popov]

?  Then I think your option is to persuade the regulators not to require TLS 
1.3 for internal networks.

?  So in my opinion, it makes sense to keep using TLS 1.2 internally.
Won't the TLS WG stop addressing newly found protocol-level security issues in 
TLS 1.2 at some point in the future? I don't think financial institutions' 
internal networks can stay on TLS 1.2 indefinitely.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xiaoyin Liu
Sent: Monday, September 26, 2016 1:12 PM
To: BITS Security ; Peter Bowen 

Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


Andrew,



Then I think your option is to persuade the regulators not to require TLS 1.3 
for internal networks. Also, unlike SSL 3.0 - TLS 1.1, TLS 1.2 is not currently 
known to be weak or insecure, if properly implemented and not using insecure 
cipher suites. So in my opinion, it makes sense to keep using TLS 1.2 
internally.



Best,

Xiaoyin



From: BITS Security
Sent: Monday, September 26, 2016 3:02 PM
To: Peter Bowen
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


Peter-

Outbound TLS connections require MITM for decryption.  Inbound or internal TLS 
connections can be decrypted with an RSA private key under TLS 1.2.

The PCI DSS is already requiring TLS 1.2 for financial institutions that 
participate in the Payment Card Industry.  .BANK (exclusive top level banking 
domain) is also planning to require TLS 1.2.   We're anticipating that a 
regulatory body like these will require TLS 1.3 at some point in the future.  
Financial institutions then have to comply if they want to continue to do 
business with the companies represented by the regulatory body (like large 
credit card companies in the case of PCI).

-Andrew




-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security 
>
Cc: Yaron Sheffer >; 
tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security 
> wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might 
> expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange versus DH 
for key exchange would only seem to apply when the network tapping system has 
access to the RSA key, right?  So the part of this about monitoring the network 
for external chat and such doesn't really change if the client is using TLS 1.1 
or 1.3, as you still can't decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat under 
control of the monitor, so it can support TLS 1.2 as long as needed.  TLS 1.0 
came out in 1999 and is still now (in 2016) widely deployed.  While I hope TLS 
1.3 deployment is speedy, I don't forsee browsers dropping TLS 1.2 and earlier 
support any time soon.

Thanks,
Peter
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Xiaoyin Liu]

Andrew,



Then I think your option is to persuade the regulators not to require TLS 1.3 
for internal networks. Also, unlike SSL 3.0 – TLS 1.1, TLS 1.2 is not currently 
known to be weak or insecure, if properly implemented and not using insecure 
cipher suites. So in my opinion, it makes sense to keep using TLS 1.2 
internally.



Best,

Xiaoyin



From: BITS Security
Sent: Monday, September 26, 2016 3:02 PM
To: Peter Bowen
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3



Peter-

Outbound TLS connections require MITM for decryption.  Inbound or internal TLS 
connections can be decrypted with an RSA private key under TLS 1.2.

The PCI DSS is already requiring TLS 1.2 for financial institutions that 
participate in the Payment Card Industry.  .BANK (exclusive top level banking 
domain) is also planning to require TLS 1.2.   We're anticipating that a 
regulatory body like these will require TLS 1.3 at some point in the future.  
Financial institutions then have to comply if they want to continue to do 
business with the companies represented by the regulatory body (like large 
credit card companies in the case of PCI).

-Andrew




-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security 
Cc: Yaron Sheffer ; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security  
wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might 
> expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange versus DH 
for key exchange would only seem to apply when the network tapping system has 
access to the RSA key, right?  So the part of this about monitoring the network 
for external chat and such doesn't really change if the client is using TLS 1.1 
or 1.3, as you still can't decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat under 
control of the monitor, so it can support TLS 1.2 as long as needed.  TLS 1.0 
came out in 1999 and is still now (in 2016) widely deployed.  While I hope TLS 
1.3 deployment is speedy, I don't forsee browsers dropping TLS 1.2 and earlier 
support any time soon.

Thanks,
Peter
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

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:tls-boun...@ietf.org] On Behalf Of Brian Sniffen
Sent: Saturday, September 24, 2016 11:31 PM
To: nalini.elk...@insidethestack.com; Watson Ladd ; 
Ackermann, Michael 
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

nalini.elk...@insidethestack.com 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:noloa...@gmail.com]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael 
>> Cc: BITS Security ; tls@ietf.org
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael  
>> 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 

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

Peter- 

Outbound TLS connections require MITM for decryption.  Inbound or internal TLS 
connections can be decrypted with an RSA private key under TLS 1.2. 

The PCI DSS is already requiring TLS 1.2 for financial institutions that 
participate in the Payment Card Industry.  .BANK (exclusive top level banking 
domain) is also planning to require TLS 1.2.   We're anticipating that a 
regulatory body like these will require TLS 1.3 at some point in the future.  
Financial institutions then have to comply if they want to continue to do 
business with the companies represented by the regulatory body (like large 
credit card companies in the case of PCI).

-Andrew




-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security 
Cc: Yaron Sheffer ; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security  
wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might 
> expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange versus DH 
for key exchange would only seem to apply when the network tapping system has 
access to the RSA key, right?  So the part of this about monitoring the network 
for external chat and such doesn't really change if the client is using TLS 1.1 
or 1.3, as you still can't decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat under 
control of the monitor, so it can support TLS 1.2 as long as needed.  TLS 1.0 
came out in 1999 and is still now (in 2016) widely deployed.  While I hope TLS 
1.3 deployment is speedy, I don't forsee browsers dropping TLS 1.2 and earlier 
support any time soon.

Thanks,
Peter
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

[Andrei Popov]

> Pushed to the extreme, the result is a sort of protocol drift, in which buggy 
> variants get first tolerated, and then accepted as de-facto standards.
Indeed, we're seeing several instances of this protocol drift in TLS 1.3 (2.0? 
4.0?), e.g. the relaxed rules around the signature_algorithms extension and the 
version negotiation workaround that just got adopted...

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Christian Huitema
Sent: Friday, September 23, 2016 5:52 PM
To: 'Peter Gutmann' ; 'Andreas Walz' 

Cc: tls@ietf.org
Subject: Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server 
implementations

On Friday, September 23, 2016 1:39 AM, Peter Gutmann wrote:
> Andreas Walz  writes:
>
>>However, where would you draw the line between "I can't" and "I don't 
>>want to"?
> 
> It's one of those judgement-call things, I don't know if you can 
> strictly define it but as a rule of thumb I'd say that if you 
> encounter it during normal processing it's an I-can't problem while if 
> you have to add
special-
> case checks to identify it and refuse to continue it's an 
> I-don't-want-to problem.

Yes of course, but there is another aspect to it, the general health of the 
ecosystem. Postel's rule is nice, but it removes the pressure on broken 
implementations to fix their code. Pushed to the extreme, the result is a sort 
of protocol drift, in which buggy variants get first tolerated, and then 
accepted as de-facto standards. This tends to hinder future evolutions, not to 
mention adding complexity. We often hear that "the IETF has no protocol 
police," but in fact it does. Each implementation that takes a strict view of 
standard compliance contributes to this policing.

-- Christian Huitema



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Martin Rex]

Pawel Jakub Dawidek wrote:
> 
> Because of that, every corporate network needs visibility inside TLS
> traffic not only incoming, but also outgoing, so they can not only
> debug, but also look for data leaks, malware, etc.

There may be a some countries with poor civil liberty protections
where such activies (employee communication surveillance) has
not been criminalized yet, but at least in the European Union,
there is EU Directive 2002/58/EC which requires member states to
criminalize such surveillance.  In Germany, this was criminalized
with the 2004 update of the TKG (Telekommunikationsgesetz) and
will get every employer up to 5 years prison term for doing this.

And no, there can not be any valid regulations to require such
monitoring, because _every_ to the secrecy provisions and criminalization
requires an explicit law from the parlamentarian legislator.

"regulations" are issued by parts of the government (executive power),
and the German national law (TKG) and the German constitution (GG)
formally excludes the executive power from defining/creating exceptions
to telecommunication secrecy.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Pascal Urien]

Hi All

There is a smart way to recover DH secret by a third party

It is DH tripartite base on EC paring

https://tools.ietf.org/html/draft-urien-tls-dh-tripartite-00

Rgs

Pascal



2016-09-25 23:20 GMT+02:00 Ackermann, Michael :

> I understand your concern over what the nation-state actors are doing but
> it is not the same as what Enterprises do to manage their private servers,
> networks and clients.
>
> Your final paragraph is quite a constructive question.   "What
> specifically would you have us do? What do you want in the protocol that
> enables your needs, but doesn't make it possible for everyone in the world
> to be surveilled?  Please, make some specific suggestions."
>
> My personal perspective would be, that the approach to achieving an answer
> to that important question, would start with:
>
> 1.  Gathering  protocol neutral requirements from all involved factions,
> (with help and suggestions from people on the TLS list)
>
> 2.   Brainstorming session(s) with people on the TLS list as well
> potential users/operators, with objectives that include the design of a
> solution that meets (hopefully) all known requirements.
>
> What I would like to see come out of the debate we seem to be currently
> involved in,  is the realization that significant operational/management
> issues exist with TLS 1.3 and that the IETF is taking them seriously enough
> to at least begin dialogue intended to address these issues, and
> potentially work together to craft related solution(s).   In my view this
> issue is far too complex &  pervasive to believe that any one person or
> group's perspective would produce a viable overall solution.
>
> Again, let me restate,  I don't think anyone is saying that we MUST have
> RSA.But, we, as the clients of the IETF TLS protocol, would like to
> work with you to assure we have workable, manageable  and affordable
> solutions,  that meets our needs as well as the needs of others.
>
> -Original Message-
> From: Salz, Rich [mailto:rs...@akamai.com]
> Sent: Saturday, September 24, 2016 10:10 PM
> To: Ackermann, Michael ; Pawel Jakub Dawidek <
> p.dawi...@wheelsystems.com>; tls@ietf.org
> Subject: RE: [TLS] Industry Concerns about TLS 1.3
>
> >   This lack of scope, depth and detail [in MITM infrastructures] are
> > what drove us to install the packet collection infrastructures
> > (debugging networks I think some are saying).
>
> At the risk of repeating myself and flogging this dead horse...  What you
> are doing is exactly what the nation-state actors are doing.  I bet that
> some even use that exact phrase of "packet collection infrastructure."
>
> I understand that if you want to use TLS 1.3, it is going to be expensive
> and/or inconvenient; you're going to have to educate regulators and get
> bespoke TLS endpoint solutions from vendors. Perhaps you can get the NSA's
> to stop collecting everyone's Internet traffic for future decoding?
>
> Less flippantly, what specifically would you have us do? What do you want
> in the protocol that enables your needs, but doesn't make it possible for
> everyone in the world to be surveilled?  Please, make some specific
> suggestions.
>
>
>
>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Martin Rex]

Thijs van Dijk wrote:
> 
> Regular clients, no.
> But this would be a useful addition to debugging / scanning suites (e.g.
> Qualys), or browser extensions for the security conscious (e.g. CertPatrol).

With FREAK and LOGJAM attacks, there is a significant difference in
effort between servers using a static private (DH or temporary RSA) key
vs. truely ephemeral key.  But security checks of "vulnerability scanners"
do not seem to do any checks on whether the server is presenting the
same public key on multiple handshakes.

Generation of truely ephemeral DH keys for every full handshake is IMO
quite expensive for 2048+ bits DH.  The reason why I like Curve25519
is that generation of ephemeral keys is cheap.

-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls