Re: [TLS] ESNI/ECH: minor progress, much githubbery
On Mon, Sep 28, 2020 at 12:55 PM Stephen Farrell wrote: > > Hiya, > > Today I read over the diff between the latest ESNI/ECH > version and draft-07. [1] I have the following comments: > > 1. The volume of discussion on github is a deterrent. (*) > I agree the churn has seemed surprisingly heavy. The changes look well-meaning, but I don't really see a plan. Are there OpenSSL / NSS / etc implementations others can work from? Probably the best way to lock this in and ship is to write the code. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Tue, Sep 29, 2020, at 10:38, Watson Ladd wrote: > > Is stateless HelloRetryRequest even being used? If so, how? NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server state, in which case the retained state is compared against the state from the cookie as an extra sanity check. We chose to do this for a few reasons, but one thing is that it encourages us to use the second ClientHello for negotiating everything. > QUIC depends on it iiuc. It did, but it doesn't any more. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Mon, Sep 28, 2020 at 3:33 PM Michael D'Errico wrote: > On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > > > Luckily, we don't have any angry cryptographers in this group. > > Were they all pushed away too? > I don't think this is very likely. The TLS list can get a bit competitive, but other IETF lists (say, anything related to DNS), are much worse. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Mon, Sep 28, 2020 at 6:33 PM Michael D'Errico wrote: > > On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > > > Luckily, we don't have any angry cryptographers in this group. > > Were they all pushed away too? > > Anyway, back on the topic of stateless HelloRetryRequest, I > don't see how this can work given that the client can make > several modifications to the ClientHello which will invalidate > the hash sent in the "cookie" (even if the client echos it back > as required without modification). The hash isn't used for validation, but for continuing the running hash of the transcript to ensure that the negotiation isn't interfered with. See section 4.4.1. > > Is stateless HelloRetryRequest even being used? If so, how? QUIC depends on it iiuc. Sincerely, Watson -- Astra mortemque praestare gradatim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Problem?
On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > Luckily, we don't have any angry cryptographers in this group. Were they all pushed away too? Anyway, back on the topic of stateless HelloRetryRequest, I don't see how this can work given that the client can make several modifications to the ClientHello which will invalidate the hash sent in the "cookie" (even if the client echos it back as required without modification). Is stateless HelloRetryRequest even being used? If so, how? Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] ESNI/ECH: minor progress, much githubbery
Hiya, Today I read over the diff between the latest ESNI/ECH version and draft-07. [1] I have the following comments: 1. The volume of discussion on github is a deterrent. (*) I can't keep up with that and coding at the same time so (being busy elsewhere) paused my coding work in the hope that the noise would fade over time. Consider this a noise- reduction plea to allow time for implementation and testing. 2. Almost all the changes seems fine but near-trivial. The move to expand/extract from hashes doesn't seem to add much. I hope there's some theory-justification for it. I don't see 3 months of significant improvement so please consider that we may have hit diminishing returns in the mega-discussion. 3. (This isn't new, but no harm repeating:-) I don't plan to adhere to the MUST send the public_name from the ECHConfig. That makes sense for a browser but for a command line tool, or similar, my conclusion is that overriding can be justified, so I treat that as a SHOULD. (I allow such an override for the openssl s_client version I've done and similarly for curl.) FWIW, I hope to now have time to resume coding. I won't have time to process the volume of mails generated by recent github discussion as well so plan to pay attention to the text, openssl code and the mailing list. I might or might not notice something significant in the githubbery, so would be happy if significant changes (if any) can be sent to the list. Cheers, S. [1] https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-tls-esni.txt=https://tlswg.github.io/draft-ietf-tls-esni/draft-ietf-tls-esni.txt#part-2 (*) I get mail when there are comments on that repo. I have gotten 784 since June 1 when draft-07 was published. There were also 557 github emanations related to SVCB in the same timeframe. 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] TLS 1.3 Problem?
Hi Mike, > I felt that I was unwelcome in this group by some of the "angry > cryptographers" as I call them. No reason to worry. Luckily, we don't have any angry cryptographers in this group. On top of what Richard mentioned in his response, take a look at Appendix D of the spec, see https://tools.ietf.org/html/rfc8446#appendix-D. Ciao Hannes -Original Message- From: TLS On Behalf Of Michael D'Errico Sent: Sunday, September 27, 2020 9:52 PM To: tls@ietf.org Subject: [TLS] TLS 1.3 Problem? Hi, Took a quick look at RFC 8446 and noticed that there is no definition of ServerKeyExchange or ServerHelloDone which are part of TLS 1.2 and prior. A 1.3 client talking to a 1.2 or earlier server is likely going to receive both of these messages: RFC 5246 TLSAugust 2008 Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data <---> Application Data Figure 1. Message flow for a full handshake Since RFC 8446 obsoletes RFC 5246, this is a serious problem. How is this supposed to work? Sorry but I did not follow the development of TLS 1.3. I felt that I was unwelcome in this group by some of the "angry cryptographers" as I call them. Mike ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] The future of external PSK in TLS 1.3
Hi Hannes The TLS-SE code is now published https://github.com/purien/TLS-SE It also comprises software tools for testing This code is a TLS1.3 ECDH-PSK server for a javacard as specified in https://tools.ietf.org/html/draft-urien-tls-se-01 It has been tested with several javacard 3.04 This code also implements https://tools.ietf.org/html/draft-urien-tls-im-03 Pascal Le lun. 21 sept. 2020 à 17:05, Hannes Tschofenig a écrit : > > > Ping me when it becomes available or post a link to the UTA mailing list. > > > > *From:* Pascal Urien > *Sent:* Monday, September 21, 2020 4:18 PM > *To:* Hannes Tschofenig > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 > > > > Not at this moment but the code will be pusblished on github > > > > Le lun. 21 sept. 2020 à 15:30, Hannes Tschofenig < > hannes.tschofe...@arm.com> a écrit : > > Thanks for the details. > > > > Is the code for the tls13 server on the javacard open source? > > > > Ciao > > Hannes > > > > > > *From:* Pascal Urien > *Sent:* Monday, September 21, 2020 2:54 PM > *To:* Hannes Tschofenig > *Cc:* Filippo Valsorda ; tls@ietf.org > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 > > > > tls-se memory footprint is > > flash 《 40KB > > ram 《 1KB > > > > time to open a tls session 1.4 seconds > > > > > > Le lun. 21 sept. 2020 à 14:47, Pascal Urien a > écrit : > > hi Hannes > > > > no openssl or wolfssl are used as client in order to check > interoperability with tls-se server > > > > tls-se is of course a specific implémentation for tls13 server in > javacard..it is written in java but an ôter implémentation is written in c > for constraint notes. as written in the draft tls-se implementation has > three software blocks: crypto lib, tls state machine, and tls lib > > > > > > > > Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig < > hannes.tschofe...@arm.com> a écrit : > > Hi Pascal, > > > > are you saying that the stack on the secure element uses WolfSSL or > OpenSSL? I am sure that WolfSSL works well but for code size reasons I > doubt OpenSSL is possible. Can you confirm? > > > > In case of WolfSSL, you have multiple options for credentials, including > plain PSK, PSK-ECDHE, raw public keys, and certificates as I noted in my > mail to the UTA list: > > https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/ > > > > Ciao > > Hannes > > > > *From:* Pascal Urien > *Sent:* Monday, September 21, 2020 2:01 PM > *To:* Hannes Tschofenig > *Cc:* Filippo Valsorda ; tls@ietf.org > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 > > > > Hi Hannes > > > > Yes it has been tested with several 3.04 Javacards commercially available > > > > In the draft https://tools.ietf.org/html/draft-urien-tls-se-00 Section > 5-ISO 7816 Use Case, the exchanges are done with the existing implementation > > > > TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or Arduino+Ethernet > boards > > > > For client software we use OPENSSL or WolfSSL > > > > Pascal > > > > > > > > > > Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig < > hannes.tschofe...@arm.com> a écrit : > > Hi Pascal, > > Thanks for the pointer to the draft. > > Since I am surveying implementations for the update of RFC 7925 (see > https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I was > wondering whether there is an implementation of this approach. > > Ciao > Hannes > > > From: Pascal Urien > Sent: Monday, September 21, 2020 11:44 AM > To: Hannes Tschofenig > Cc: Filippo Valsorda ; tls@ietf.org > Subject: Re: [TLS] The future of external PSK in TLS 1.3 > > Hi All > > Here is an example of PSK+ECDHE for IoT > > https://tools.ietf.org/html/draft-urien-tls-se-00 uses TLS1.3 server > PSK+ECDHE for secure elements > > The security level in these devices is as high as EAL5+ > > The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, + > secp256r1) > > The real critical resource is the required RAM size, less than 1KB in our > experiments > > The secure element only needs a classical TCP/IP interface (i.e. sockets > like) > > Trusted PSK should avoid selfie attacks > > Pascal > > > > Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig hannes.tschofe...@arm.com> a écrit : > Hi Filippo, > > • Indeed, if the SCADA industry has a particular need, they should profile > TLS for use in that industry, and not require we change the recommendation > for the open Internet. > > We have an IoT profile for TLS and it talks about the use of PSK, see > https://tools.ietf.org/html/rfc7925 > > On the “open Internet” (probably referring to the Web usage) you are not > going to use PSKs in TLS. There is a separate RFC that provides > recommendations for that environmnent, see RFC 752. That RFC is currently > being revised, see > https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/ > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended >
[TLS] Review of draft-ietf-tls-esni
Hi, I review the version on github and have a few high level comments. Cheers, John - Section 1 "The cleartext Server Name Indication (SNI) extension in ClientHello messages, which leaks the target domain for a given connection, is perhaps the most sensitive information unencrypted in TLS 1.3." External PSK identities are probably even more sensitive, but are of course not as commonly used as SNI. The draft should definitly mention external PSK identities. - Section 1 "and other potentially sensitive fields, such as the ALPN list." I think there is much more than SNI and ALPN that can be sensitive. I think the draft should mentioned that the set of extensions and their content as a whole can be used to identity a specific application (e.g. Tor, File sharing, dating apps, etc.). The list of supported cipher suites is well-known to have been used in practice for fingerprinting. Section 10.2 “In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource Records are signed via a server private key, ECH records have no authenticity or provenance information. This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply clients with fake ECH records (so that the client encrypts data to them) or strip the ECH record from the response. However, in the face of an attacker that controls DNS, no encryption scheme can work” I think the statement "no encryption scheme can work" is to strong. If the authenticity of ECHConfig is assured it mitigates attacks where an attacker inject false ECHConfig to lure the client to encrypt data to the attacker. Furthermore, the presence of ECHConfig could fool the client to do something they would not do otherwise, like using usign a sensitive application like Tor, File sharing, dating apps, etc. which could get the person in trouble. I think the draft needs to state that something like: “if the authenticity of ECHConfig cannot be assured, it is unknown who can decrypt the InnerClientHello. Client shall not change their behavior based on unauthenticated ECHConfig”. Section 10.2 ”Thus, allowing the ECH records in the clear does not make the situation significantly worse.” ”SNI encryption is less useful without encryption of DNS queries in transit” These two statements seems slightly contradicting. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
