Re: [TLS] DNS-based Encrypted SNI

[Stephen Farrell <[e-mail]>]

Hiya,

Just on this bit...

On 04/07/18 18:20, Eric Rescorla wrote:
> The structure started a bit simpler and got new features to
> deal with new issues. Specifically:
> 
> - The checksum is intended to deal with corruption

I'm not sure I see why that's needed, but I believe you if
you say it might help with some home routers. (Though I'd
also be interested in information/citation about the
details of the problems seen there.)

> - The keys and cipher suites seem kind of mandatory

Yep. OTOH, given we need to support >1 value for the RR, if
mostly people just need one key+CS per-RR, it may be possible
to use multiple RRs to provide additional keys/CSes. (If most
uses would have a variable number of keys/CSes then I agree
the current structure is better.)

> - The padded length is needed to tell the client how much to
>   pad. Though I guess we could always pad to 260. If you don't
>   pad at all, it doesn't work.

Sure.

> - I think it's clear what not_before and not_after are for. If you have
>   more concrete feedback about better ways to do that, we'd welcome
>   this.

With not_before/not_after (and the TTL) there'll need to be some
consideration of the various overlaps, which has been a source of
bugs and ops screw-ups in other scenarios. I also don't like the
forced expiry of not_after - people will just put in 2038 all over,
or risk weird breakage. (X.509's mandatory notAfter was IMO an
error for most uses of X.509 - an error inherited from the X.500
DAP user authentication use-case that initially motivated X.509.)

I wonder would an incrementing counter (like SOA serial) maybe be
easier where the client just uses the highest value? (There was
some discussion on related topics during the work on MTA-STS, but
I forget the details, might be worth checking with the folks
involved.)

> - Extensions is just there because we're trying to be safe.

Sure, but I hope we consider dropping 'em if there's no need.
New RRTYPEs could always be used for extensions (if new RRTYPEs
are cheap, that is:-)

> 
> FWIW, this actually is pretty friendly because we b64-encode
> (thus making the internal structure opaque to DNS). Removing
> things won't make it much smaller because a big chunk of
> the data is in the keys. For instance, in my implementation,
> the object is 70 bytes long and 34 bytes of that is key (X25519)
> and 8 bytes is cipher suite (each of these has 2 bytes of length).

That's good. But I was more thinking about how friendly this
would be for the DNS admin folks. One thing I like about TLSA
and CAA is that (for my use-cases:-) I can just cut'n'paste
the values into zone files and they'll be good until a CA root
key or name changes, which is pretty rare and would be widely
advertised ahead of time.

With RRSIGs and similar, I can also easily inspect values by
just looking at zonefiles and/or using dig, which is helpful
for me at least. But I don't have to deal with large zones so
that kind of inspection may not be of much use to larger
operators. So, I'd defer to real DNS server folks on whether
or not being able to directly view the internals of ESNIKeys
encoding makes any difference.

All that said, I did just suggest adding in the dummy sni
value:-) So I mostly think if this goes ahead (as I hope it
does), we spend a bit of time considering the above issues
before we're done.

Cheers,
S.