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

[Christian Huitema]

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

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

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

[Stephen Farrell]

On 01/12/2018 09:10, Dmitry Belyavsky wrote:
> 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

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.

> 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.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

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

[Christian Huitema]

On 12/1/2018 9:24 AM, Tony Arcieri wrote:
> On Sat, Dec 1, 2018 at 8:12 AM Dmitry Belyavsky  > wrote:
>
> I do not understand why the ETSI solution does not provide ability
> to 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.


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

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

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

[Tony Arcieri]

On Sat, Dec 1, 2018 at 8:12 AM Dmitry Belyavsky  wrote:

> I do not understand why the ETSI solution does not provide ability to
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dmitry Belyavsky]

On Sat, Dec 1, 2018 at 6:59 PM Tony Arcieri  wrote:

> 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.
>

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

-- 
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Tony Arcieri]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dmitry Belyavsky]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls