On Wed, Jul 04, 2018 at 08:42:38PM -0700, Eric Rescorla wrote:
> 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.)
The question is premature, some implementations are not candidate
early adopters. Once library support is there, and there are
some early adopters deployed, then the others follow.
Postfix implemented DANE in 2014, a bunch additional MTAs added
support in 2017 and 2018, and I expect more in 2019.
> > 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.
Yes, that's true with major TLS revisions. This extension, however,
will not see such rapid uptake that sloppy early versions will need
to be revised. You're on the one hand questioning whether any
adoption will take place at all, and on the other concerned that
early adopters will be intolerant of non-sentinel values of the
proposed reserved field. Your first concern is closer to the mark.
While I'd like to have the second problem, the reality is that for
the first couple of years the number of implementations will be
rather small, and the specification of the reserved field can and
should predate the bulk of the follow-up implementations.
> 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.
Sure, but "significan fielded population" is not a problem we'll
be having here for some time. This is a space where uptake will
be slow, and the early adopters will be well aware of the requirements.
By the time the late adopters arrive, we'll have the downgrade
protection fully specified.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
