> On Apr 4, 2018, at 6:12 PM, Melinda Shore <melinda.sh...@nomountain.net>
> wrote:
>
>> I support publication of the document as is. I would also be
>> comfortable with a minor modification to say that TLSA certificate
>> usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism.
>
> The addition of text that clarifies that seems absolutely reasonable
> to me.
That addition is fundamentally flawed. THere is no realistic scalable
adoption model in which a server publishes DANE-only certificates to
and expects thereby to support a meaningful set of clients that would
don't trust Let's Encrypt (for example). Nor do I see the browser
community accepting DANE alone as a sufficient security mechanism.
> I do think there would be a problem with adding additional complexity
Ignoring a 16-bit field in the extension adds ZERO complexity. Not
sending a denial of existence response and not accepting one if
given (in applications that don't need this feature) likewise adds
ZERO complexity. The complexity argument is a mirage.
> to the extension to support functionality that nobody has said that
> they intend to use (including the proponents of the changes), given
> that the changes would not be introduced to correct an error in
> the existing spec.
The changes are needed to support the extension in any application
where adoption is necessarily incremental (i.e. all existing WebPKI
applications). To refute that, one would need to refute the security
and cost-benefit analyses in my post and somehow demonstrate
"alternative facts" that establish the viability of an additive
model, and some other way to compensate for the fact the present
extension has a major downgrade hole.
It is precisely the "restrictive" use-case that Richard says can be
left out that users expect from DANE, that is tangible benefit over
and above just using WebPKI, from say Let's Encrypt.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
