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

[Viktor Dukhovni <[e-mail]>]

On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote:

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

Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT,
and I am a maintainer of both the TLS features in Postfix, and the
X.509 code in OpenSSL, I expect to add support for DANE chain in
OpenSSL and Postfix in 2019.  Next on the list would be Dovecot and
mutt, but it'd be nice if that was done by one of the primary
maintainers of those packages.

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

Any broken clients will get fixed.  The client that motivated this
draft is purported to require the extension, and the others will
take some time to appear, highly likely not until the follow-on
spec is written.  The odds of real problems here are negligible.

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

There's no need for nested extensions, they serve no purpose.  If DANE
chain STS is in a separate extension, it may as well be top-level.

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

At much too much complexity, unless we fork-lift this extension
plus the additional payload, and largely obsolete this draft.  Using
one extension to pin itself and another is much too cumbersome.

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

That is, to address the security gap highlighted in the upcoming
more complete security considerations.  s/pinning/DANE chain STS/

-- 
	Viktor.