On Thu, Apr 26, 2018 at 11:13 AM, Nico Williams <n...@cryptonector.com> wrote:
> 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. > [citation-needed] All the instances of "reserved" I can think of are either due to bit alignment or blocking off old stuff. --Richard > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
