On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen <fandr...@cisco.com> wrote:
> Thank you for the feedback Ekr - please see below for responses > > > On 11/6/17 12:43 PM, Eric Rescorla wrote: > > I took a look at this. > > Without getting into the question of whether the types of middleboxes > you describe here provide a security benefit, there are several points > in the document that are either wrong or at least misleading/confusing. > > - Key Synchronization > This document notes that in TLS 1.2, it is possible for a middlebox > that traffic keys match on both sides of the connection it is proxying, > but in TLS 1.3 it is not: > > There are several techniques that can be utilized. Those techniques > function with TLS 1.2 and earlier versions but not with TLS 1.3. > > One technique is for the middlebox to negotiate the same master > secret with the original TLS client and server, as if the two > endpoints handshake directly. This is also known as "Triple > Handshake" used by legitimate middleboxes. [BreakTLS] describes the > methods with RSA and DH key exchanges. When the proxy session keys > are the same as for a direct handshake, the middlebox is able to > "cut-through" the two TLS proxy sessions when it finishes the > security inspection. > > This technique is not functional with TLS 1.3 since the transcript > hash over the handshake messages is part of the key derivation > procedure. > > First, I would note that this property of TLS 1.2 is bad, as it leads > to Unknown Key Share (UKS) attacks, which can be the basis of real > attacks on TLS 1.2 as fielded. It is for this reason that the TLS > WG published RFC 7627. > > Thanks for the bringing that one up - we will make sure to include that in > the next version. > > Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's an > integral part of the protocol that cannot be disabled. The TLS 1.2 > extension does not share that property. > It seems like an odd complaint that we are making protection against Unknown Key Shares an integral part of the protocol > Finally, you note several times in the document (e.g., S 4.5), that > with key synchronization, the middlebox can perform the handshake and > then disengage from the connection. However, the cases you mention > (e.g.., detecting exploit attempts) ultimately require examining > all traffic in the connection. > > We have several different use case scenarios in there, and I agree with > the observation that they cannot all be satisfied at the same time. For > example, we cannot scan for malware in an encrypted stream to a financial > institution that we are not allowed to decrypt. That doesn't mean either > use case is invalid. Customers do both in real-life (just not at the same > time). > I'm finding it a bit puzzling what you claim customers do. Specifically, you seem to be saying that customers examine the beginning of the connection and then stop. What are they scanning for and what makes them stop? > - PSK and resumption > You write: > > In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), > which can be negotiated as part of an initial handshake and then used > in a subsequent handshake to perform resumption using the PSK. TLS > 1.3 states that the client SHOULD include a "key_share" extension to > enable the server to decline resumption and fall back to a full > handshake, however it is not an absolute requirement. > > Example scenarios that are impacted by this are middleboxes that were > not part of the initial handshake, and hence do not know the PSK. If > the client does not include the "key_share" extension, the middlebox > cannot force a fallback to the full handshake. If the middlebox > policy requires it to inspect the session, it will have to fail the > connection instead. > > In TLS 1.3, PSKs and session resumption are basically the same and > have the same properties. While I concede that the document does > not require the client to offer key_shares, as a practical matter > it is very unlikely that a client will act in such a way that > failure to retain the PSK causes a hard failure, for two reasons: > > (a) In every version of TLS, the ticket lifetime is just a hint, and > the server can forget it at any time > (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13. > html#NSTMessage). Thus, > a client which does not allow a full handshake will often > find itself unable to connect. > > (b) The relevant question is not whether the client offers a key share > extension but whether it advertises any DH groups. If the client sends > a group but not a key share, the server can send HelloRetryRequest > to force the client to send a key share. > > For these reasons, as far as I know, every client (and at least every > browser client) should allow a full handshake even when trying to resume. > > If that is indeed the case, then I would suggest changing the spec > language to a MUST here instead so we can guarantee it. > I don't believe this is necessary. There are certainly reasons why you would want to do PSK w/o (EC)DHE (e.g., you are really PSK only). - Server Certificate Concealment > You note that in TLS 1.2 the middlebox can examine both the SNI and the > server's certificate in order to decide whether to MITM the connection, > but that in TLS 1.3, the middlebox cannot guarantee that the SNI in > uses is correct: > > In TLS 1.2, the ClientHello, ServerHello and Certificate messages are > all sent in clear-text, however in TLS 1.3, the Certificate message > is encrypted thereby hiding the server identity from any > intermediary. Note that even _if_ the SNI is provided (in cleartext) > by the client, there is no guarantee that the actual server > responding is the one indicated in the SNI from the client. > > In this case, it's important to distinguish between conformant and > nonconformant clients. In the former case -- as when the user is > not attempting to evade inspection -- the SNI will reflect the > identity that the client expects and therefore will compare the > certificate against. > > Of course, in the case where the client is attempting to evade > inspection, the certificate might not match. However, in this > scenario, the client and server are colluding and so there are > a variety of ways to avoid inspection, even when doing TLS 1.2. > > For example: > > 1. The client and server can share a prearranged public key and then > negotiate static RSA. The client sends an innocuous SNI and the server > can simply send the certificate of the corresponding server, captured > by connecting to that server. The client then enciphers the PMS > under the server's prearranged key and continues with TLS as usual. > This cannot be detected by the middlebox without decrypting the EPMS. > > 2. If an (EC)DHE cipher suite must be negotiated, then the attack > described above does not work directly because the server's signature > over the ServerKeyExchange can be validated, and of course the > attacker server does not have the legitimate server's key. However, > the server can forward the ClientHello to the legitimate server, > capture the Certificate and ServerKeyExchange and the proxy those to > the client. This looks legitimate to the inspection device and then > the client can simply send the Encrypted PMS in the first chunk of > data that is apparently encrypted under the server's key. > > For these reasons, being able to see the server's certificate provides > a false sense of security, as this check is easily bypassed. > > I agree we should distinguish between between conformant and > non-comformant. > > For the conformant case, I do not know to what extent we can rely on the > client always sending the SNI, but even if it is always sent, there are > still use case scenarios around certificate audit, etc. that cannot be > satisified in TLS 1.3 without becoming an active MITM. > You can do certificate audit by making an independent connection and eliciting the certificate. > With the recently adopted proposal around SNI encryption, there are more > use cases that cannot be satisfied without becoming an active MITM. > Yes, I agree with that. For the non-conformant case, you bring up some good points. We can reduce > the set of bypass scenarios there, but we cannot eliminate them. > I'm not persuaded that you can meaningfully reduce them. What technical approach do you believe would do so? -Ekr > > > Thanks again for the feedback - we will update accordingly in the next > version of the draft. > > -- Flemming > > > > -Ekr > > > [0] Note: the use of static DH is very rare. > > > On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) < > ncamw...@cisco.com> wrote: > >> All, >> >> >> >> @IETF99, awareness was raised to some of the security WGs (thanks >> Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in >> TLS 1.2 and asked what the implications would be for the security solutions >> today. https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is >> an initial draft to describe some of the impacts relating to current >> network security solutions. The goal of the draft is NOT to propose any >> solution as a few have been proposed, but rather to raise awareness to how >> current network-based security solutions work today and their impact on >> them based on the current TLS 1.3 specification. >> >> >> >> Regards, Nancy, Flemming and Eric >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
