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

[Eric Rescorla <[e-mail]>]

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

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

It would be nice to hear from those maintainers, as well as from some of
the bigger email senders (e.g., GMail, Yahoo Mail, etc.)


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

It has not been my experience or, I think, that of the WG, that this is the
case. Rather, once there is a significant fielded population of intolerant
endpoints, generating the offending PDU causes too much breakage and
instead you have to send something which doesn't break those endpoints. cf.
the padding extension, supported_versions, and the CCS hack.


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

Yes, I appreciate that this is your opinion.

-Ekr