[TLS] More issues with current ESNIKEYS DNS approach
Following the discussion this week I realized some other major issues we'll need to make sure we cover: 1) Handling proxies here is going to be tricky. The CONNECT generally needs to specify the hostname which needs to go to the server which has the ESNI key for what gets sent in the TLS handshake. IPs don't come into play here at all. The only thing I can think of for handling this is to pass the canonical name to the CONNECT when using a proxy, and making sure that the canonical name is specific to a CDN. There may be some related issues in non-proxy environments. 2) The extension model breaks down if not all CDNs send it as mandatory. In the hallway, Chris suggested we could require at least one extension be manditory in any ESNIKey record in DNS. There could be a bunch of similar corner cases. This issue also applies to switching off of using ESNIKeys (eg, if there had been no extension included). 3) Trusting A and records from the EDNSKeys is going to break environments relying on /etc/resolv.conf for spoofing to staging or other testing environments. (Services and Support staff will likely be unhappy as they do this all the time.) On Sat, Mar 9, 2019 at 9:08 PM Christopher Wood wrote: > >> i'd also like to hear from CDNs about whether their address ranges > >> are really small enough to not make the list of ranges prohobitive. > At least for one CDN, there are tens to hundreds of possible A/ records that could be used in a given cluster, and then many thousands of clusters. Especially on IPv4 this space is not dense as some comes from local provider space. (The net result for each is far more IPv4 and IPv6 addresses than can be enumerated reasonably.) Some additional minor issues we'll want to address or specify, regardless, if we take this path: * We'll want to make sure to specify that clients must round-robin or permute the A and records included in the address list. Typically most recursive and/or stub resolvers handle this, but since it's all in one RR and not an RRSET it will be on clients to do this properly. * We may wish to provide guidance on how to handle A vs (eg, reference RFC 8305). One thing that clients may lose out on is support features provided by the OS, such as those which sort results based on past knowledge about RTT and the like. I'm increasingly thinking that while we may wish to define a general-purpose ESNIKEY record for use by generic applications, we may wish to define application-protocol specific use-cases and bindings for some of the most persnickety applications. For example, an HTTP-specific "HTTPS" record that combined ALTSVC, ESNIKEY, and "ANAME" style information may solve a bunch of these issues together. I've been talking to some folks and am tempted to try writing up a draft on this. (Mail might be another case that will just want its own binding...) Erik ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A flags extension
In addition to this, the document would seem to allow a server to set bit k if the client did not set that bit. (Or more generally, the responder can set bits the initiator did not set. ) In fitting with the TLS model, I would recommend allowing a responder to set only bits that the initiator sets. Other bits being set would be an error. On Fri, Mar 29, 2019, at 19:59, John Mattsson wrote: > Hi, > > The document only talks about use in ClientHello, ServerHello, and > EncryptedExtensions. I think it should also discuss usage in > CertificateRequest, Certificate from the server, and Certificate from > the client. It should likely be left to the document that specifies a > specific feature to determine where it can be used. > draft-thomson-tls-sic-00 uses the tls_flags extension in > CertificateRequest. > > Cheers, > John > > > ___ > 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] Comment on draft-thomson-tls-sic-00
And one more "The 0xTBD flag can only be send in a ClientHello or CertificateRequest message. Endpoints that receive a value of 1 in any other handshake message MUST generate a fatal illegal_parameter alert." This goes against draft-nir-tls-tlsflags "A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by the client." I assume the sic sic extension should be sent in EncryptedExtensions. Cheers, John -Original Message- From: John Mattsson Date: Friday, 29 March 2019 at 11:34 To: "TLS@ietf.org" Subject: Re: Comment on draft-thomson-tls-sic-00 Some more comments after reading the draft in detail. - The abstract and introduction only talks about the ClientHello use case. Should shortly mention the CertificateRequest use case as well. - I notice that the draft does not have any requirement on how the client gets access to the intermediary certificates. I think this is the right approach. The problem discussed in EMU is that that many access points drops EAP connections after 40 - 50 packets and that EAP-TLS connections with large certificate chains may therefore be unable to complete. One approach discussed in EMU is that the client could take intermediate certificates from an earlier EAP-TLS connection that was dropped by the access point. This drafts currently allows that. I think that is correct. I cannot see that the distribution of intermediary certificates need any security requirements as the client can verify them with the help of one of its trust anchors. Cheers, John -Original Message- From: John Mattsson Date: Friday, 29 March 2019 at 10:29 To: "TLS@ietf.org" Subject: Comment on draft-thomson-tls-sic-00 Hi, I am strongly supporting of solving the problem this draft is trying to solve. This is a problem that the EMU WG has identified and discussed in the past. https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02 I will add text discussing draft-thomson-tls-sic-00 to draft-ms-emu-eaptlscert-03 and ask for agenda time in EMU at IETF 105 to discuss if draft-thomson-tls-sic-00 solves the problems of the EMU WG. The EMU WG actually shortly discussed this Monday if the WG thought there was any updates to TLS that needed to be driven in the TLS WG. Cheers, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A flags extension
Hi, The document only talks about use in ClientHello, ServerHello, and EncryptedExtensions. I think it should also discuss usage in CertificateRequest, Certificate from the server, and Certificate from the client. It should likely be left to the document that specifies a specific feature to determine where it can be used. draft-thomson-tls-sic-00 uses the tls_flags extension in CertificateRequest. Cheers, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Comments on draft-stebila-tls-hybrid-design-00
On Thu, Mar 28, 2019, at 16:58, Scott Fluhrer (sfluhrer) wrote: > * 3.3.1. (Shares-concat) Concatenate key shares > My concern with this is that there may be algorithms with variable key > share size (I don’t know of any right now, but ‘extensibility’); if we > do this, we would want internal length markers Anything injective should work. > * 3.4.2. (Comb-XOR) XOR keys and then KDF > This one makes me nervous. Me too. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A use of flags
On Fri, Mar 29, 2019, at 11:18, Andrei Popov wrote: > > No resumption in TLS 1.3... > You probably mean no renegotiation in TLS 1.3. Of course, thank you. Not nearly enough sleep this week. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Comment on draft-thomson-tls-sic-00
Some more comments after reading the draft in detail. - The abstract and introduction only talks about the ClientHello use case. Should shortly mention the CertificateRequest use case as well. - I notice that the draft does not have any requirement on how the client gets access to the intermediary certificates. I think this is the right approach. The problem discussed in EMU is that that many access points drops EAP connections after 40 - 50 packets and that EAP-TLS connections with large certificate chains may therefore be unable to complete. One approach discussed in EMU is that the client could take intermediate certificates from an earlier EAP-TLS connection that was dropped by the access point. This drafts currently allows that. I think that is correct. I cannot see that the distribution of intermediary certificates need any security requirements as the client can verify them with the help of one of its trust anchors. Cheers, John -Original Message- From: John Mattsson Date: Friday, 29 March 2019 at 10:29 To: "TLS@ietf.org" Subject: Comment on draft-thomson-tls-sic-00 Hi, I am strongly supporting of solving the problem this draft is trying to solve. This is a problem that the EMU WG has identified and discussed in the past. https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02 I will add text discussing draft-thomson-tls-sic-00 to draft-ms-emu-eaptlscert-03 and ask for agenda time in EMU at IETF 105 to discuss if draft-thomson-tls-sic-00 solves the problems of the EMU WG. The EMU WG actually shortly discussed this Monday if the WG thought there was any updates to TLS that needed to be driven in the TLS WG. Cheers, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A use of flags
> No resumption in TLS 1.3... You probably mean no renegotiation in TLS 1.3. -Original Message- From: TLS On Behalf Of Martin Thomson Sent: Friday, March 29, 2019 10:25 AM To: Hubert Kario ; tls@ietf.org Subject: Re: [TLS] A use of flags On Thu, Mar 28, 2019, at 14:46, Hubert Kario wrote: > what about resumption and renegotiation? No certificates in resumption. No resumption in TLS 1.3 (and I don't care about TLS 1.2 any more). ___ 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%7Cb0eec22e1db4492231f408d6b428b219%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636894484211356742sdata=t0K5DCsx%2FZIV%2Bs7bnUe5lZO0SHtqqCT005GGRAuptUM%3Dreserved=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Comment on draft-thomson-tls-sic-00
Hi, I am strongly supporting of solving the problem this draft is trying to solve. This is a problem that the EMU WG has identified and discussed in the past. https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02 I will add text discussing draft-thomson-tls-sic-00 to draft-ms-emu-eaptlscert-03 and ask for agenda time in EMU at IETF 105 to discuss if draft-thomson-tls-sic-00 solves the problems of the EMU WG. The EMU WG actually shortly discussed this Monday if the WG thought there was any updates to TLS that needed to be driven in the TLS WG. Cheers, John ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A flags extension
On Thu, Mar 28, 2019, at 14:54, Hubert Kario wrote: > what about making sure that the legacy and flags remain in-sync? we will have > to send the legacy encoding for many years to come, so only thing it would > possibly reduce the size of is ServerHello or EncryptedExtensions Those are messages where we have size pressure. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
