On Wed, Jul 23, 2014 at 03:42:28PM -0400, James Cloos wrote:
> Thinking about 7250, I'm becoming convinced that we should recommend
> that anyone publishing TLSA, whose software might have or gain support
> for 7250, or might be accessed by clients which can support 7250, SHOULD
> publish a 31x for them, in addition to any non-31x tlsa they publish.
That is, publish "DANE-EE(3) SPKI(1) ? {blob}" associations for
the public keys in any extant certificates, so as to allow the
corresponding bare public keys to be used without the surrounding
X.509 baggage later. If the protocol is in fact TLS (in which case
the full keys are exchanged in-band), the matching type SHOULD
typically be a digest, though for some algorithms (say EC curve
25519 keys), the key size is comparable to the size of its SHA2-256
digest.
However, once "3 1 x" records are published, there is little point
in publishing any other type of record. So I am not sure about
the "in addition to" bit. Rather I would suggest "instead of".
> Ie, those who prefer 0, 1 or 2 should publish both, for the benefit of
> any 7250 clients which might access them.
The cost of publishing "3 1 x" is that the server operator needs to
update DNS when keys change, while with DANE-TA(2), a CNAME to the
TA TLSA record can be published for each service, and the task
of DNS updates is left to the organization's TA administrator.
Once the cost burden (on each server operator) of updating "3 1 x"
records is present already, also publishing "2 1 X" just makes
things needlessly complex. There is no point.
> Thoughts?
I think that in most cases DANE users will publish either "3 1 X"
or "3 0 X". With 7250 in mind, they should be encouraged to
publish "3 1 X" and avoid "3 0 X".
> I also remain conviced that, per liberal in what you accept, any 7250
> client should accept a 11x just as though it were a 31x, since the
> association data is identical.
This is what Postfix does, but is not what the SMTP draft says.
I was dissuaded from formalizing such creative interpretation of
TLSA RRs. If the publisher wants PKIX then the service should not
agree to RPK (raw public keys) use and the client should be free
to either do PKIX or treat the record as unusable, or at least
that's all the server operator can expect. Clients might be more
lenient, but no standard will require them to do it.
If the group believes that Postel's rule applies here, and that
non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as
DANE-EE(3), then we SHOULD add that to the text the OPS draft, and
update the SMTP draft accordingly.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
