Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Bill Frantz 
On 9/28/16 at 4:27 PM, melinda.sh...@nomountain.net (Melinda 
Shore) wrote:



That said, IETF participation is dominated by large equipment and
software vendors and the problem space, at least until recently
(there's been a crop of data center-related problems coming up in
OPS and routing), has tended to cover service provider-related
questions.  We have poor participation and representation from
enterprise networks.  So now we've got someone showing up from
the enterprise space and saying "I have this problem related to
protocol changes."  And yeah, he's very, very late in this
process, although it's worth pointing out that it's in the best
tradition of the IETF to deal with technical problems that crop
up with documents at any point in their development.


While I fully support trying to design protocols so applications 
and networks can be managed by enterprises (and indeed home 
users), I do not want to see IETF security protocols become more 
complex as a result. That will only make them easy targets for 
attackers. The Clipper chip shows what happens when even experts 
design key recovery systems.


I hope one outcome of this thread is that industry groups which 
use IETF protocols will realize that the best way to have their 
needs recognized is to be active in the relevant groups from the 
beginning and for the long term. I know of no other way to make 
the proper tradeoffs except to have all the issues in front of 
the working group from the beginning of their process. That 
involvement will strengthen the IETF while making sure 
enterprise issues are addressed.


Even as late comers to the process, BITS Security has gotten a 
number of suggestions for ways forward which do not change the 
emerging TLS 1.3 standard. Given that it will be several years 
before regulators require TLS 1.3, vendors will be able step 
forward to fill this need with endpoint logging as well as other 
techniques embedded in "install and run" products. Given the 
list of companies that Tony linked, these products should enjoy 
a profitable market.


Cheers - Bill

---
Bill Frantz| Concurrency is hard. 12 out  | Periwinkle
(408)356-8506  | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |- Jeff Frantz | Los Gatos, 
CA 95032


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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Tony Arcieri 
On Wed, Sep 28, 2016 at 5:49 PM, Melinda Shore  wrote:

> I think it's quite clearly the case that that is not going to happen.
> But, that doesn't mean that these guys don't have a problem worth
> addressing, even if they're asking for a crap solution to it.  The
> IETF is an insular organization and I tend to think that leads to
> poorer outcomes in some cases than we might otherwise have produced.


Their argument is the PCI council will mandate TLS 1.3 soon. This is not
the case. A TLS *1.1* mandate by the PCI council has been delayed until
2018.

I work for a company that directly participates in the PCI council, and
have been participating in the TLS and CFRG process for several years
(again, I do not directly represent either in this discussion).

I do not think that TLS 1.3 in its current form will cause them any
practical real-world problems for these companies, rather they seem to be
attempting to futureproof their current bad practices.

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Melinda Shore 
On 9/28/16 4:36 PM, Tony Arcieri wrote:
> The IETF is doing great work. This entire thread is a distraction, and I
> hope it does not result in changes which weaken TLS 1.3's security.

I think it's quite clearly the case that that is not going to happen.
But, that doesn't mean that these guys don't have a problem worth
addressing, even if they're asking for a crap solution to it.  The
IETF is an insular organization and I tend to think that leads to
poorer outcomes in some cases than we might otherwise have produced.

I am not suggesting that his request for a protocol that he
can break needs serious consideration, but that the fact that he's
come up with an unacceptable solution to a problem that he's
identified doesn't mean that the problem either doesn't exist or
is completely outside the IETF's scope.

All that's going to come out of discussion here is unhelpful
and largely redundant finger-wagging.  I think these guys ought
to write up the problem they've got and post a draft.

Melinda




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Tony Arcieri 
On Wed, Sep 28, 2016 at 4:27 PM, Melinda Shore  wrote:

> We have poor participation and representation from
> enterprise networks.  So now we've got someone showing up from
> the enterprise space and saying "I have this problem related to
> protocol changes."  And yeah, he's very, very late in this
> process, although it's worth pointing out that it's in the best
> tradition of the IETF to deal with technical problems that crop
> up with documents at any point in their development.


"BITS Security" is representing *some* companies in the payments space,
namely these ones: http://fsroundtable.org/members/

Their concerns are not representative of "the enterprise", "the industry",
"the payments space", etc. In fact some of the companies in the
aforementioned link have personally contacted me to note they disagree with
"BITS Security". Even among their cabal, their opinion is contentious.

My personal opinion, as a security professional directly working on
implementing TLS for a payments company, is their last-minute proposed
changes would harm the security of our payments platform. I want to deploy
TLS 1.3 in its current form. I also think the reasoning for their proposed
changes is based on flawed premises.

There are relevant industry groups BITS Security seems actually concerned
with, such as the PCI Council. BITS Security should be voicing their
concerns there, and the PCI Council should be working with the IETF to
implement such changes if they're actually deemed necessary.

I do not think this is a case of the IETF failing to understand "industry
requirements". I strongly disagree the proposal represents "industry
requirements" at all. I think they are trying to subvert the IETF process
because they have inadequate security processes and they do not want to see
their inadequate processes disturbed by security improvements to TLS.

As a payments professional, my personal opinion is improving the security
of TLS is *paramount*. The voiced concerns are not representative of
"enterprise", "industry", or "payments" as a whole, but an last-minute
opinion of companies who haven't been paying attention to the process who
do not want to invest in upgrading their security practices.

The IETF is doing great work. This entire thread is a distraction, and I
hope it does not result in changes which weaken TLS 1.3's security.

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Melinda Shore 
On 9/28/16 3:08 PM, Bill Frantz wrote:
> On 9/28/16 at 2:01 AM, m...@sap.com wrote:
>> I'm sorry, but I'm still violently opposed to the IETF endorsing
>> backdooring of security protocols.
> I find myself in violent agreement with Martin, and many others in the
> IETF.

This seems uncontroversial and frankly somewhat low-information.
Yay, crypto backdoors are bad.

That said, IETF participation is dominated by large equipment and
software vendors and the problem space, at least until recently
(there's been a crop of data center-related problems coming up in
OPS and routing), has tended to cover service provider-related
questions.  We have poor participation and representation from
enterprise networks.  So now we've got someone showing up from
the enterprise space and saying "I have this problem related to
protocol changes."  And yeah, he's very, very late in this
process, although it's worth pointing out that it's in the best
tradition of the IETF to deal with technical problems that crop
up with documents at any point in their development.

It seems to me that the discussions of alternatives to modifying
the protocol to meet his needs has been extremely helpful, and it
also seems to me that in some sense this ought to be an object
lesson to large enterprises dealing with fairly sophisticated
protocol problems that they really need to get involved and make
their requirements known.  If there's a need here for a new
monitoring framework that doesn't involve compromising the
security of IETF protocols, that strikes me as an interesting
question.  In the meantime I'd hate to see this level of hectoring
continue - we need more participation from other kinds of network
operators, not less.

Melinda




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-16

2016-09-28 Thread Andrei Popov 
Ø  I don't really agree that we shouldn't specify client order. We do that 
everywhere else in TLS.
+ 1
While I agree that the server should be using the server’s preferences in most 
cases, I see no reason for the client to not list protocol versions (and cipher 
suites, for that matter) in the client’s order of preference. The client needs 
to send all supported options; no need to randomize the order.


Ø  Rather, I think we should relax the requirement to pick the highest one, 
which is just a holdover from a less expressive negotiation mechanism.
In addition, it’s not always clear what the “highest” TLS version is, e.g. in 
the presence of national TLS “standards”. E.g. a particular server may prefer 
TLS 0x0100 over TLS 0x0304.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, September 28, 2016 10:15 AM
To: Stephen Checkoway 
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-tls13-16

I don't really agree that we shouldn't specify client order. We do that 
everywhere else in TLS.

Rather, I think we should relax the requirement to pick the highest one, which 
is just a holdover from a less expressive negotiation mechanism.


-Ekr


On Wed, Sep 28, 2016 at 9:18 AM, Stephen Checkoway 
> wrote:

> On Sep 28, 2016, at 11:08 AM, Salz, Rich 
> > wrote:
>
>
>> C.2 Negotiating with an older client says, "If the
>>   "supported_versions" extension is present, the server MUST negotiate
>>   the highest server-supported version found in that extension."
>
> I agree that an appendix is the wrong place to put this.  And that specifying 
> the client order is pointless.
>
> But I disagree with this being a MUST.  There may be times when the server 
> knows more than the client and will know that a lower version is more 
> appropriate.  E.g., interfering middleboxes or regulatory regimes.

Seems reasonable. How about making selection from the list (if the extension is 
present) a MUST and selecting the highest server-supported version is 
RECOMMENDED? Perhaps the second part is unnecessary.

--
Stephen Checkoway



___
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

2016-09-28 Thread Yoav Nir 

> On 28 Sep 2016, at 7:16 PM, Dan Brown  wrote:
> 
> As I understand the concern, the worry is that Bud is compromising Bob's 
> (TLS) server, to somehow send Bob's plaintext to the wrong place.
>  
> The proposed (existing?) strategy has Bob compromising his own 
> forward-secrecy to stop Bud, but only after the cat is out of the bag. This 
> seems a high price (no forward-secrecy) to pay for little gain 
> (cat-out-of-bag).
>  
> It seems wiser for Bob to somehow monitor or log what is being done with his 
> own plaintexts at his own server. I know little about existing products to do 
> this, but from my theoretical perspective, it ought to be easier than 
> compromising forward-secrecy (logging ciphertexts).
>  
> If proper plaintext monitoring or logging is somehow too costly, then yes...

I don’t really understand under what circumstances logging, monitoring or 
storing the plaintext is not feasible, while storing the ciphertext is. Because 
if you don’t store the ciphertext, then keeping static or ephemeral keys around 
doesn’t buy you much.  It’s true that current server products don’t log or 
store the plaintext, but they could easily be modified to do that. There are 
extensions to browsers that store the plaintext if you want.

Maybe if the good folks at the Bluffdale facility are willing to let you 
download their copy of your captured ciphertexts, then it makes sense to store 
only ephemeral or static keys. Otherwise it seems cheaper to store the 
plaintext than to store both ciphertext and keys.

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

Re: [TLS] draft-ietf-tls-tls13-16

2016-09-28 Thread Eric Rescorla 
I don't really agree that we shouldn't specify client order. We do that
everywhere else in TLS.

Rather, I think we should relax the requirement to pick the highest one,
which is just a holdover from a less expressive negotiation mechanism.


-Ekr


On Wed, Sep 28, 2016 at 9:18 AM, Stephen Checkoway  wrote:

>
> > On Sep 28, 2016, at 11:08 AM, Salz, Rich  wrote:
> >
> >
> >> C.2 Negotiating with an older client says, "If the
> >>   "supported_versions" extension is present, the server MUST negotiate
> >>   the highest server-supported version found in that extension."
> >
> > I agree that an appendix is the wrong place to put this.  And that
> specifying the client order is pointless.
> >
> > But I disagree with this being a MUST.  There may be times when the
> server knows more than the client and will know that a lower version is
> more appropriate.  E.g., interfering middleboxes or regulatory regimes.
>
> Seems reasonable. How about making selection from the list (if the
> extension is present) a MUST and selecting the highest server-supported
> version is RECOMMENDED? Perhaps the second part is unnecessary.
>
> --
> Stephen Checkoway
>
>
>
> ___
> 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] draft-ietf-tls-tls13-16

2016-09-28 Thread Adam Langley 
On Wed, Sep 28, 2016 at 9:37 AM, Salz, Rich  wrote:
> On the crypto-library side, boringSSL had equivalence classes so you could 
> specify that by configuring the CIPHER list. If running in a server, and the 
> configured ciphers were like "[AES:CHACHA]:3DES:RC4" for example, then either 
> AES or ChaCha would be picked.  I don't know if Google servers use that, but 
> I'd be a bit surprised if they didn't.
>
> As for OpenSSL, we need to figure out something.  The "ciphers" syntax is 
> showing its age.

The equal-preference groupings have worked pretty well for us in terms
of making the right thing happen and being understandable to
non-experts. I certainly agree that the ciphers mini-language could do
with some renewal overall.

But I think a lot of the need for it is also going away. We've spent
years worrying about should we do forward security? Do we put RC4
ahead of AES-CBC because of BEAST / POODLE / etc? What about the poor
performance of AES-GCM with Java (for a while)?

But since we've now drastically reduced the number of options, and
those options are (fingers crossed) less shitty than before, I'd hope
that a default would work for the vast majority of TLS 1.3 users.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] draft-ietf-tls-tls13-16

2016-09-28 Thread Salz, Rich 

> C.2 Negotiating with an older client says, "If the
>"supported_versions" extension is present, the server MUST negotiate
>the highest server-supported version found in that extension."

I agree that an appendix is the wrong place to put this.  And that specifying 
the client order is pointless.

But I disagree with this being a MUST.  There may be times when the server 
knows more than the client and will know that a lower version is more 
appropriate.  E.g., interfering middleboxes or regulatory regimes.
 
--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [TLS] draft-ietf-tls-tls13-16

2016-09-28 Thread Martin Thomson 
On 29 September 2016 at 02:02, Stephen Checkoway  wrote:
> * The only time to take the client's preference into account is if the server 
> really has no opinion on an option--e.g., two equivalent-strength cipher 
> suites--but the client can specify a preference for an option that requires 
> less computation/power for it. But I'm not entirely convinced that's worth 
> the implementation cost.

I generally agree, though we just added one small exception to NSS,
and have been discussing another for a while now:  Respecting client
preference for ChaCha over GCM makes a real difference for clients
that don't have AES-NI.

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

Re: [TLS] draft-ietf-tls-tls13-16

2016-09-28 Thread Stephen Checkoway 

> On Sep 22, 2016, at 6:42 PM, Eric Rescorla  wrote:
> 
> - New version negotiation format (*) [IMPORTANT: this got lost in the 
> ChangeLog]

4.2.1 Supported Versions says, "The extension contains a list of
   supported versions in preference order, with the most preferred
   version first."

C.2 Negotiating with an older client says, "If the
   "supported_versions" extension is present, the server MUST negotiate
   the highest server-supported version found in that extension."

I'm skeptical of the server respecting client preferences in any situation*, 
but if servers are required to negotiate the highest supported version (which I 
think is sensible), then there's no point to the client giving preference order.

I propose moving the text about which version a server must negotiate out of 
the appendix to 4.2.1 and replacing the text mentioning client preference order 
with arbitrary order. (We could mandate descending version order, but it seems 
silly for the server to reject 0304, 0302, 0303 
if it's willing to negotiate 0304, for example.)



* The only time to take the client's preference into account is if the server 
really has no opinion on an option--e.g., two equivalent-strength cipher 
suites--but the client can specify a preference for an option that requires 
less computation/power for it. But I'm not entirely convinced that's worth the 
implementation cost.

-- 
Stephen Checkoway



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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Martin Rex 
Martin Rex wrote:
> Stephen Farrell wrote:
> > 
> > On 28/09/16 01:17, Seth David Schoen wrote:
> > > People with audit authority can then know all of the secrets,
> > 
> > How well does that whole audit thing work in the financial services
> > industry?  (Sorry, couldn't resist:-)
> 
> I am actually having serious doubts that it works at all.
> 
> Consider a scenario that uses TLSv1.2 with static-RSA key exchange,
> plain old session caching and Microsoft style renego-client-cert-auth
> on a subset of the urlspace.
> 
> (1) first TLS session, full handshake, request to public area.
> 
> (2) TLS session resume, request to non-public area -> renego
> 
> (3) TLS session resume for renego'ed session to non-public area.
> 
> 
> To obtain the cleartext of session (3), you'll need the master secret
> of the renego'ed session from (2), for which you'll first have to locate
> and decrypt (2), for which you need the master secret from (1), so you'll
> have to locate (1), and only at (1) you can start opening the encryption
> with the longterm private RSA key of the server.
> 
> It is impossible to open (3) directly, and the ClientKeyExchange
> handshake message (and client randoms) that created the master secret
> of session (3) is encrypted during renegotiation, so one can not
> directly recover that with the longterm private RSA key of the server,
> but has to open (2) first.

And it might even be more difficult than that.

Because the Server Hello (with the server-issued new session_id)
is encrypted during renegotiation, one can not see which renegotiation
created the session that is resumed in (3), and may have to decrypt
several renegotiation handshakes in order to find the correct one
which created the session_id (3).

-Martin

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Martin Rex 
Stephen Farrell wrote:
> 
> On 28/09/16 01:17, Seth David Schoen wrote:
> > People with audit authority can then know all of the secrets,
> 
> How well does that whole audit thing work in the financial services
> industry?  (Sorry, couldn't resist:-)

I am actually having serious doubts that it works at all.

Consider a scenario that uses TLSv1.2 with static-RSA key exchange,
plain old session caching and Microsoft style renego-client-cert-auth
on a subset of the urlspace.

(1) first TLS session, full handshake, request to public area.

(2) TLS session resume, request to non-public area -> renego

(3) TLS session resume for renego'ed session to non-public area.


To obtain the cleartext of session (3), you'll need the master secret
of the renego'ed session from (2), for which you'll first have to locate
and decrypt (2), for which you need the master secret from (1), so you'll
have to locate (1), and only at (1) you can start opening the encryption
with the longterm private RSA key of the server.

It is impossible to open (3) directly, and the ClientKeyExchange
handshake message (and client randoms) that created the master secret
of session (3) is encrypted during renegotiation, so one can not
directly recover that with the longterm private RSA key of the server,
but has to open (2) first.


-Martin

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Joachim Strömbergson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Aloha!

Salz, Rich wrote:
>> 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.
> 
> Okay, in technical terms only, what is the difference?
> 
>> My personal perspective would be, that the approach to achieving an
>> answer to that important question, would start with:
> 
> It's too late for that.  We're at the end-game, not the start.  I'm
> only a WG member, not editor, chair, or Area Director, but I would be
> extremely surprised if there was any consensus to delay things.

This whole thread looks scarily close to an attempt at throwing a
spanner into the machinery.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.

 Joachim Strömbergson  Secworks AB  joac...@secworks.se

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIbBAEBCAAGBQJX6466AAoJEF3cfFQkIuyN+xEP+OFOliFsdy8qzTlYFXwEKaHm
CsujoaU/vswzXK6y3MadGn4rVhBjuaA1P4Iu5E1/w8Wlm7B6HOTXqM2iJVCv1bQs
D8iS5JRS9TR3cnXtEDk51V+nYQmDxFBhNILwukVrp8alvvVh/ww21bLxrp9xrLy5
8rfynu6BD2QreVfRGYDjT4rfxU5t+EecwCsxBn1JM/+Uv0/e/cFQVI55dnWm4OWi
WwX7ieRyd/N76VadyHhAV9VFXnpIewBSINyroCfBEHDeiDmYEQcCcIOVjMI6EHp8
T3D/rCZR865G06PO7gxY4IVsS4pbd3lXYyG/+9SSDm/axWJ7FasoaoaqXm19EaCc
p9399BaJss7kLS+1c63axzm7xcdRE1fqJN2oJNlRnD7zv6ycvcg2cbuC5HUKasHx
H9RL7VAry33KP8EGBMPbf8Ep9IfX2l/dtMe1FMuNaTajsXj9vMKi0eOZ5EVPykqZ
fuX9rwMUXafNkWVrVUflxQHU9fY6+5ZkncoEtUUQASlGeL2K9edMdUD0vs5WceHe
HYc4mLdJsi88crwE5/HPQHl8ncZCTwlMTxxyAdySf4uotKPQytnPha1mPrijOUQS
A4KEzIA1BcEFSdMR/3v2Bw8qNLA5HU5fV22NBlS8nYkgdqmmF9nwUTgJ7G2x8zcw
2HBLYpaDWnMyGEcaAv0=
=9iJ/
-END PGP SIGNATURE-

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Martin Rex 
Judson Wilson wrote:
> 
> I think this challenge is best solved by putting the information on the
> wire in some way, possibly as a special industry-specific extension (used
> only by those who are bent on shooting themselves in the foot). The benefit
> being that if the TLS channel is alive, the session information is
> available to the monitor.  Just as a strawman, the client could transmit
> session info in special records, encrypted by a public key, and the
> monitoring equipment could scoop these up. For compatibility with servers
> outside the network, a middlebox could somehow filter out these records.
> 
> It sounds like the need is large enough that such an effort is feasible,
> and it would be good to keep normal TLS 1.3 unambiguously forward secure.
> (There IS still the question of how to make sure that the extension is not
> enabled in endpoints it shouldn't be.)


Whoa there.  What you're describing is essentially the
Clipper-Chip & Skipjack encryption

https://en.wikipedia.org/wiki/Skipjack_(cipher)


I'm sorry, but the IETF decided back then that it doesn't want
to standardize such technology:

https://tools.ietf.org/html/rfc1984


I'm sorry, but I'm still violently opposed to the IETF endorsing
backdooring of security protocols.


-Martin

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Hannes Tschofenig 
Hi Andrew,

I am coming from a different industry, the embedded industry, and for us
at ARM the development of TLS 1.3 will help us to increase the security
of Internet of Things devices as well as to improve the performance of
the handshake. We are reaching out to developers and our partners to
tell them about the importance of randomness and keys generated on on
low end microcontrollers.

From reading your text it feels that you have been relying on technology
that intercepts security protocols in a way that follows an
architectural model that wasn't necessarily sound to begin with. Maybe
it is time to rethink the architectural choices you have made or at
least challenge your favorite deep packet inspection vendors a bit more.

Ciao
Hannes

On 09/22/2016 07:19 PM, BITS Security wrote:
> To:  IETF TLS 1.3 Working Group Members
>
> My name is Andrew Kennedy and I work at BITS, the technology policy
> division of the Financial Services Roundtable
> (http://www.fsroundtable.org/bits).  My organization represents
> approximately 100 of the top 150 US-based financial services
> companies including banks, insurance, consumer finance, and asset
> management firms.
>
> I manage the Technology Cybersecurity Program, a CISO-driven forum to
> investigate emerging technologies; integrate capabilities into member
> operations; and advocate member, sector, cross-sector, and
> private-public collaboration.
>
> While I am aware and on the whole supportive of the significant
> contributions to internet security this important working group has
> made in the last few years I recently learned of a proposed change
> that would affect many of my organization's member institutions:  the
> deprecation of RSA key exchange.
>
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant
> problems for financial institutions, almost all of whom are running
> TLS internally and have significant, security-critical investments in
> out-of-band TLS decryption.
>
> Like many enterprises, financial institutions depend upon the ability
> to decrypt TLS traffic to implement data loss protection, intrusion
> detection and prevention, malware detection, packet capture and
> analysis, and DDoS mitigation.  Unlike some other businesses,
> financial institutions also rely upon TLS traffic decryption to
> implement fraud monitoring and surveillance of supervised employees.
> The products which support these capabilities will need to be
> replaced or substantially redesigned at significant cost and loss of
> scalability to continue to support the functionality financial
> institutions and their regulators require.
>
> The impact on supervision will be particularly severe.  Financial
> institutions are required by law to store communications of certain
> employees (including broker/dealers) in a form that ensures that they
> can be retrieved and read in case an investigation into improper
> behavior is initiated.  The regulations which require retention of
> supervised employee communications initially focused on physical and
> electronic mail, but now extend to many other forms of communication
> including instant message, social media, and collaboration
> applications.  All of these communications channels are protected
> using TLS.
>
> The impact on network diagnostics and troubleshooting will also be
> serious.  TLS decryption of network packet traces is required when
> troubleshooting difficult problems in order to follow a transaction
> through multiple layers of infrastructure and isolate the fault
> domain.   The pervasive visibility offered by out-of-band TLS
> decryption can't be replaced by MITM infrastructure or by endpoint
> diagnostics.  The result of losing this TLS visibility will be
> unacceptable outage times as support groups resort to guesswork on
> difficult problems.
>
> Although TLS 1.3 has been designed to meet the evolving security
> needs of the Internet, it is vital to recognize that TLS is also
> being run extensively inside the firewall by private enterprises,
> particularly those that are heavily regulated.  Furthermore, as more
> applications move off of the desktop and into web browsers and mobile
> applications, dependence on TLS is increasing.
>
> Eventually, either security vulnerabilities in TLS 1.2, deprecation
> of TLS 1.2 by major browser vendors, or changes to regulatory
> standards will force these enterprises - including financial
> institutions - to upgrade to TLS 1.3.  It is vital to financial
> institutions and to their customers and regulators that these
> institutions be able to maintain both security and regulatory
> compliance during and after the transition from TLS 1.2 to TLS 1.3.
>
> At the current time viable TLS 1.3-compliant solutions to problems
> like DLP, NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and
> monitoring of regulated employee communications appear to be immature
> or nonexistent.  There are serious cost, scalability, and security
> concerns with all of the

[TLS] How to contribute to TLS RFC

2016-09-28 Thread ranjana mukhia 
Hello,

I have just joined a new company and have been asked to contribute to TLS
RFC within two years. I request you to guide me how to go about it. What
books etc will you recommend ? Please also advise if I should also join a
TLS implementation group. If yes, which one ?

Thanks and Regards,

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