On Mon, 2 Jul 2018, Eric Rescorla wrote:
It is strongly recommended not to use TXT records. Why not use a new
RRTYPE? Everything these days knows how to serve unknown record types
(see RFC 3597). The only possibly exception is provisioning tools of
small players, but this document starts of saying you basically need
to be on a bulk hosting provider anyway. They can properly provision.
See:
https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906
[Can we keep the discussion within the IETF and the Note Well please. We
also don't know what happens in 10 years with these links.]
quoting from that link:
These facts lead to the conclusion that if we choose RRtype as the
method, there would often be cases where the DNS record of the ESNIKey
and the TLS server would be required to be operated by different
entities.
That seems to have confused two things with each other. I did not say
anything about the location of the DNS record, only of the RRTYPE.
Clearly, with the same location, it would be under control of the same
entity, so I don't understand why you bring this up as a reason against
using a dedicated RRTYPE.
Here is another argument against it, besides the generic IETF policy of
trying to not overload things or create kitchen sinks. If you used, or
were forced to use, a DNS under control of someone who can block things,
they might be instructed to block anything related to encrypted SNI,
and they might decide to just block all TXT records, even unrelated
ones, resulting in collateral damage.
Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
