Re: [TLS] [Technical Errata Reported] RFC8446 (5874)
Thanks for letting us know, Andrei. That's rather depressing, but is fairly indicative that the errata report should be verified. (I think I will edit the "Notes" slightly when doing so, but am too tired to do a proper job tonight, so I'm holding off on actually marking the report as verified in the database for now.) -Ben On Fri, Oct 25, 2019 at 06:13:18PM +, Andrei Popov wrote: > My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data > records must still be encrypted and authenticated. Otherwise, MITM can inject > arbitrary numbers of these. > > However, the current language is vague enough that I've seen major SW vendors > send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is > RFC-compliant, because " Zero-length fragments of Application Data MAY be > sent". > > Therefore, I support clarifications in this area. > > Cheers, > > Andrei > > -Original Message- > From: TLS On Behalf Of RFC Errata System > Sent: Friday, October 11, 2019 9:22 PM > To: e...@rtfm.com; r...@cert.org; ka...@mit.edu; c...@heapingbits.net; > j...@salowey.net; sean+i...@sn3rd.com > Cc: lper...@bellaliant.net; tls@ietf.org; rfc-edi...@rfc-editor.org > Subject: [TLS] [Technical Errata Reported] RFC8446 (5874) > > The following errata report has been submitted for RFC8446, "The Transport > Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5874data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889sdata=61wnX96xJGd6FSLbxEQAJNvwERSVAMGoxxvjgb7DuRo%3Dreserved=0 > > -- > Type: Technical > Reported by: Mr Laurie Perrin > > Section: 5.1 > > Original Text > - > > >Application Data messages contain data that is opaque to TLS. >Application Data messages are always protected. Zero-length >fragments of Application Data MAY be sent, as they are potentially >useful as a traffic analysis countermeasure. Application Data >fragments MAY be split across multiple records or coalesced into a >single record. > > Corrected Text > -- > > >Application Data messages contain data that is opaque to TLS. >Application Data messages are always protected. Zero-length >fragments of Application Data (i.e. those encapsulating an >TLSInnerPlaintext record having a content field of length zero) >MAY be sent, as they are potentially useful as a traffic analysis >countermeasure. Application Data fragments MAY be split across >multiple records or coalesced into a single record. > > Notes > - > In the interest of clarity, it may be prudent to specify the type of record > for which a fragment of length zero is being considered - it cannot be that > of the TLSCiphertext itself, for "Application Data messages are always > protected," > therefore I infer this relates to the TLSInnerPlaintext content field (of > length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment. > > Note: This comment also applies to previous versions of the TLS > specification, in particular with the introduction of the respective text > concerning zero-length fragments in RFC 5246. In TLS 1.2, this would be the > GenericXXCipher content field of length "TLSCompressed.length" - i.e. to the > TLSCompressed fragment. > > Note: The implications of zero-length records must be considered with respect > to potential vectors for denial of service. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party can log in to change the status and > edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > TLS mailing list > TLS@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889sdata=khYsCm5Wgkg98VESyOV8pNZCqEhA7EWLQhGE6%2FtOgos%3Dreserved=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Suggestions regarding a few definitions in the ESNI draft
Hi, I filed a few issues on some definitions in the ESNI draft. "Zx = HKDF-Extract(0, Z)" https://github.com/tlswg/draft-ietf-tls-esni/issues/188 "AEAD-Encrypt" https://github.com/tlswg/draft-ietf-tls-esni/issues/189 Given that there are open source implementations to test against, I don't think these issues are critical right now, but they do seem imprecise at least. As the draft firms up, it might be nice to develop some test vectors for each step of each algorithm, so implementors can tell where things go wrong as they're developing. The ESNI process ended up being a lot more involved than I expected (but that is not a criticism). thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] tls - Requested sessions have been scheduled for IETF 106
Dear Christopher Wood, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:00 requested) Thursday, 21 November 2019, Morning Session I 1000-1200 Room Name: Padang size: 300 - tls Session 2 (1:00 requested) Thursday, 21 November 2019, Afternoon Session III 1740-1840 Room Name: Canning size: 250 - iCalendar: https://datatracker.ietf.org/meeting/106/sessions/tls.ics Request Information: - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Christopher Wood Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 120 Conflicts to Avoid: Chair Conflict: pearg git mls emu cacao Technology Overlap: cfrg dprive dnsop lake Key Participant Conflict: quic httpbis taps secdispatch saag People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Yoav Nir Benjamin Kaduk Christopher A. Wood Nick Sullivan Resources Requested: Special Requests: - ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adopting HTTPSVC for ESNI
I have some concerns here that I floated in the bug.
At a high level, ipv[46]hints seems like a regression from the way things
are in ESNI.
-Ekr
On Fri, Oct 25, 2019 at 9:01 AM Tommy Pauly wrote:
> I'm also supportive of this change, and in general of using HTTPSSVC for
> the transmission of ESNI keys, speaking as an implementer at Apple.
>
> With regards to the per-version structure, I agree with Steven that the
> structure of the configuration should be able to change between versions. I
> think that either specifying that the structure can change with versions,
> or just moving the version into the label (Stephen's suggestion) would
> work. I have a *slight* concern for the case of using a different HTTPSSVC
> label for each version or set of extensions, since the code that parses out
> the records may be distinct from the code that uses the keys, and it may be
> easier to fetch the right information out if it has a consistent label
> name. Not a huge issue either way, though.
>
> Thanks,
> Tommy
>
> On Oct 25, 2019, at 7:57 AM, Steven Valdez <
> svaldez=40google@dmarc.ietf.org> wrote:
>
> Chrome is supportive of this change, and will likely work on implementing
> HTTPSSVC into our DNS stack once the draft progresses further.
>
> As for the ESNIKeys/ESNIConfig change, we were actually thinking of
> something that further abstracted HTTPSSVC having to understand anything
> about ESNI from the ESNI versioning:
>
> The ESNIKeys naming was always a bit confusing since you could have
> multiple ESNIKeys, and there wasn't a great way of referring to those.
>
> HTTPSSVC records include a single ESNIBundle which is length prefixed and
> contains one or more ESNIConfigs. (to allow an endpoint to publish multiple
> ESNIConfigs, potentially supporting multiple versions of the ESNI record).
>
> Each ESNIConfig is then just a version and then a version-specific
> structure. (to allow the entire structure of the ESNIConfigInner to
> arbitrarily change at different versions).
>
> Something roughly like the following:
>
> ESNIBundle {
> ESNIConfig<2..2^16-1>;
> };
>
> ESNIConfig {
> version,
> select (version) {
> case 0: {
> opaque public_name<1..2^16-1>;
> KeyShareEntry keys<4..2^16-1>;
> CipherSuite cipher_suites<2..2^16-2>;
> uint16 padded_length;
> Extension extensions<0..2^16-1>;
> }
> }
> };
>
> (alternatively maybe make an ESNIConfigInner and stuff an opaque in
> ESNIConfig that is version-specific, not sure what the right presentation
> looks like)
>
> On Fri, Oct 25, 2019 at 6:29 AM Stephen Farrell
> wrote:
>
>>
>> Hiya,
>>
>> On 25/10/2019 01:28, Christopher Wood wrote:
>> > Hi folks,
>> >
>> > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of
>> > doing the same thing, I've put together a PR that drops the custom
>> > ESNI RRType in favor of this more general (yet feature compatible)
>> > Resource Record:
>> >
>> > https://github.com/tlswg/draft-ietf-tls-esni/pull/187
>> >
>> > Please have a look and comment before next Friday. We'd like to land
>> > this before Singapore.
>>
>> I'm supportive of this change, on the assumption that browsers are
>> really going to use HTTPSSVC.
>>
>> If that lands as-is, please bump the version to ff04 and I don't
>> see much benefit in changing from ESNIKeys to ESNIConfig (seems
>> more likely to confuse than help to me).
>>
>> Going further, I think we ought also take advantage of this to
>> simplify the ESNIKeys/ESNIConfig structure. We don't need to do
>> that right now but we could.
>>
>> There are two related simplifications that'd make sense to me:
>>
>> - remove the version field and encode that in the HTTPSSVC label
>> (so it'd be something like esnikeys05="/wElr6L2ACQAHQ...") - I
>> think that'd lead to fewer cases where HTTPSSVC code needs to
>> understand what's inside the ESNIConfig structure.
>>
>> - similarly, remove the extensions field from ESNIConfig, and
>> require a new label in HTTPSSVC if something new is really needed
>>
>> Cheers,
>> S.
>>
>> >
>> > Best, Chris (no hat)
>> >
>> > [1]
>> >
>> https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s
>>
>> >
>> > ___ TLS mailing list
>> > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>> >
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> --
>
> Steven Valdez | Chrome Privacy Sandbox | sval...@google.com |
> 210-692-4742
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8446 (5874)
My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data records must still be encrypted and authenticated. Otherwise, MITM can inject arbitrary numbers of these. However, the current language is vague enough that I've seen major SW vendors send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is RFC-compliant, because " Zero-length fragments of Application Data MAY be sent". Therefore, I support clarifications in this area. Cheers, Andrei -Original Message- From: TLS On Behalf Of RFC Errata System Sent: Friday, October 11, 2019 9:22 PM To: e...@rtfm.com; r...@cert.org; ka...@mit.edu; c...@heapingbits.net; j...@salowey.net; sean+i...@sn3rd.com Cc: lper...@bellaliant.net; tls@ietf.org; rfc-edi...@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC8446 (5874) The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5874data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889sdata=61wnX96xJGd6FSLbxEQAJNvwERSVAMGoxxvjgb7DuRo%3Dreserved=0 -- Type: Technical Reported by: Mr Laurie Perrin Section: 5.1 Original Text - . Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. Corrected Text -- . Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data (i.e. those encapsulating an TLSInnerPlaintext record having a content field of length zero) MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. Notes - In the interest of clarity, it may be prudent to specify the type of record for which a fragment of length zero is being considered - it cannot be that of the TLSCiphertext itself, for "Application Data messages are always protected," therefore I infer this relates to the TLSInnerPlaintext content field (of length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment. Note: This comment also applies to previous versions of the TLS specification, in particular with the introduction of the respective text concerning zero-length fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment. Note: The implications of zero-length records must be considered with respect to potential vectors for denial of service. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8446 (draft-ietf-tls-tls13-28) -- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date: August 2018 Author(s) : E. Rescorla Category: PROPOSED STANDARD Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889sdata=khYsCm5Wgkg98VESyOV8pNZCqEhA7EWLQhGE6%2FtOgos%3Dreserved=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adopting HTTPSVC for ESNI
I'm also supportive of this change, and in general of using HTTPSSVC for the
transmission of ESNI keys, speaking as an implementer at Apple.
With regards to the per-version structure, I agree with Steven that the
structure of the configuration should be able to change between versions. I
think that either specifying that the structure can change with versions, or
just moving the version into the label (Stephen's suggestion) would work. I
have a *slight* concern for the case of using a different HTTPSSVC label for
each version or set of extensions, since the code that parses out the records
may be distinct from the code that uses the keys, and it may be easier to fetch
the right information out if it has a consistent label name. Not a huge issue
either way, though.
Thanks,
Tommy
> On Oct 25, 2019, at 7:57 AM, Steven Valdez
> wrote:
>
> Chrome is supportive of this change, and will likely work on implementing
> HTTPSSVC into our DNS stack once the draft progresses further.
>
> As for the ESNIKeys/ESNIConfig change, we were actually thinking of something
> that further abstracted HTTPSSVC having to understand anything about ESNI
> from the ESNI versioning:
>
> The ESNIKeys naming was always a bit confusing since you could have multiple
> ESNIKeys, and there wasn't a great way of referring to those.
>
> HTTPSSVC records include a single ESNIBundle which is length prefixed and
> contains one or more ESNIConfigs. (to allow an endpoint to publish multiple
> ESNIConfigs, potentially supporting multiple versions of the ESNI record).
>
> Each ESNIConfig is then just a version and then a version-specific structure.
> (to allow the entire structure of the ESNIConfigInner to arbitrarily change
> at different versions).
>
> Something roughly like the following:
>
> ESNIBundle {
> ESNIConfig<2..2^16-1>;
> };
>
> ESNIConfig {
> version,
> select (version) {
> case 0: {
> opaque public_name<1..2^16-1>;
> KeyShareEntry keys<4..2^16-1>;
> CipherSuite cipher_suites<2..2^16-2>;
> uint16 padded_length;
> Extension extensions<0..2^16-1>;
> }
> }
> };
>
> (alternatively maybe make an ESNIConfigInner and stuff an opaque in
> ESNIConfig that is version-specific, not sure what the right presentation
> looks like)
>
> On Fri, Oct 25, 2019 at 6:29 AM Stephen Farrell > wrote:
>
> Hiya,
>
> On 25/10/2019 01:28, Christopher Wood wrote:
> > Hi folks,
> >
> > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of
> > doing the same thing, I've put together a PR that drops the custom
> > ESNI RRType in favor of this more general (yet feature compatible)
> > Resource Record:
> >
> > https://github.com/tlswg/draft-ietf-tls-esni/pull/187
> >
> >
> > Please have a look and comment before next Friday. We'd like to land
> > this before Singapore.
>
> I'm supportive of this change, on the assumption that browsers are
> really going to use HTTPSSVC.
>
> If that lands as-is, please bump the version to ff04 and I don't
> see much benefit in changing from ESNIKeys to ESNIConfig (seems
> more likely to confuse than help to me).
>
> Going further, I think we ought also take advantage of this to
> simplify the ESNIKeys/ESNIConfig structure. We don't need to do
> that right now but we could.
>
> There are two related simplifications that'd make sense to me:
>
> - remove the version field and encode that in the HTTPSSVC label
> (so it'd be something like esnikeys05="/wElr6L2ACQAHQ...") - I
> think that'd lead to fewer cases where HTTPSSVC code needs to
> understand what's inside the ESNIConfig structure.
>
> - similarly, remove the extensions field from ESNIConfig, and
> require a new label in HTTPSSVC if something new is really needed
>
> Cheers,
> S.
>
> >
> > Best, Chris (no hat)
> >
> > [1]
> > https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s
> >
> >
> > ___ TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> Steven Valdez |Chrome Privacy Sandbox |sval...@google.com
> |210-692-4742
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-esni feedback
On Wed, Oct 23, 2019 at 04:52:57PM -0400, Ben Schwartz wrote: > On Wed, Oct 23, 2019 at 1:11 PM Ilari Liusvaara > > > > Perhaps a simpler way would be to have a flag that causes the first > > label to be overwritten with '*'. That would be set on nodes covered > > by a wildcard certificate. > > This is a reasonable simplification. It would also work nicely > without the hashing, for servers that only have reasonably-sized names > but can't make promises about wildcards. However, it does still > suffer from the configuration brittleness described by David Benjamin > in #186. I think all mechanisms that transmit only a single hash need to know if some node is covered by exact name or a wildcard. And wildcard expansion is at worst 63 bytes, due to DNS limitations, so transmitting full first label and 32 octet hash of rest would take 96 octets (if one can assume host character set, that could be fit into 80 octets with some encoding). Then if one had two hashes, one could fit those to 64 bytes (or 48 if one truncated the hashes to 192 bits, as scope of uniqueness is just a single server). This would not depend on knowing if node is wildcard or not. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
On Fri, Oct 25, 2019 at 7:11 AM Stephen Farrell wrote: > > > On 25/10/2019 15:06, Eric Rescorla wrote: > > OK. I don't think this needs to be documented in this draft, but if you > > 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. > 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 > Cheers, > S. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
On 25/10/2019 15:06, Eric Rescorla wrote: > OK. I don't think this needs to be documented in this draft, but if you > 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. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
On Fri, Oct 25, 2019 at 7:03 AM Stephen Farrell wrote: > > > 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 > > just an internal implementation covnenience? > > 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. > OK. I don't think this needs to be documented in this draft, but if you wanted to write some other draft -Ekr > Cheers, > S. > > > > > -Ekr > > > > > > On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> > >> 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/Iy1Y2EYAAhMBAQQAXO6j > >> /gBc995+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/Iy1Y2EYAAhMBAQQAXO6j > >> /gBc995+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 > >> ___ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
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 > just an internal implementation covnenience? 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. > > -Ekr > > > On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell > wrote: > >> >> 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/Iy1Y2EYAAhMBAQQAXO6j >> /gBc995+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/Iy1Y2EYAAhMBAQQAXO6j >> /gBc995+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 >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
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 wrote: > > 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/Iy1Y2EYAAhMBAQQAXO6j > /gBc995+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/Iy1Y2EYAAhMBAQQAXO6j > /gBc995+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 > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Standards Track for draft-ietf-tls-ticketrequests
During my Shepherd review of draft-ietf-tls-ticketrequests, I noticed that the intended status of the draft is Informational, but the IANA Considerations sections indicates that the Recommended column is “Y”. RFC 8447 requires Standards Action for an extension to be marked as Recommended. I went back and looked and the extension has been marked as Recommended since Chris' and David’s initial individual draft back in April 2018. I think that this has been an oversight and believe the intended status should be changed to Proposed Standard. If you think this change is wrong, please let the list know why by November 1st. Note that this is the final issue before I will issue WGLC. Cheers, spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
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. > > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TLS@IETF016: Agenda Topics
The preliminary IETF 106 agenda is out: https://datatracker.ietf.org/meeting/agenda/. The final agenda will be published later today. The TLS WG will be meeting @ IETF 106 in Singapore. To help the chairs get a better handle on how arrange our sessions, please send in your agenda requests to tls-cha...@ietf.org. Along with your request please provide an estimate for how much time you will need. Please note that we will prioritize existing WG items. Cheers, Chris, Joe, and Sean ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNI PEM files
Is the private key PKCS8? If not, then perhaps "ESNI PRIVATE KEY" is better. Overall, yes, plus-one. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adopting HTTPSVC for ESNI
Hiya, On 25/10/2019 01:28, Christopher Wood wrote: > Hi folks, > > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of > doing the same thing, I've put together a PR that drops the custom > ESNI RRType in favor of this more general (yet feature compatible) > Resource Record: > > https://github.com/tlswg/draft-ietf-tls-esni/pull/187 > > Please have a look and comment before next Friday. We'd like to land > this before Singapore. I'm supportive of this change, on the assumption that browsers are really going to use HTTPSSVC. If that lands as-is, please bump the version to ff04 and I don't see much benefit in changing from ESNIKeys to ESNIConfig (seems more likely to confuse than help to me). Going further, I think we ought also take advantage of this to simplify the ESNIKeys/ESNIConfig structure. We don't need to do that right now but we could. There are two related simplifications that'd make sense to me: - remove the version field and encode that in the HTTPSSVC label (so it'd be something like esnikeys05="/wElr6L2ACQAHQ...") - I think that'd lead to fewer cases where HTTPSSVC code needs to understand what's inside the ESNIConfig structure. - similarly, remove the extensions field from ESNIConfig, and require a new label in HTTPSSVC if something new is really needed Cheers, S. > > Best, Chris (no hat) > > [1] > https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s > > ___ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
