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 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
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Thoughts on draft-rescorla-tls13-semistatic-dh-00
Dear all, I read the draft and have a few comments. First off it seems like OPTLS used an HKDF extracted key to feed into the content keys, instead of reusing the shared secret. I'm pretty sure that will end up not mattering, but I'm by no means an expert in how much some change like that will affect the analysis. Secondly there is the question of performance. A fixed based exponentiation can almost always be done faster then a variable base exponentiation because it offers precomputation. As specified a server does one fixed based exponentiation and two variable based exponentiations, while with signatures a server does two fixed based exponentiations and one variable base exponentiation. The performance gains possible from OPTLS come from reuse of the ephemeral, resulting in just two variable base exponentiations for most clients, unless there is a very fast choice of group that doesn't support signatures out there. The given example of x25519 vs. P256 could be solved with issuing an Ed25519 delegated credential for instance. Clients will see a performance gain if the total number of signature verifications goes down as two variable base exponentiations are cheaper then a verification plus variable base exponentiation, but that depends on not using delegated credentials. Perhaps more interesting is the question of postquantum schemes that don't support signatures. But there a classical signature usually outperforms a postquantum key exchange, and so it is not very interesting to do two postquantum key exchanges instead of one and a classical signature. As for client authentication I think the server ephemeral+client static producing a key they use to MAC works out: it's no worse for mixing the client secret in then the signature based client authentication is in TLS. Sincerely, Watson Ladd ___ 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 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. You can't 100% escrow this way. Nico -- ___ 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
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 On Tue, 4 Dec 2018 at 16:19 Tony Arcieri wrote: > 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 >> > 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 > 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] 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 > > 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 > 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. 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.) > *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. 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 -- ___ 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
* 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. ___ 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
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 wrote:
> 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 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.
>
> 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
> --
>
> ___
> 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
