[ech] looking for comments on my current APIs for ECH

[Stephen Farrell]

Hiya,

Thanks for the comments!

On 19/12/2022 23:19, Kurt Roeckx wrote:
> Hi,
> 
> I think your use of the word session probably confusing, because I think
> about an SSL_SESSION *, while I think you're talking abuot an SSL *.
> Maybe connection is a better word?

Yeah, I'm never sure what the right terminology is for an
``SSL *`` thing - if it's "connection" then great and happy
to use that throughout.

> Not having read the draft, is it normal to have multiple public keys as
> client? 

It's allowed. Too early to tell if it'll be normal or not but
best guess for now is it'll be uncommon. I suspect clients
will see >1 public value for servers that use >1 CDN (or are
migrating between CDNs).

More fully: the client will likely read an HTTPS RR, which
like any DNS RR can be multi-valued. And each RR value can
contain an ECHConfigList that has >1 public key. (I did argue
that was over complex a couple of years ago in the IETF WG
but lost that argument.)

> Does that mean you encrypt to all the public keys? 

No. The client picks one then uses HPKE for the ECH crypto,

> I would
> expect the client to only have 1, but the server to support multiple.

The server will support multiple generations of key pair but
only one (the current) public key needs to be visible to
clients at a time. (Can be >1 generation that's visible but
that's not necessary.)

> I currently fail to see the related OSSL_ECH_INFO and SSL_ech_reduce()
> and don't see why we need something like that.

Practically, it'd allow a client that cares to pick which of
the server's CDNs to use as the public_name/outer-sni (and
probably also the server IP address to use). But without
some way to down-select, the client would be sort of at the
whim of the order in which DNS responses are presented, which
seemed a bit wrong.

There's also a very niche use-case for this when checking a
set of >1 public value is supported at a server before
publishing the HTTPS RR. [1] (I don't currently do the
selection part of that via the library though - I do it via
bash scripting at the moment, but one could implement the
"zone factory" part of [1] using those APIs.)

> I'm not sure it's a good idea to support an API that says to read all
> files in a directory matching *.ech.

I can understand that. Reason I did it was to make it easier
for servers to just re-load all relevant keys with one call
at the application layer. (I think there was some reason why
that was easier with nginx but I'd have to go delve to be
sure.)

Using a directory means a key manager can just drop the right
files for the server into that directory and then trigger a
reload or restart.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/

> 
> 
> Kurt
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x5AB2FAF17B172BEA.asc
Type: application/pgp-keys
Size: 5564 bytes
Desc: OpenPGP public key
URL: <https://mta.openssl.org/pipermail/ech/attachments/20221219/ac10e61f/attachment-0001.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/ech/attachments/20221219/ac10e61f/attachment-0001.sig>