> On Apr 10, 2018, at 8:17 PM, Melinda Shore <melinda.sh...@nomountain.net>
> wrote:
>
> There's an unfortunate number of IETF protocols that
> people worked on for years and that never saw implementation, and
> it seems to me that we ought to be trying to minimize the chances
> of that happening with the protocols we're working on.
Exactly, which is why we need to make sure that the protocol does
not fail to address its natural use-cases. This is a protocol for
stapled DANE in TLS, and many potential applications will run in
mixed WebPKI + DANE environments and will need to be able to do
DANE *when possible*, in a downgrade-resistant manner (in this case
after first contact).
> I haven't seen
> anything in this discussion that leads me to believe that the
> extension as specified is fundamentally broken or insecure for its
> intended use.
The intended use in the introduction does not preclude Web browser
HTTPS, JMAP, IMAP, POP, NNTP, SMTP Submission, XMPP, ... with only
statically configured DANE for DPRIV in scope. DPRIV may well be
the application that's ready now, but closing the door on others
is surely unwise.
> I'm good with adding clarifying text or scoping it
> more clearly, but beating this thing to death for a use case that
> nobody intends to implement seems a bit misguided to me.
It is a mistake to confuse lack of immediate adoption plans with
evidence that no such implementations will ever happen, and should
be precluded at the outset.
I had no idea DANE existed (too busy implementing comprehensive
TLS support in Postfix to follow IETF work) when the DANE WG
concluded work on RFC6698. 8 months later Tony Finch brought
DANE to my attention, and I began implementation at that time.
My implementation was the first non-toy implementation of DANE
that got used in real systems.
Was I ready to implement in August of 2012? No. Did I then
never implement? Of course not, indeed we'd not be talking
about DANE at all (it would be dead) if it were not for that
work, and subsequent work to eliminate hurdles in the form of
buggy authoritative servers at some major providers, integration
into OpenSSL, Exim, ...
The arguments against the proposal continue to ignore the
technical issues and focus on perceived delay. If you
really want to avoid delay, let's adopt the changes, and we'll
be done. If there are technical flaws in the cost/benefit
analysis that motivates the changes, please address those
in detail. I see nothing in the draft that justifies limiting
its scope to just a narrow application profile in which DANE
is statically mandated by client policy. That limitation fails
to scale.
Even with DPRIV it should be possible for a server that no
longer has TLSA records to provide a denial of existence proof
(thus at least option (A) from the consensus call message) and
employ PKIX instead (a domain may become unsigned if they change
their mind about implementing DNSSEC). Option (B) supports
incremental adoption, and provides downgrade protection after
first contact, dramatically increasing the applicability.
The changes are small, but needed to not preclude further
implementation work in new application areas. There may not
be implementors right away, but we should leave the door open
for when they are.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
