Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

2018-03-23 Thread Benjamin Kaduk
On Thu, Mar 22, 2018 at 12:53:22PM +, Salz, Rich wrote: > I am inclined to agree with Peter. It doesn't quite seem like a registry if > the very first time there is a list of things in it, that list is now frozen. > > Why are we closing/reserving all the bits? Huh? These are for the old TL

Re: [TLS] Additional changes for draft-ietf-tls-iana-registry-updates

2018-03-23 Thread Salz, Rich
So we have two registries that share a number space. Sounds like the right solution is for the registries to coordinate. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] (crypto agility may benefit from private extensions) Re: Additional changes for draft-ietf-tls-iana-registry-updates

2018-03-23 Thread Alex C
I'm hesitant to call a 16-bit registry "big" in any context. But if allocating a value requires a specification, that's probably okay. (There aren't even close to 2^16 RFCs in total) On Wed, Mar 21, 2018 at 3:54 AM, Eric Rescorla wrote: > > > On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik > wrote

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

2018-03-23 Thread Alex C
As I understand it (poorly!) the idea is exactly to have a single system on the network that monitors all traffic in cleartext. It's fundamentally impossible to prevent someone from copying all their traffic to another system in cleartext. If they're going to do it, they will. The functionality is