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

I appreciate this answer, thank you Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday 7 December 2018 23:48, Sean Turner wrote: > 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

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

On Tue, Dec 11, 2018 at 6:58 AM Daniel Kahn Gillmor wrote: > On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote: > > On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote: > >> One mitigating factor of the ETSI standard, i suppose, is that the > >> CABForum's Baseline Requirements

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

> All the linters will give an error about that, see for instance: > https://crt.sh/?id=1009623020=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

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

On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote: > On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote: >> 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

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

On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote: > 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

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

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

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

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 wrote: > Dear All, > > JFYI. Via Feisti Duck nerwsletter. > > >

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

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 > wrote: > > I am really surprised how the

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

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

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

On Thu, Dec 6, 2018 at 3:30 PM Viktor Dukhovni wrote: > > On Dec 6, 2018, at 4:08 PM, Andrei Popov 40microsoft@dmarc.ietf.org> wrote: > > > > Widespread deployment of draft-dkg-tls-reject-static-dh-01 and failing > connections to "enterprise TLS" servers would probably qualify as >

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

On Fri, Dec 07, 2018 at 12:04:02AM +, Andrei Popov wrote: > > 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. Yes. What we can, and IMO should do, is say that if you must

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

> 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 ___ TLS mailing list TLS@ietf.org

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

On Thu 2018-12-06 21:08:00 +, 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

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

> On Dec 6, 2018, at 4:08 PM, Andrei Popov > 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 don't think the TLS WG or IETF can win

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

On Thu, Dec 6, 2018 at 12:33 PM Daniel Kahn Gillmor wrote: > 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

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

On Thu 2018-12-06 02:10:06 +, 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. hm, thinking about this optimization approach, i would really like to know what implementations are doing this. It

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

Hi Andrei-- On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote: > 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

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

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

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

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

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

On Wed, Dec 5, 2018 at 8:28 AM Salz, Rich wrote: > > 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 >

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

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.  

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

* 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

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

>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. Ooh, good catch.

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

On Wed, Dec 5, 2018 at 12:09 AM 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

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

On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote: >> On Dec 5, 2018, at 7:33 PM, Stephen Farrell >> wrote: >>> 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

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

Comments inline Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Dec 5, 2018, at 7:33 PM, Stephen Farrell wrote: > > > >> 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

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

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

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

> The WG is chartered to make TLS a fast, secure, confidential transport > layer. Let's keep the charter goals in mind. > >--dkg + 1 ___ 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

On Wed 2018-12-05 17:08:44 +0900, 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

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

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

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

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,

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

On Sat 2018-12-01 10:02:44 -0800, Christian Huitema wrote: > 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. This certainly looks like a case of

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

On Tue, Dec 04, 2018 at 05:39:30PM +0100, Jonathan Hoyland wrote: > Isn't there a lower bar at the IETF for defining new cipher suites, as long > as you're not seeking a "recommended" setting? Yes, but then you have to get interoperability using them, which means patching clients and servers.

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

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.

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

On Sun, Dec 2, 2018 at 3:36 PM Nico Williams 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 >

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

On Tue, Dec 04, 2018 at 04:34:08PM +0100, Jonathan Hoyland wrote: > 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 >

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

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

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

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

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

On Sat, Dec 01, 2018 at 07:59:45AM -0800, 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

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

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 wrote: > > >> On 12/1/2018 11:14 AM, Tony Rutkowski wrote: >> >> The eTLS use case is an enterprise

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

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

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

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

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

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

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

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

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

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

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

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