Subject: [TLS] ETSI releases standards for enterprise security and data centre management

From: Dmitry Belyavsky <[email-masked]>
Date: Sat, 1 Dec 2018 12:10:36 +0300

Dear All,

JFYI. Via Feisti Duck nerwsletter.

https://www.etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management

The eTLS key exchange shall use exactly the same messages and procedures to
establish a set of session keys as a
TLS 1.3 ephemeral Diffie-Hellman key exchange, except for two differences
[2].
1) the server shall use a static public/private key pair at Step 2 in
clause 4.3.1; and
2) the server's certificate at Step 5 shall contain visibility information
as defined in clause 4.3.3 to indicate to the
client that eTLS is in use.
NOTE: Neither the static public key nor the visibility information affects
the operation of a TLS 1.3 compliant
client, so an eTLS server is therefore fully interoperable with TLS 1.3
compliant clients.

-- 
SY, Dmitry Belyavsky

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 1 Dec 2018 07:59:45 -0800

This does not seem to address a problem which was brought up when the
similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
system in possession of one of the non-ephemeral-ECDHE private keys,
ostensibly for the purposes of passive traffic decryption, can arbitrarily
resume decrypted sessions and therefore impersonate any observed clients.

I'm not a fan of systems like this, but I believe for security reasons they
should be designed in such a way that only the confidentiality of traffic
is impacted, and a "visibility" system isn't able to leverage the decrypted
traffic to resume decrypted sessions and thereby impersonate clients.

-- 
Tony Arcieri

---

From: Dmitry Belyavsky <[email-masked]>
Date: Sat, 1 Dec 2018 19:11:54 +0300

On Sat, Dec 1, 2018 at 6:59 PM Tony Arcieri <[email-masked]> wrote:

> I'm not a fan of systems like this, but I believe for security reasons
> they should be designed in such a way that only the confidentiality of
> traffic is impacted, and a "visibility" system isn't able to leverage the
> decrypted traffic to resume decrypted sessions and thereby impersonate
> clients.
>

I do not understand why the ETSI solution does not provide ability to
impersonate clients/servers.

-- 
SY, Dmitry Belyavsky

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 1 Dec 2018 09:24:18 -0800

> impersonate clients/servers.

My understanding of this solution is a "visibility" system would have
access to a not-so-ephemeral ECDHE private key. This gives it access (via
passive observation) to all session keys ultimately derived from ECDHE key
agreement, including the resumption master secret.

See RFC 8446, section 7.1: Key Schedule

(EC)DHE -> HKDF-Extract = Handshake Secret
             |
             +-----> Derive-Secret(., "c hs traffic",
             |                     ClientHello...ServerHello)
             |                     = client_handshake_traffic_secret
             |
             +-----> Derive-Secret(., "s hs traffic",
             |                     ClientHello...ServerHello)
             |                     = server_handshake_traffic_secret
             v
       Derive-Secret(., "derived", "")
             |
             v
   0 -> HKDF-Extract = Master Secret
             |
             +-----> Derive-Secret(., "c ap traffic",
             |                     ClientHello...server Finished)
             |                     = client_application_traffic_secret_0
             |
             +-----> Derive-Secret(., "s ap traffic",
             |                     ClientHello...server Finished)
             |                     = server_application_traffic_secret_0
             |
             +-----> Derive-Secret(., "exp master",
             |                     ClientHello...server Finished)
             |                     = exporter_master_secret
             |
             +-----> Derive-Secret(., "res master",
                                   ClientHello...client Finished)
                                   = resumption_master_secret

-- 
Tony Arcieri

---

From: Christian Huitema <[email-masked]>
Date: Sat, 1 Dec 2018 10:02:44 -0800

On 12/1/2018 9:24 AM, Tony Arcieri wrote:
> On Sat, Dec 1, 2018 at 8:12 AM Dmitry Belyavsky <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I do not understand why the ETSI solution does not provide ability
>     to impersonate clients/servers. 
>
>
> access to a not-so-ephemeral ECDHE private key. This gives it access
> (via passive observation) to all session keys ultimately derived from
> ECDHE key agreement, including the resumption master secret.

Which is indeed a huge problem. Security conscious implementations of
TLS should detect the use of such "enhancements", and either abort the
session or automatically treat it as insecure.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 2 Dec 2018 00:23:10 +0000

> https://www.etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management

Yes, it is a shame that ETSI's role in transport security
appears to be to stick their noses in the trough of cast-off
proposals that didn't garner IETF consensus due to insecurity.

I hope that that properly (i.e., negatively), influences
people's opinions of ETSI, and of any government or industry
body so easily open to capture. Put another way, the IETF's
imperfect but terrifically open process considered this for
more than a year, (once there were people who raised the
topic, no matter how ineptly) and concluded there was no
consensus to even start such work, whereas ETSI appear to
have picked up those droppings and started and finished their
"standardisation" "process" (ironic quoting intended:-) in
roughly the same amount of time an open process requires to
conclude that such proposals are rubbish.

> The eTLS key exchange shall use exactly the same messages and procedures to

I also hope the IETF aren't shy about enforcing copyright
on the name TLS. (Not that I understand copyright;-)

Cheers,
S.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Christian Huitema <[email-masked]>
Date: Sat, 1 Dec 2018 17:42:50 -0800

On 12/1/2018 11:14 AM, Tony Rutkowski wrote:
>
> The eTLS use case is an enterprise network or data center that is
> owned or dedicated and under the control of a company (e.g., a
> financial institution) or government agency that is subject to
> compliance obligations that require auditing and traffic monitoring
> capabilities for their systems and users.  This relatively bounded use
> case should be kept in mind here.  The associated tutorial is
> helpful. 
> https://www.etsi.org/news-events/events/1338-2018-10-webinar-middlebox-security-protocol-explained
>

Which reinforces the idea that these "enhancements" have no legitimate
reason to be found "in the wild", and hence should be treated as errors
when detected.

-- Christian Huitema

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 2 Dec 2018 16:38:53 +0000

Exactly. I for one am against such "enhancements" and agree that treating them as errors is the right way.

Regards,
Uri

Sent from my iPhone

> On Dec 1, 2018, at 20:44, Christian Huitema <[email-masked]> wrote:
> 
>

---

From: Nico Williams <[email-masked]>
Date: Sun, 2 Dec 2018 17:35:54 -0600

> traffic to resume decrypted sessions and thereby impersonate clients.

Any key escrow system will have this property.  Given the session keys
(or a way to recover them) you can resume decrypted sessions.

If I had to I would build a corporate TLS 1.3 session key escrow system
as follows:

 - use a keyed PRF/PRNG to generate the ephemeral DH keys, with two
   inputs, a secret key shared with the escrow third party, and a number
   generated randomly:

   edh_key = DH_key_gen(seed = PRF+(escrowed_key, r = getrandom()));

 - log to the escrow third party {connection ID, random} for each
   connection (the connection ID can be a handshake transcript hash).

   (it's even safe to log the random number r in the clear, as it alone
   is insufficient for recovering session keys)

This would preserve all the properties of TLS 1.3 and would work for any
other version of TLS with EDH too, and also for any other protocols that
use ephemeral key agreement (SSHv2, IKE, ...).

It's more work to integrate this than to use RSA key transport with
escrowed RSA key orchestration, but it's one-time work (do it for about
six or so open source implementations and you've got 90+% coverage).

I'm sure upstreams would accept this sort of contribution as it is
better for everyone outside corporate environments if we can just stop
the pressure to go back to RSA key transport.  It's also better for
corporate environments, as insiders are the largest threat there, so
forward security is still a plus even in corporate environments.

Nico
--

---

From: Jonathan Hoyland <[email-masked]>
Date: Tue, 4 Dec 2018 16:34:08 +0100

Is it necessarily true that any key escrow system must allow resumptions?

Just to play devil's advocate, consider defining a new cipher suite that
appended a MAC to each message before applying one of the other cipher
suites.
If the MAC is keyed with a key not derived from the master secret, but from
some other value shared between the client and server, but not the
middlebox, then the middlebox would be able to read all* the traffic, but
would not be able to successfully resume the session.

*The middlebox would not be able to verify the tag, so technically it can't
check /everything/, but it would be able to read the data on the channel
without being able to modify it.

Regards,

Jonathan

On Sun, 2 Dec 2018 at 23:36 Nico Williams <[email-masked]> wrote:

> they

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 Dec 2018 15:40:37 +0000

*   Just to play devil's advocate, consider defining a new cipher suite that appended a MAC to each message before applying one of the other cipher suites.

But that would defeat their purpose, which is on-the-wire compatibility with real TLS.

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Dec 2018 09:48:12 -0600

> would not be able to successfully resume the session.

This MAC key would also have to be involved in the session resumption
PSK, but yes.  You don't even need this extra MAC past the handshake,
you just need an extra key not known to the escrow agent for use in the
session resumption PSK.  (The extra MAC on every record would impose too
much overhead.)

> without being able to modify it.

Oh sure, if you're willing to do such violence to TLS, then yes, it can
be done.

However, a constraint here is that an escrow design can't really require
client-side modifications without the IETF approving of it and the
client implementations accepting the change.

The most obvious escrow design requiring no changes to the clients is to
use a static eDH key on the server-side.  The next most obvious such
design is to have the server talk to the escrow agent.

Nico
--

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 4 Dec 2018 08:18:44 -0800

> (or a way to recover them) you can resume decrypted sessions.

Wouldn't escrowing only the client/server application traffic secrets
(instead of keys higher in the schedule) avoid this problem? These keys
would permit the one capability "visibility" appliance vendors allege to
care about: traffic decryption, without permitting others like session
resumption.

> design is to have the server talk to the escrow agent.

It seems like with an out-of-band escrow agent, the traffic secrets could
be escrowed with no changes to TLS.

--
Tony Arcieri

---

From: Jonathan Hoyland <[email-masked]>
Date: Tue, 4 Dec 2018 17:39:30 +0100

Isn't there a lower bar at the IETF for defining new cipher suites, as long
as you're not seeking a "recommended" setting?

I think escrowing lower down keys / not MACing the messages beyond the
handshake means that you lose authenticity and integrity of the message
data, which is unattractive.
How burdensome would the extra few bytes actually be, given that the
alternative is substantially weaker security?

Regards,

Jonathan

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Dec 2018 11:43:14 -0600

> as you're not seeking a "recommended" setting?

Yes, but then you have to get interoperability using them, which means
patching clients and servers.  You can't 100% escrow this way.

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Dec 2018 07:07:30 +0300

> session or automatically treat it as insecure.

This certainly looks like a case of forum-shopping to do an end-run
around the underlying goals of TLS as a 2-party protocol that
prioritizes confidentiality, integrity, and authenticity between the two
peers.

Even worse, the supposed "VisibilityInformation" mechanism is stuffed
into subjectAltName in the server's certificate, which means that it
can't even depend on the "critical bit" that would have been available
to a standard X.509v3 certificate extension.  This appears to encourage
deployment to unaware clients.

I've just submitted draft-dkg-tls-reject-static-dh-00, which suggests
that responsible TLS clients that observe a server certificate with a
subjectAltName otherName with the VisibilityInformation type-id (OID
0.4.0.3523.3.1 {itu-t(0) identified-organization(4) etsi(0) msp(3523)
etls(3) visibility(1)}) MUST reject the certificate.  I'm open to
feedback on it.

    https://datatracker.ietf.org/doc/draft-dkg-tls-reject-static-dh/

One mitigating factor of the ETSI standard, i suppose, is that the
CABForum's Baseline Requirements forbid issuance of a certificate with
any subjectAltName other than dNSName or iPAddress, so otherName looks
like it must not be issued by standard public CAs.

top of p. 44 of https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf

Has anyone set up tools to monitor the CT logs for such a sAN to see
whether that element of the BR is being honored?

    --dkg

---

From: Bret Jordan <[email-masked]>
Date: Wed, 5 Dec 2018 17:08:44 +0900

Now this WG is finally starting to talk about a solution to a real problem and need.  We can either address the use case and need here in the IETF, or we can let the solutions be done else where. I would personally prefer we take this work item back and solve it here in the IETF.

Finally, remember, you may not like the use case or need, but that does not mean the use case is not valid and needed. 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Dec 5, 2018, at 1:18 AM, Tony Arcieri <[email-masked]> wrote:
> 
> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams <[email-masked] <mailto:[email-masked]>> wrote:
> Wouldn't escrowing only the client/server application traffic secrets (instead of keys higher in the schedule) avoid this problem? These keys would permit the one capability "visibility" appliance vendors allege to care about: traffic decryption, without permitting others like session resumption.
> 
> It seems like with an out-of-band escrow agent, the traffic secrets could be escrowed with no changes to TLS.
> 
> --
> Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Dec 2018 09:12:02 +0000

On 05/12/2018 08:08, Bret Jordan wrote:
> Now this WG is finally starting to talk about a solution to a real
> problem and need.  We can either address the use case and need here
> in the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this work item back and solve it here in
> the IETF.

#include <previous-discussions>

I would hope the WG not revisit this topic and see no new
facts to justify distracting the WG again. Forum shopping
is not new - rubber-stamping by ETSI or ANSI was explicitly
proposed as a putative reason to adopt draft-green and that
did not result in consensus to work on this topic despite
the significant effort put in by proponents. I'm also happy
to say that I see no evidence that the WG would reach a
different conclusion as to lack of consensus.

FWIW, I view this discussion as being analogous to scratching
an itchy scab - despite our knowing it is unproductive to do
so, some IETF participants apparently can't resist poking at
the wound:-(

S.

> 
> Finally, remember, you may not like the use case or need, but that
> does not mean the use case is not valid and needed.
> 
> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
> the only thing that can not be unscrambled is an egg."
> 
>>> I'm not a fan of systems like this, but I believe for security
>>> reasons they should be designed in such a way that only the
>>> confidentiality of traffic is impacted, and a "visibility" system
>>> isn't able to leverage the decrypted traffic to resume decrypted
>>> sessions and thereby impersonate clients.
>> 
>> Any key escrow system will have this property.  Given the session
>> keys (or a way to recover them) you can resume decrypted sessions.
>> 
>> Wouldn't escrowing only the client/server application traffic
>> secrets (instead of keys higher in the schedule) avoid this
>> problem? These keys would permit the one capability "visibility"
>> appliance vendors allege to care about: traffic decryption, without
>> permitting others like session resumption.
>> 
>> The most obvious escrow design requiring no changes to the clients
>> is to use a static eDH key on the server-side.  The next most
>> obvious such design is to have the server talk to the escrow
>> agent.
>> 
>> It seems like with an out-of-band escrow agent, the traffic secrets
>> could be escrowed with no changes to TLS.
>> 
>> -- Tony Arcieri _______________________________________________ TLS
>> mailing list [email-masked] 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Dec 2018 11:27:30 +0300

On Wed 2018-12-05 17:08:44 +0900, Bret Jordan wrote:
> problem and need.  We can either address the use case and need here in
> the IETF, or we can let the solutions be done else where. I would
> personally prefer we take this work item back and solve it here in the
> IETF.

Or, the IETF can say with relative clarity that this kind of information
leakage is inappropriate for and incomaptible with the information
security goals of TLS.

> does not mean the use case is not valid and needed.

Sure, but just because someone says it is, doesn't mean that the use
case is valid or needed within the scope of TLS either.

Throughout the (several years now) discussion of this sort of proposal,
we've repeatedly heard about "legal obligations" which somehow evaporate
when pressed for details.  And we've heard about "operational
considerations" which typically amount to cost-shifting concerns (they
can come across as: "we've invested a bunch of money in this particular
network architecture/application design, please change the infosec
guarantees provided by TLS for everyone on the global network so that we
don't have to do an expensive re-tooling or staff up on new skills while
i'm responsible for this budget line item").

The WG is chartered to make TLS a fast, secure, confidential transport
layer.  Let's keep the charter goals in mind.

        --dkg

---

From: Benjamin Beurdouche <[email-masked]>
Date: Wed, 5 Dec 2018 10:34:43 +0100

> layer.  Let's keep the charter goals in mind.

+ 1

---

From: Bret Jordan <[email-masked]>
Date: Wed, 5 Dec 2018 19:22:05 +0900

I think we should be more open minded and look at the needs from a 360 degree deployment perspective. The real power of the IETF is in looking at all the needs and requirements and designing solutions for them.

We should flesh this out. It seems like several people on this list so far have proposed options that might work. If we spent half as much time looking for a solution as we have trying to prevent a solution, we would probably be done by now. 

Thanks,
Bret

> On Dec 5, 2018, at 6:12 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Dec 2018 10:33:01 +0000

On 05/12/2018 10:22, Bret Jordan wrote:
> I think we should be more open minded and look at the needs from a
> 360 degree deployment perspective. 

I think we should avoid marketing speak.

> The real power of the IETF is in
> looking at all the needs and requirements and designing solutions for
> them.

The IETF is sometimes at it's best when it says "no." This
is one of those cases.

> We should flesh this out. It seems like several people on this list
> so far have proposed options that might work. If we spent half as
> much time looking for a solution as we have trying to prevent a
> solution, we would probably be done by now.

All of the above was done, at length, and we got a result.
The TLS WG had no consensus to work on this topic.

S.

>>> Now this WG is finally starting to talk about a solution to a
>>> real problem and need.  We can either address the use case and
>>> need here in the IETF, or we can let the solutions be done else
>>> where. I would personally prefer we take this work item back and
>>> solve it here in the IETF.
>> 
>> I would hope the WG not revisit this topic and see no new facts to
>> justify distracting the WG again. Forum shopping is not new -
>> rubber-stamping by ETSI or ANSI was explicitly proposed as a
>> putative reason to adopt draft-green and that did not result in
>> consensus to work on this topic despite the significant effort put
>> in by proponents. I'm also happy to say that I see no evidence that
>> the WG would reach a different conclusion as to lack of consensus.
>> 
>> FWIW, I view this discussion as being analogous to scratching an
>> itchy scab - despite our knowing it is unproductive to do so, some
>> IETF participants apparently can't resist poking at the wound:-(
>> 
>> S.
>> 
>>> 
>>> Finally, remember, you may not like the use case or need, but
>>> that does not mean the use case is not valid and needed.
>>> 
>>> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0
>>> 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw,
>>> however, the only thing that can not be unscrambled is an egg."
>>> 
>>>> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> I'm not a fan of systems like this, but I believe for
>>>>> security reasons they should be designed in such a way that
>>>>> only the confidentiality of traffic is impacted, and a
>>>>> "visibility" system isn't able to leverage the decrypted
>>>> Any key escrow system will have this property.  Given the
>>>> session keys (or a way to recover them) you can resume
>>>> decrypted sessions.
>>>> 
>>>> problem? These keys would permit the one capability
>>>> "visibility" appliance vendors allege to care about: traffic
>>>> decryption, without permitting others like session resumption.
>>>> 
>>>> The most obvious escrow design requiring no changes to the
>>>> clients is to use a static eDH key on the server-side.  The
>>>> next most obvious such design is to have the server talk to the
>>>> escrow agent.
>>>> 
>>>> It seems like with an out-of-band escrow agent, the traffic
>>>> secrets could be escrowed with no changes to TLS.
>>>> 
>>>> -- Tony Arcieri _______________________________________________
>>>> TLS mailing list [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Wed, 5 Dec 2018 20:15:08 +0900

Comments inline 

Sent from my Commodore 128D

> On Dec 5, 2018, at 7:33 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

This is not marketing speak. This is understanding how these solutions need to be deployed end to end in all of their scenarios from consumer, to small business, to enterprise, to service provider, to content provider, to telco, etc.  

> The IETF is sometimes at it's best when it says "no." This

I disagree.

> The TLS WG had no consensus to work on this topic.

Or it could be said the TLS WG had no consensus to not work on it.  When there is a tie who wins? It seems like working on a solution that works for the larger community is the right solution.  The use case and need is a valid requirement.

Bret

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 05 Dec 2018 15:36:12 +0300

On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote:
> This is not marketing speak. This is understanding how these solutions
> need to be deployed end to end in all of their scenarios from
> consumer, to small business, to enterprise, to service provider, to
> content provider, to telco, etc.

Perhaps one of the reasons that this might across as marketing speak to
some people is that your list of "all their scenarios" appears to be
only business use cases (where the individual people involved are at
most consumers of business products).  You haven't mentioned
journalists, disk jockeys, activists, flat earthers, dissidents,
students, medical professionals, juggalos, community organizers, gun
nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free
software developers, elected officials, religious minorities, senior
citizens, or any of the other non-business use cases that may depend on
TLS for confidentiality, integrity, authenticity, or any of the other
information security guarantees that are put at risk by proposals like
this.

One of the concerns the last time we danced this dance was that the
proposal claimed to be interested in one use case only: "the enterprise
data center", and yet offered no meaningful way to effectively limit its
(ab)use outside the data center.  This objection was raised clearly, and
the proponents of the protocol change failed to address it.  And now it
appears that instead of addressing the concern, they forum-shopped until
they found a place to publish the same approach without even
acknowledging the concern that this could have an impact beyond the data
center.

A full 360 degree view might acknowledge that doing harm to the core
priniciples of a security protocol that everyone relies on for the sake
of one particular use case out of many might not be an appropriate step
to take.  (and that one use case might have other solutions, albeit
perhaps more expensive or inconveient ones for people who have already
made certain investments)

I'm pretty sure we don't want TLS to be all things to all people, right?
What are the core goals or guarantees of TLS that you would like to see
preserved?

        --dkg

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 5 Dec 2018 07:51:26 -0800

On Wed, Dec 5, 2018 at 12:09 AM Bret Jordan <[email-masked]> wrote:

> Now this WG is finally starting to talk about a solution to a real problem
> and need.  We can either address the use case and need here in the IETF, or
> we can let the solutions be done else where. I would personally prefer we
> take this work item back and solve it here in the IETF.
> [...]
>
> [...]
> Note that the solution I was proposing here requires no changes to TLS. I
am sure that there are many in the IETF who would be happy with people
exploring solutions which don't require changes to TLS.

Here are some others:

   - Endpoint agents (OSS - commercial options are also available):
   - https://osquery.io/
      - https://www.bro.org/ (now Zeek)
      - https://wazuh.com/
      - Encrypted traffic analytics:
   https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back

--
Tony Arcieri

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Dec 2018 16:12:31 +0000

Ooh, good catch.  I bet the ETSI folks didn't know this.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Dec 2018 16:27:49 +0000

*   Or it could be said the TLS WG had no consensus to not work on it.  When there is a tie who wins? It seems like working on a solution that works for the larger community is the right solution.  The use case and need is a valid requirement.

That’s not the way it works.  When deciding whether or not to adopt something as a WG item, unless there is consensus to DO it, then the consensus is DO NOT do it.  There is no tie.  A decision was made, and by not adopting this work, the WG decided to NOT DO IT.

---

From: R duToit <[email-masked]>
Date: Wed, 05 Dec 2018 11:44:04 -0500

I like the gist of what Tony is saying.  Key escrow (it should be called "secret escrow", but I digress) itself is not really the problem in a datacenter - those guys struggle to solve the key distribution problem.  If it was one-server-to-one-tool then we would not be having this discussion.  eTLS looks like an attempt to simplify the key distribution implementation, but at the expense of the security attributes of the TLS session. Why don't we provide a "sandbox" mechanism that would allow business-solution folks to solve the key distribution problem without directly affecting the TLS session?  What I have in mind is a TLS extension that would unlock a new TLS record ContentType called "foo" (for lack of a name).  All "foo" records will be completely ignored by the TLS stack, including not affecting the TLS record sequence number or crypto state.  That mechanism can then be used to send in-band messages that could be picked up by inline and passive tools along the way.  Mechanisms that use "foo" records could potentially be designed outside the IETF, and the TLS-WG would have no responsibility for insecure implementations of multi-party secret sharing mechanisms (although it would be good to point those engineers in the right direction). --Roelof ---- On Wed, 05 Dec 2018 10:51:26 -0500 Tony Arcieri <[email-masked]> wrote ---- On Wed, Dec 5, 2018 at 12:09 AM Bret Jordan <[email-masked]> wrote: Now this WG is finally starting to talk about a solution to a real problem and need.  We can either address the use case and need here in the IETF, or we can let the solutions be done else where. I would personally prefer we take this work item back and solve it here in the IETF. [...] On Dec 5, 2018, at 1:18 AM, Tony Arcieri <[email-masked]> wrote: [...] It seems like with an out-of-band escrow agent, the traffic secrets could be escrowed with no changes to TLS. Note that the solution I was proposing here requires no changes to TLS. I am sure that there are many in the IETF who would be happy with people exploring solutions which don't require changes to TLS. Here are some others: Endpoint agents (OSS - commercial options are also available): https://osquery..io/ https://www.bro.org/ (now Zeek) https://wazuh.com/ Encrypted traffic analytics: https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back -- Tony Arcieri _______________________________________________ TLS mailing list [email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: Christopher Wood <[email-masked]>
Date: Wed, 5 Dec 2018 08:44:46 -0800

> That’s not the way it works.  When deciding whether or not to adopt something as a WG item, unless there is consensus to DO it, then the consensus is DO NOT do it.  There is no tie.  A decision was…

Rich's assessment is correct. This may very well be a legitimate use
case and goal, though we previously concluded via lack of consensus
that it does not align with the goals of WG. Therefore, this
discussion should happen elsewhere, and not in this particular WG. I
recommend contacting the ADs for advice as to where this discussion
should go next.

Best,
Chris (for the chairs)

---

From: Melinda Shore <[email-masked]>
Date: Wed, 5 Dec 2018 08:04:34 -0900

On 12/5/18 7:27 AM, Salz, Rich wrote:
> That’s not the way it works.  When deciding whether or not to adopt
> something as a WG item, unless there is consensus to DO it, then the
> consensus is DO NOT do it.  There is no tie.  A decision was made, and
> by not adopting this work, the WG decided to NOT DO IT.

I'm going to split hairs here, since there are a few participants
in the discussion who aren't experienced in the ways of the IETF:
If there's no consensus then there's no consensus.  However, the
outcome, in this case, is very much the same.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Andrei Popov <[email-masked]>
Date: Thu, 6 Dec 2018 02:10:06 +0000

I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will cost servers some perf:

   "Given the concerns in Section 2 and the necessary client mitigations
   in the subsections above, servers need to avoid giving the appearance
   of using non-ephemeral DH.  Servers MUST NOT reuse ephemeral DH
   shares."

In our tests, we see significant drop in handshakes/sec on a busy TLS server with ephemeral DH share reuse time < 1 sec.

Also, won't the "enterprise TLS" server just create a bunch of static DH shares and send different ones at different times, thereby avoiding detection by most clients?

Cheers,

Andrei

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 06 Dec 2018 23:25:01 +0300

Hi Andrei--

On Thu 2018-12-06 02:10:06 +0000, Andrei Popov wrote:
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.

interesting, i'd love to see more details on those tests if you can
share them.  What kind of load are we talking about?  Which server
implementation?

The cost here is in the fixed-base operation, iiuc, which is the
cheapest part of the handshake -- DH share reuse allows you to skip this
one step per handshake (or rather, to amortize the one step across
multiple handshakes).

You mention a cutoff of 1 second.  If the amortization is spread across,
say, all handshakes within 2 seconds, is the performance impact still
significant?

If the draft's server guidance were to be amended to suggest avoiding DH
reuse for more than 2 seconds, and the guidance for clients to track
added a buffer of 2 seconds before rejection, would that satisfy your
concerns about performance under load?

> Also, won't the "enterprise TLS" server just create a bunch of static
> DH shares and send different ones at different times, thereby avoiding
> detection by most clients?

I don't think that the intent of the ETSI spec is to encourage
non-visible use.  They've specifically stated visibility to clients as a
primary goal, and acknoweldged that "Annex A" servers would be in
violation of their own goals.

So it's conceivable that truly malicious servers would do this, of
course, but they might also just publish the master secret on twitter
too, and the client wouldn't know how to detect that inband either.  But
for the misbehavior that we *can* detect in-band, a responsible client
should be aware of it and avoid it, right?

       --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Dec 2018 00:04:50 +0300

> server with ephemeral DH share reuse time < 1 sec.

hm, thinking about this optimization approach, i would really like to
know what implementations are doing this.  It occurs to me that client
implementations as well as server implementations could be doing this
"for efficiency reasons".

If both sides do it, and two connections are established within the
window before the "ephemeral" keys are disposed of, then you could end
up in a scenario where you actually have a "Handshake Secret" and
"Master Secret" that are reused across a connection, and this would be
entirely observable by a passive monitor.

That leaves the only defense against direct key reuse for encryption on
the wire the entropy in:

 * ClientHello and ServerHello (for
   {client,server}_handshake_traffic_secret)

 * ClientHello and server Finished (for
   {client,server}_application_traffic_secret_0 and
   exporter_master_secret)

 * ClientHello and client Finished (for
   resumption_master_secret)

Seems like risky business... we're leaning heavily on HKDF-Expand-Label
to keep a passive observer from being able to identify how the actual
traffic keys across sessions are related to one another.  Or am i
missing something?  I'd love for someone to correct me here.

Maybe i'll add a section to the draft explicitly forbidding clients from
ever taking this "optimization" step as well.

      --dkg

---

From: Andrei Popov <[email-masked]>
Date: Thu, 6 Dec 2018 21:08:00 +0000

> What kind of load are we talking about?  
~2500 full handshakes per sec, basic workstation HW.

> Which server implementation?
HTTP.SYS/IIS.

> If the amortization is spread across, say, all handshakes within 2 seconds, is the performance impact still significant?
In a specific quick test that I did, there was no significant perf impact with key reuse time > 1 sec. And I could probably get it down to sub-seconds on my HW. But HW specs differ between TLS servers; our current "ephemeral" key lifetime is a generous 30 sec., mainly because we saw no reason to push for a lower key lifetime.

> So it's conceivable that truly malicious servers would do this, of course,...
"Truly malicious" is perhaps an overstatement for this easy workaround explicitly permitted by the "Enterprise TLS" spec:
"In some essential circumstances, the visibility information field may be omitted."

Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing connections to "enterprise TLS" servers would probably qualify as "essential circumstances", at least to some operators.

Cheers,

Andrei

-----Original Message-----
From: Daniel Kahn Gillmor <[email-masked]> 
Sent: Thursday, December 6, 2018 12:25 PM
To: Andrei Popov <[email-masked]>; [email-masked]
Subject: RE: [TLS] ETSI releases standards for enterprise security and data centre management

Hi Andrei--

> server with ephemeral DH share reuse time < 1 sec.

interesting, i'd love to see more details on those tests if you can share them.  What kind of load are we talking about?  Which server implementation?

The cost here is in the fixed-base operation, iiuc, which is the cheapest part of the handshake -- DH share reuse allows you to skip this one step per handshake (or rather, to amortize the one step across multiple handshakes).

You mention a cutoff of 1 second.  If the amortization is spread across, say, all handshakes within 2 seconds, is the performance impact still significant?

If the draft's server guidance were to be amended to suggest avoiding DH reuse for more than 2 seconds, and the guidance for clients to track added a buffer of 2 seconds before rejection, would that satisfy your concerns about performance under load?

> detection by most clients?

I don't think that the intent of the ETSI spec is to encourage non-visible use.  They've specifically stated visibility to clients as a primary goal, and acknoweldged that "Annex A" servers would be in violation of their own goals.

So it's conceivable that truly malicious servers would do this, of course, but they might also just publish the master secret on twitter too, and the client wouldn't know how to detect that inband either.  But for the misbehavior that we *can* detect in-band, a responsible client should be aware of it and avoid it, right?

       --dkg

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 6 Dec 2018 15:29:13 -0800

> should be aware of it and avoid it, right?

If nothing else, implementations which reuse ephemeral keys for long
periods of time are buggy and contain a vulnerability which violates the
security assumptions of the protocol.

I think it's reasonable for clients to detect and reject this behavior, as
it's an indicator TLS has been deployed in an insecure way and therefore
the connection should be aborted. I think this could detect a wide range of
"real world" TLS implementation failures which have come up in the past,
including bugs in random number generation and bugs in the code in TLS
stacks responsible for rotating ephemeral keys.

-- 
Tony Arcieri

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Dec 2018 18:30:18 -0500

> On Dec 6, 2018, at 4:08 PM, Andrei Popov <Andrei.Popov=[email-masked]> wrote:
> 

I don't think the TLS WG or IETF can win this skirmish.  If some
operators are set on session recording, they'll find a way, and
the more obstacles they have to overcome the more likely they are
to compromise security along the way.

So while clients should not do anything special to support this,
and the protocol should not change to adapt to the use-case, it
might in fact be more productive to help the operators who need
this arrive at an approach that minimizes risk.  Explicitly
trying to defeat what they're sure to do anyway does look like
a wise approach to me.

The operators could, for example, derive the (EC)DH private key
from an HMAC of the client and server random with a secret
key shared with the wiretap device.  The client would never
know, and the (EC)DH key would not look any different to an
outside observer.

The best we can probably do is publicize the risks, so that
auditors are well aware of them and can highlight poor designs,
and hope that some operators will decide they can do without
such intercepts, or will use an approach that preserves as
much security as possible.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Dec 2018 02:45:12 +0300

On Thu 2018-12-06 21:08:00 +0000, Andrei Popov wrote:
> In a specific quick test that I did, there was no significant perf
> impact with key reuse time > 1 sec. And I could probably get it down
> to sub-seconds on my HW. But HW specs differ between TLS servers; our
> current "ephemeral" key lifetime is a generous 30 sec., mainly because
> we saw no reason to push for a lower key lifetime.

Is this on both client side and server side?  That is, does SChannel as
a client also use an "ephemeral" key lifetime of a generous 30 seconds?

> "In some essential circumstances, the visibility information field may be omitted."

The ETSI "Middlebox Security Protocol" explicitly aims to drop Annex A.
They've said that they *want* visibility and that is an explicit goal.

Surely the purpose of visibility is to ensure that both parties involved
are running the significantly weaker eTLS, and not TLS.  Opting for
visibility while expecting clients to not do anything with the knowledge
gained doesn't make much sense to me.

       --dkg

---

From: Andrei Popov <[email-masked]>
Date: Fri, 7 Dec 2018 00:04:02 +0000

> I don't think the TLS WG or IETF can win this skirmish.  
That's what I'm thinking as well, although I agree with the goals of draft-dkg-tls-reject-static-dh-01.

Cheers,

Andrei

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Dec 2018 18:09:11 -0600

> draft-dkg-tls-reject-static-dh-01.

Yes.  What we can, and IMO should do, is say that if you must do key
escrow or session recording, to it out-of-band.

Nico
--

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 6 Dec 2018 16:30:48 -0800

On Thu, Dec 6, 2018 at 3:30 PM Viktor Dukhovni <[email-masked]>
wrote:

> > Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing
> connections to "enterprise TLS" servers would probably qualify as
> "essential circumstances", at least to some operators.
>

I think there are very strong technical/security reasons to reject using a
static D-H key in place of an ephemeral D-H key, namely compromise of this
key permits "impersonation" of any previously (passively) observed TLS
sessions by allowing a passive observer holding one of these keys to
recover the resumption master secret.

In as much as people are attempting to build standards around this
approach, based on the conversation earlier in this thread it seems they
were unaware of this security property. I hope this causes the creators of
"eTLS" to reconsider the security implications of their proposal.

I think a protocol which aims to fulfill the specific goals of "eTLS"
should focus on providing a way for a passive observer to recover the
*traffic* secrets, which would provide the ability to passively decrypt
traffic (something I think is a bad idea, but I digress), but *NOT* resume
observed sessions.

-- 
Tony Arcieri

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Fri, 07 Dec 2018 02:19:01 +0000

I am really surprised how the answers you don't like are systematically put on denial. Can you explain me what leads you to think that some people here are not concerned by the list of people you list? this is an assumption and the wrong assumption.

Perhaps on the contrary we are concerned BOTH by what these people endure but too by what other consistencies are basically removed rights to defend themselves.

As to the marketing aspect frankly this is an invention here and again I don't see what allows you to paint the answers you don't like because you don't like.

So I could on the contrary hightight the dogmatism that reins here, with a smell of intimidation, and to some degree the sectarianism back to the latin roots of the word

Regarding Human Rights, we DO care about Human Rights too and fact is that I had the chance to make more progress in 2 hours than I did in 2 years at IET and I had the chance to contribute to a magic moment with a Chinese Organization to comply a technical solution to Human Rights requirements. You know why? Because we took the time to TALK properly to each other, understand each other, learn from each other with no intimidation and no wrong assumptions that 'because we LOOK to be on the wrong side' we are foolish people, and respect to the fact that not everyone speaks and writes a proper English and sometimes words are dangerous when we don't know exactly the semantics in the right context

The assumption that you are the only one who cares is tiresome.

This group was offered a chance to control the development of a 360 degree solution for all parties and it was rejected. Fine. The ETSI took it and is taking its responsibly.

I don't know what leads you to think that a model where security resides only on the 2 ends of the communication IS the answer to all the problems.

The recent continuous scandals that are affecting a number of platforms and destroying trust, privacy and security is leading me to think about why should I trust this model. By analogy when I see how my body defends itself against bad stuff, it is using a battery of models, not one model.

In any negotiation you can look for what is the right battle, and those who understand that point will know that the right battle (and the one which is harder for the opposition) is on providing guarantees. This would have been a better battle to pick and would have given a chance to work more collaboratively and not by confrontation.

Now I don't understand what leads this group to try now to block the ETSI, can someone tell me and in particular the chairs if we have a consensus here?

Finally I am calling on the chairs of this group. It was very interesting to observe the many comments at the last IETF103 about the vile and toxic atmosphere that prevails here. I have all my time to work in these conditions but perhaps the chair could try to think about a more positive atmosphere of work.

A bon entendeur salut

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor <[email-masked]> wrote:

> > > On Dec 5, 2018, at 7:33 PM, Stephen Farrell [email-masked] wrote:
> > >

---

From: Sean Turner <[email-masked]>
Date: Fri, 7 Dec 2018 10:37:28 -0500

Please stand by.

The chairs (Joe, Chris, and myself) have been discussing whether this draft is in scope.  We are meeting later today to wrap up the discussion and get message out to the WG.

spt

> On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF <Arnaud.Taddei.IETF=[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Dec 2018 09:42:16 -0800

The Security ADs sent the following liaison statement to ETSI on this topic:
https://datatracker.ietf.org/liaison/1616/

On Sat, Dec 1, 2018 at 1:11 AM Dmitry Belyavsky <[email-masked]> wrote:

> https://www..etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management
> <https://www.etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management>
>
> The eTLS key exchange shall use exactly the same messages and procedures
> to establish a set of session keys as a

---

From: Sean Turner <[email-masked]>
Date: Fri, 7 Dec 2018 17:48:57 -0500

There is no WG consensus to adopt this draft as no WG adoption call has been made.  draft-dkg-tls-reject-static-dh is an individual draft that is currently being discussed on this list; in much the same way draft-green-tls-static-dh-in-tls13 and draft-rhrd-tls-tls13-visibility were individual drafts that were discussed on this list; there was no WG consensus to adopt draft-rhrd-tls-tls13-visibility and there was never a call to adopt draft-green-tls-static-dh-in-tls13.  

The chairs have been debating whether draft-dkg-tls-reject-static-dh is in scope or whether the discussion should be moved elsewhere.  Parts of this draft we believe are in scope, e.g., providing guidance on handling key share re-use and pitfalls for not following this guidance.  (Note that how to handle key share re-use is not the same thing as explicitly prohibiting re-use of keys.)  Other parts of the draft contain material for which we did not reach consensus to address, such as Section 3.3 on prohibiting key-share reuse.  We are not the protocol police and have recently gotten out of that business, e.g., by removing barriers for cipher suite code points. We do not want to get back in that business.

In order to ensure a focused discussion and avoid rehashing the previous debate regarding draft-rhrd-tls-tls13-visibility, parts of this draft should be rescoped or removed.  Authors are free to take this material to an AD and seek sponsorship, or to the ISE/IAB for further guidance.

Cheers,
Joe, Chris, and Sean

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 9 Dec 2018 18:35:20 +0100

> whether that element of the BR is being honored?

All the linters will give an error about that, see for instance:
https://crt.sh/?id=1009623020&opt=x509lint,cablint,zlint

Kurt

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 11 Dec 2018 06:56:14 -0500

> https://crt.sh/?id=1009623020&opt=x509lint,cablint,zlint

right, so what is to be done about that, when some of these CAs are
clearly violating the BRs?  Transparency is only as useful as the
actions we can take once violations are uncovered.  Unactionable
transparency just sounds like despair to me.  So what's the action?

          --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 11 Dec 2018 13:27:39 +0000

The IETF is not the protocol police, nor are we the data-format police as you well know.  All we can do is name-and-shame when interop fails.

What are these BRs of which you speak?  Not an IETF spec.  Go report violations to the place that wrote them I guess.

I've also heard tell of an anyone-can-join discussion group, https://groups.google.com/forum/#!forum/mozilla.dev.security.policy, where these kinds of things are discussed.

	/r$, yes I know all this.  So does dkg I believe.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 11 Dec 2018 08:39:14 -0500

On Tue, Dec 11, 2018 at 6:58 AM Daniel Kahn Gillmor <[email-masked]>
wrote:

> >> top of p. 44 of
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf
> >>

The same as it is for any misissuance:
1) Report to the CA’s problem reporting mechanism. The  Baseline
Requirements require they provide one in Section 1.5.2 of their CPS (BRs
Section 4.9.3). The CA is obligated to revoke such certificates and,
according to various root policies, report and/or disclose to the root
programs they participate in or publicly.

If you are unsatisfied with the answer you get from the CA, or want to
ensure greater transparency, you can/should also
2) Report to any root programs that trust those CAs.

The example from Kurt is from a CA that is ONLY trusted by Microsoft, and
which other programs have, sometimes explicitly, declined to trust. If CAs
are violating the contractual or public requirements of Microsoft’s root
program, such as the one demonstrated (although notably, it is NOT
displaying the use of this ETSI MITM extension), then that is an
enforcement action for Microsoft, or something for their customers to
respond to if Microsoft is shipping insecure CAs to them.

Your best-best-case is that publicly trusted CAs never issue such
certificates. Your worst-best-case is that the CA has to revoke within 24
hours/5 days of issuance, and that the root program takes the violation
into consideration when evaluating whether to trust that CA. Your
worst-worst case is that the CA ignores the revocation requirements, as
they did the issuance requirements, and that root programs that trust those
CAs fail to take action to ensure consistency among the CAs they trust and
with the requirements.

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Thu, 13 Dec 2018 03:29:30 +0000

I appreciate this answer, thank you

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday 7 December 2018 23:48, Sean Turner <[email-masked]> wrote:

> > On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF Arnaud.Taddei.IETF=[email-masked] wrote:
> > On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor [email-masked] wrote:
> >