Subject: [TLS] ESNI PEM files

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Oct 2019 11:55:01 +0100

Hiya,

To date, my ESNI code [1] has been dealing with files containing
the binary encoding of ESNIKeys and a separate PEM file containing
the related private key.

As part of getting nginx to work with ESNI [2], it'd be easier
for me to deal with a single file containing both private key
and the ESNIKeys (or ESNIConfig) value. (One of the upstream
maintainers didn't like how I handled configuring ESNI, so the
change is really to make him happier, but I think it's likely
a generally useful thing:-)

Since mixing binary and PEM encoding in one file would be ickky,
it'd be nice if we had a PEM file convention for the public keys
used in ESNI. And of course, it'd be much nicer if everyone did
the same thing here.

What I'm coding up now would handle files like:

"
-----BEGIN ESNIKEY-----
/wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j
/gAAAABc995+AAA=
-----END ENSIKEY-----
"

...where the content is (unsurprisingly:-) a base64 encoded ESNIKeys.

And if both the private and public components are in one file,
it'd look like:

"
----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va
-----END PRIVATE KEY-----
-----BEGIN ESNIKEY-----
/wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j
/gAAAABc995+AAA=
-----END ENSIKEY-----
"

I'd be happy to change that however increases the probability
that other code bases do the same thing.

If this is useful, I could do up a PR with a bit of text saying
to use "ESNIKEY" (or whatever) as the label when storing these
things in PEM files. Given RFC7468 documents other PEM file
things, it seems reasonable to do the same for ESNI.

Cheers,
S.

[1] https://github.com/sftcd/openssl/tree/master/esnistuff
[2] https://github.com/sftcd/nginx

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Oct 2019 12:25:35 +0000

Is the private key PKCS8?  If not, then perhaps "ESNI PRIVATE KEY" is better.

Overall, yes, plus-one.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Oct 2019 13:51:32 +0100

Hiya,

On 25/10/2019 13:25, Salz, Rich wrote:
> Is the private key PKCS8?  

Eh... not sure and didn't ever look:-)

It's what I got from PEM_write_PrivateKey()

But now that I do look, yep it's a PKCS8 PrivateKey.

Cheers,
S.

> If not, then perhaps "ESNI PRIVATE KEY" is better.
> 
> Overall, yes, plus-one.
>  
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Oct 2019 06:45:28 -0700

Are you suggesting that these strings appear on the wire in DNS? Or is this
just an internal implementation covnenience?

-Ekr

On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Oct 2019 15:03:08 +0100

On 25/10/2019 14:45, Eric Rescorla wrote:
> Are you suggesting that these strings appear on the wire in DNS? 

Nope.

> Or is this

A bit more than that, but yes. I have a (temporary) tool for
generating these files and then need to import the output from
that into e.g. nginx or lighttpd. Some applications support
more than one TLS library, so having a well defined format
seems like it'd help with ESNI deployment.

Basically this is the same logic that lead to pkcs8 PrivateKey
being worth documenting in an RFC.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Oct 2019 07:06:02 -0700

> being worth documenting in an RFC.

OK. I don't think this needs to be documented in this draft, but if you
wanted to write some other draft....

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Oct 2019 15:11:54 +0100

> wanted to write some other draft....

It doesn't *need* to be in draft-ietf-tls-esni, no, but I
figure it'd be better there as implementers would be less
likely to miss it in that case. But, I'm fine starting off
with the small bit of text needed in a new draft if that's
somehow better than a PR.

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Oct 2019 07:46:21 -0700

> somehow better than a PR.

Sorry I wasn't clear: I don't think it belongs in this draft, but I don't
object to you writing up some other draft.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Oct 2019 15:22:17 +0000

I prefer an informative (not- normative) appendix of, like, 3 sentences or so.

This will need all the implementation and operational help it can get, and scattering things across multiple teensy docs is not helpful.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Oct 2019 15:40:22 +0000

Hiya,

On 25/10/2019 16:22, Salz, Rich wrote:
> This will need all the implementation and operational help it can
> get, and scattering things across multiple teensy docs is not
> helpful.
> 

I agree with Rich - if a bunch of TLS server code bases adopt this,
it'd be better as an appendix to the ESNI spec.

However, to help move things along, I submitted [1]. I'm happy to
make sensible changes to that however suits other implementers, but
that's what I've coded up for now.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-farrell-tls-pemesni-00