Re: [apps-discuss] [dane]

[Martin Rex <[e-mail]>]

Ned Freed wrote:
> 
> > Updates: should only be used if the change is supposed to apply not only
> > to implementations of the *new* document, but that all new implementors of
> > the *old* (=updated) document should ignore certain parts of the old
> > document and use the new document instead.
> 
> Which is exactly the sense in which it is being used here. Although
> I think it unlikely given how limited DANE is, it is nevertheless
> possible that some subsequent use of TLSA will require tweaking of
> something in the DANE specification. We're not omnipotent and we
> don't always get every detail right.

Just the opposite.

Quite similar to rfc6125, DANE-protocol assumes that you already have a
trustworthy hostname for which to retrieve the certificate association.
This way, DANE-protocol can be put into a black block module for the
caller and does not need to be updated or changed depending on the
usage scenario.  It would even be possible to tunnel the TLSA+DNSSEC
records for performing DANE-protocol through a TLS extension instead
of looking it up in a combined TLS+DANE module in a fashion that is
completely opaque to the application caller.

What some of the app specs (other than HTTPS) may have to specify _and_
implement, in order to be able to use DANE, is how to securely obtain
a hostname&port which can be used as input to an implementation of
DANE-protocol or input to rfc6125 matching for PKIX-based matching
to DV-validated server certificates.

But such an apps-specific spec is _not_ an update to DANE itself,
in spite of refering to DANE.  It is irrelevant to the DANE software module.

New TLS cipher suites usually do not update or change TLS, new crypto
algorithms usually do not update or change PKIX, new mime-types ususally
do not update HTTP or the internet message format.


> 
> >   - retaining full interop with old implementations based on only
> >     the full spec, and clear distinction of features that were
> >     added or dropped in the updated parts.
> 
> This, OTOH, is unduly constraining.

Not at all.  Maybe you're misreading this.  It says that anything that
claims to update an earlier document must explain where and how it does
that, an in particular outline omissions and mark additions as such,
so that it will be clear to the reader of the document.

Example:  http://tools.ietf.org/html/rfc5321#section-1.2


-Martin