On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote: > Thanks for producing some text. I understand why one might think that > having a reserved 16-bit field is useful here, but I don't really > agree. > > The conventional reason to reserve this kind of field is that you need > to leave space for an extension in some PDU, because it's hard to add > later. But that's not true here (or in TLS in general) because we
-07 has text on pinning. There is no consensus on making that work _now_. There is only consensus on removing that text and revisiting pinning later. Well, later we will need these two bytes. So there's the conventional reason to reserve this kind of field: because we know we will need it, and adding it via some extension facility will be harder than... already having it. And yes, we (the IETF) do use reserved fields even in protocols where there is extensibility. > already have an extension mechanism (indeed, the one that's being used > by this specification). If we end up having consensus to do pinning, > then it's straightforward to define a new TLS extension that provides > it. Having these two bytes now will mean that they are always present, which will make it a lot easier for implementations to a) start sending non-zero values, b) start handling non-zero values, once we write a spec on what non-zero values mean. (And we know what that spec will say, which is why we know we need two bytes.) > If you look at HPKP and Expect-CT, you will note that there are a > [...] HPKP is completely different. The idea here is NOT to pin key material, CAs, or anything of the sort. The idea here is to pin only the use of this extension, and this does not even bind one to use DANE because the extension can carry a denial of existence. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
