Re: [TLS] Draft updates: tls-dnssec-chain

[Shumon Huque <[e-mail]>]

On Sat, Apr 28, 2018 at 2:17 PM, Richard Barnes <[e-mail]> wrote:
>
>
> On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni <[e-mail]>
> wrote:
>
>>
>>
>> > On Apr 28, 2018, at 12:19 PM, Shumon Huque <[e-mail]> wrote:
>> >
>> >    This specification can also be used to optionally convey
>> >    authenticated denial of existence of TLSA records.  Restrictive uses
>> >    that might require such proofs (such as the PKIX constraining modes
>> >    of DANE, or where DANE should always be preferred over other modes of
>> >    authentication such as traditional PKIX) are thus not in its intended
>> >    scope.  Such restrictive uses can however be supported
>> >    opportunistically.
>>
>> The last sentence makes no sense.  The term "Restrictive uses" is poorly
>> defined.  The reduction in scope is effectively a reduction to just the
>> cases where the extension is mandatory, if that's what you intend to do
>> then say so (expect pushback).
>>
>
Yeah, I agree the assertive and restrictive terms are poorly defined. I was
using terminology that this WG has been using for a while, but we can
reword.


>
>> Please do not imply that any non-mandatory "additive" use-cases are
>> viable.  They are not.
>>
>
> I agree with Viktor here.
>
> You could imagine enforcing a restriction you see in a DANE extension the
> cert you get milliseconds later, but that's pretty useless given that an
> attacker can just not send the extension.  Let's just scope this to the
> additive case.
>
>
This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes
the latter case, I assume based on his (unproven) assertion that there will
no
incentive to deploy this. I don't agree. Lots of sites already publish DANE
for
HTTPS records even before browsers can use them (IETF, freebsd, debian,
torproject, defcon, ripe, etc). Once code is implemented/deployed they will
be
using it.

Shumon.