> On May 16, 2018, at 1:18 AM, Melinda Shore <melinda.sh...@nomountain.net>
> wrote:
>
> Your proposal has been discussed
> at length on the list, it's been discussed at length off the list,
> and there is still no consensus to modify the extension to support
> your use case.
You say that, but there are ~5 people on each side
woh've expressed an opinion on pinning one way or the other.
And the original consensus call did not even esk the question
at hand. Rather it was whether to specify pinning or not.
Not whether to reserve space to do so later. Subsequent
discussion has been the same echo chamber of Eric, Rirhard
and you on the one hand, and Paul, Nico and I on the other.
Perhaps at this point we might actually hear from some others.
> And as a reminder, "Rough consensus is achieved
> when all issues are addressed, but not necessarily accommodated."
Here I agree, but things like unaddressed downgrade attacks are
also a factor that is supposed to tilt the scales.
> On 5/15/18 8:22 PM, Viktor Dukhovni wrote:
>> It just leaves
>> the door open going forward, at negligible cost (two bytes on the
>> wire in bandwidth, and zero in implementation).
>
> I would be grateful if you would have a consistent story on this.
> Clearly, it's not just two bytes, or there wouldn't be a perceived
> need for them. It's two bytes plus the associated semantics and
> processing algorithms. In the event that anybody has an interest
> in implementing something along these lines the offer to work on
> an extension to support it still stands.
The story is quite consistent. Applications that have no need
for pinning pay no cost as claimed. Applications that need it,
can't use the present specification at all, but would be able
to at the cost of storing the pins, and requiring the extension
when pinned. Nobody pays an extra cost they could otherwise
avoid.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
