Re: [TLS] ESNIKeys over complex

[Eric Rescorla <[e-mail]>]

On Tue, Nov 20, 2018 at 4:36 PM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 20/11/2018 23:30, Eric Rescorla wrote:
> > On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell <
> [e-mail]>
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> I've started to try code up an openssl version of this. [1]
> >> (Don't be scared though, it'll likely be taken over by a
> >> student in the new year:-)
> >>
> >
> > Thanks for your comments. Responses below.
>
> Ditto.
>
> >
> >>From doing that I think the ESNIKeys structure is too
> >> complicated and could do with a bunch of changes. The ones
> >> I'd argue for would be:
> >>
> >> - use a new RR, not TXT
> >>
> >
> > This is likely to happen.
> >
> > - have values of ESNIKey each only encode a single option
> >>   (so no lists at all) since >1 value needs to be supported
> >>   at the DNS level anyway
> >>    - that'd mean exactly one ciphersuite
> >>    - exactly one key share
> >>
> >
> > I don't agree with this. It is going to lead to a lot of redundancy
> because
> > many
> > servers will support >1 cipher suite with the same key share. Moreover,
> from
> > an implementation perspective, supporting >1 RR would be quite a bit more
> > work.
>
> Aren't DNS answers RRsets? I may be wrong but I thought DNS
> clients have to handle that anyway,


Not really, because any of them is co-valid. We currently permit >1 RR, but
actually
I suspect that it would be better to try to restrict this. This would be
especially
true if we get rid of expiry, because then there would be no good reason to
have
>1 ESNIKeys record with a given version.


and I'd expect use of
> RRsets to be a part of figuring out a multi-CDN stpry.
>

That's not at all obvious.


> That said, >1 ciphersuite wouldn't be so bad if that were
> the only list per RData instance. Or maybe one could get
> rid of it entirely via some conditional link the to set
> of suites in the CH, not sure. (Or just go fully experimental
> and say everyone doing esni for now has to use the same
> suite all the time.)
>

I've implemented this and did not find it to be a major obstacle.
I do not think unnecessary duplication is a good tradeoff for
such a trivial implementation complexity reduction.


>    - no extensions (make an even newer RR or version-bump:-)
> >>
> >
> > Again, not a fan of this. It leads to redundancy.
>
> That's reasonable. OTOH, it's equally reasonable to say that
> we're dealing with an experimental draft and a future PS
> version could use another RRytpe and add extensions if they
> end up needed.
>

I don't see any advantage to choosing a suboptimal design, just
based on it being Experimental.

Incidentally, there seems to be some uncertainty about the status.
I'm not quite sure why this is marked Experimental (I think it may
have just been a thinko on my part), and the chairs didn't
ask at call for acceptance time, so I'd encourage them to sort that
out.




> >
> >
> > - get rid of not_before/not_after - I don't believe those
> >>   are useful given TTLs and they'll just lead to failures
> >>
> >
> > I'm mostly ambivalent on this, but on balance, I think these are useful,
> > as they are not tied to potentially fragile DNS TTLs.
>
> If there were a justification offered for 'em I'd be
> ok with it, but TBH, I'm not seeing it. And my main
> experience of the similar dates on RRSIGs are that they
> just break things and don't help.


This has a totally different expiry behavior from RRSIGs, so I'm
not sure that's that useful an analogy.



> Put another way, I
> don't know what sensible code to write to decide between
> not connecting or sending SNI in clear if one of these
> dates is out of whack. (I be tempted to just ignore the
> time constraints and try send the SNI encrypted instead.)
>

You should connect with SNI in the clear.


And having to deploy a cron job equivalent for the DNS
> data is an order of magnitude harder than not.
>

Nothing stops you having an infinite expiry.

>
> >
> > - get rid of padded_length - just say everyone must
> >>   always use the max (260?) -
> >
> >
> > I'm not in favor of this. The CH is big enough as it is, and this has a
> > pretty big impact on that, especially for QUIC. There are plenty of
> > scenarios where the upper  limit is known and << 160.
>
> True, big CH's are a bit naff, but my (perhaps wrong)
> assumption was that nobody cared since the F5 bug.


This has nothing to do with the F5 bug. It's about not exceeding one
packet in the QUIC CH.


It
> seems a bit wrong though to have every domain that's
> behind the same front have to publish this.


They also have to publish the key, so I don't really see a problem.


I'm also
> not sure it'll work well if we ever end up with cases
> where domains A and B both use fronts/CDNs x and y and
> can't figure out a good value as x prefers 132 and y
> prefers 260.
>

They will also use different keys for x and y, so they will
have different records and can have different pad lengghts.


How about rounding up to the nearest power of 2 that's
> bigger than 5? (Or some such.)


I don't know what this means.



> > that needs to be the same
> >>   for all encrypted sni values anyway so depending on
> >>   'em all to co-ordinate the same value in DNS seems
> >>   fragile
> >>
> >
> > It only has to be the same for all the ones in the anonymity set, and
> they
> > already need to coordinate on the key.
>
> Saying that every key share in DNS needs to be published
> with the same padded_length would be ok actually.


Sure, I can make that explicit.

(As a
> nasty hack, you could even derive the padded_length
> from the value of the key_share and fronters could just
> keep generating shares until they get one that works:-)
>

I thought you were complaining about complexity

-Ekr


> > - I'm not convinced the checksum is useful, but it's not
> >>   hard to handle
> >> - (Possibly) drop the base64 encoding, make it DNS operator
> >>   friendly text (or else binary with a zonefile text format
> >>   defined in addition)
> >>
> >
> > We are likely to drop the base64 encoding.
>
> Ack.
>
> And just to note again - I suspect a bunch of the above would
> be better sorted out as ancillary changes once a multi-CDN
> proposal is figured out.
>
> Cheers,
> S.
>
> >
> > -Ekr
> >
> >
> >
> >> [1] https://github.com/sftcd/openssl/tree/master/esnistuff
> >> _______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >
>