Re: [TLS] DNS-based Encrypted SNI

[Eric Rescorla <[e-mail]>]

On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell <[e-mail]>
wrote:

>
> 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.)
>

Sure. that's a fair question. Kazuho proposed this, so I'd be interested in
his view.

>
> > - 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.)
>

I think it's bad to provide multiple options that aren't coupled together.
Moreover, from the perspective of the TLS stack, it's actually easier
to have them all bundled.



> - 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,
>

Note that this is 64 bits, so you can go far past 2038 :)


> - 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:-)
>

I would not be in favor of this. It's trivial to parse and ignore.


> (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.
>

Sure, that seems reasonable. I think you are getting to something
important here: my philosophy here is that this should be a more
or less opaque blob which you provide to the TLS stack. So I'm
optimizing for what's convenient for that. I can understand that
others might feel differently.

-Ekr


> Cheers,
> S.
>
>