Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Eric Rescorla <[e-mail]>]

On Wed, Jul 4, 2018 at 7:33 PM, Viktor Dukhovni <[e-mail]>
wrote:

> 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"?


Well, we could start with "what implementations are going to do this"?


> 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.
>

Yes, and this is where grease comes in. Specifically, if implementations
are required to send empty values (or zero) until something is specified,
then implementations which *require* those values and choke otherwise go
undetected. By contrast, if we have a structured Extension code point with
requirements to ignore unknown extensions, then implementations can send
grease extension values and verify that the peer properly ignores them. In
any case, as Martin Thomson says, we have a perfectly good extension
mechanism which can be used to add pinning later without creating any
placeholder here.

I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished.


Well, I'm not an author, so I'm the wrong person to be addressing this to.


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.
>

That would first require there being consensus to do pinning.

-Ekr