On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:
> > 1. Do you support the working group taking on future work on a pinning
> > mechanism (based on the modifications or another approach)?
>
> Unsure. I'd like to see some real evidence that it will be widely consumed.
> Do we have a count of major implementors who say they will do so?
Well, what is a "major implementation"? TLS is not just browsers,
and adoption does not always begin the day the RFC is published.
DANE adoption only started 2+ years after RFC6698, and is still
ramping up. The important thing here is to not *preclude* adoption
by needlessly limiting the scope to just "greenfield" applications.
It is rather clear that the present draft is only compatible with
applications that mandate the extension. Some form of "STS-lite"
pinning is needed to support incremental adoption by existing
applications.
> 2. Do you support the reserved bytes in the revision for a future pinning
> > mechanism?
>
> No. I'm undecided on whether we should have an extension point here, but
> I'm strongly against having it just be opaque reserved bytes. Everywhere
> else we have decided to put extension points, we've had them as Extensions,
> not just "here are some bytes". Aside from this being general TLS
> practice, it is good futureproofing because one can grease Extensions,
> whereas you cannot grease opaque bytes.
It is far from clear why "grease" is applicable here, or what "grease
barriers" either proposed form of the reserved field presents.
* With the 16-bit field, servers set it to zero until non-zero
values are specified.
* With the <0..255> byte value, servers send an empty value
until non-empty values are specified.
* In either case clients ignore either non-zero or non-empty
values, until they implement the specification, and must not
employ pinning until such time.
I thought the authors wanted this done quickly, but lately they
seem to be in no rush to get the document finished. If we're no
longer in a hurry to get this out the door before all the issues
are sorted out, we can specify the downgrade protection now, in
which case there's no need for reserved fields, we can define the
pinning approach now.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
