Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Tue, Sep 22, 2015 at 2:37 PM, Salz, Rich wrote: > We discussed this before. Not that we can't discuss it again. Here's a link > to slides I presented at the Toronto Interim in July 2015. > > > https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing > Thanks for that link, Rich! Please forgive me if my analysis has already been gone over, but I believe that there are at least three problematic aspects in the argument as presented in your slides. 1) Entrenchment of codependent vulnerabilities This is a strong antipattern in security design, and it's been practiced by some of the great minds of the field, but I think it's fundamentally mistaken. Here's how it works: There are two systems, A and B. Each has a problem that enables some kind of attack. The people who maintain system A say: "There is no point in fixing A, because any attacker who breaks A could achieve the same results via B." But the people who maintain system B say: "There is no point fixing B because any attacker who breaks B can achieve the same results via A." Both groups are using solid logic: neither one of them would materially improve user security by fixing the vulnerability in their system. The Codependent Vulnerability antipattern arises when no progress is ever made, because each group decides that the problems outside its control will probably never be fixed. In your slides, I see several instances of codependent vulnerabilities: a) Improved DNS security vs Encrypted SNI The lack of security in current DNS usage is taken to justify not improving SNI privacy. But in discussions about DNS privacy, vulnerabilities in other protocols are frequently taken as justification for not improving DNS privacy. b) Traffic analysis vs encryption Traffic analysis is indeed strong today, but it's not omnipotent, and good research on resisting it is happening all the time. But if we take the weaknesses of TLS against traffic analysis a a permanent feature of the world, then such research will have less opportunity to bear fruit, since TLS will entrench the problems that anti-traffic-analysis research cannot yet solve. c) Technical attacks vs rubber-hose attacks See point 2 below. 2) Attacks are not equally costly and do not scale equally well. It's not sufficient to say "This defense will not render the attack impossible; therefore it is useless"; we also need to consider whether the defense will render the attack _more expensive_. Even for regimes unconcerned with fair play and regimes with significantly intrusive attitudes to civil liberties... intimidating citizens, applying political pressues, and backdooring infrastructure are not zero-cost operations. In nearly all cases, ithese attacks are more difficult and costly than simply reading bytes off the wire. 3) Censorship vs surveillance. The analysis in the slides is concerned with attackers against privacy rather than attackers against availability. But IMNSHO, both kinds of attacker are a significant threat to human rights. Unencrypted SNI makes a censor's job extremely easy. In today's TLS, it's trivial to block targeted domains hosted at a provider without blocking ones where the censors consider access desirable. Encrypting SNI would make this kind of blocking more difficult and technically expensive. To be fair, encrypted SNI would probably make trouble for providers who host some censored and some uncensored services. Plaintext SNI does make it easier for censors to be selective, and thereby makes it easier for hosting providers to avoid conflicts and drama. best wishes, -- Nick Mathewson ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
Thanks for your detailed and thoughtful review. It's all trade-offs. In previous emails on this thread I acknowledged the co-dependant issue, by calling out dkg's excellement statement of it. At the TLS interim earlier this week, Brian Sniffen (from Akamai) started a proposal that makes SNI-encryption something that can be deployed and tested on the Internet in TLS 1.3. So we'll see if it gets used and works. The earlier slides notwithstanding, it's something we (those of us at Akamai) would really like to see. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
Salz, Rich wrote: > > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started > a proposal that makes SNI-encryption something that can be deployed and > tested on the Internet in TLS 1.3. So we'll see if it gets used and works. > The earlier slides notwithstanding, it's something we > (those of us at Akamai) would really like to see. I haven't been tracking the TLSv1.3 proposals -- but whatever you do in the area of encrypted SNI, please ensure that padding *WILL* be used, so that two encrypted server names, that happend to differ by length, will not remain easily distinguishable. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
Martin Rex wrote: > Salz, Rich wrote: > > > > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started > > a proposal that makes SNI-encryption something that can be deployed and > > tested on the Internet in TLS 1.3. So we'll see if it gets used and works. > > The earlier slides notwithstanding, it's something we > > (those of us at Akamai) would really like to see. > > I haven't been tracking the TLSv1.3 proposals -- but whatever you do > in the area of encrypted SNI, please ensure that padding *WILL* be used, > so that two encrypted server names, that happend to differ by length, > will not remain easily distinguishable. Because it is not necessarily immediately obvious, you will need padding also for the Server Certificate handshake messages. And, because the key exchange is side-effected by properties of the Server Certificate, you may additionally need padding for the ServerKeyExchange and ClientKeyExchange handshake messages, so that the protocol doesn't leak of one of the service uses an RSA certificate and the other uses an ECDSA (or EdDSA) certificate. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
Various paddings (is that a word?) will be needed, but the ability to pad things is also in TLS 1.3. We think all the necessary TLS protocol bits are present. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Friday, September 25, 2015 01:10:37 pm Martin Rex wrote: > Because it is not necessarily immediately obvious, you will need > padding also for the Server Certificate handshake messages. > And, because the key exchange is side-effected by properties of > the Server Certificate, you may additionally need padding for the > ServerKeyExchange and ClientKeyExchange handshake messages, so > that the protocol doesn't leak of one of the service uses > an RSA certificate and the other uses an ECDSA (or EdDSA) certificate. This sounds like a good argument to come up with a default padding scheme for all handshake messages for even clients that don't use application data padding. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
How about making fixed length(s) for each message type, then pad it with 0x01 then optional 0x00s? Quynh. From: TLS on behalf of Dave Garrett Sent: Friday, September 25, 2015 2:11 PM To: tls@ietf.org; m...@sap.com Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) On Friday, September 25, 2015 01:10:37 pm Martin Rex wrote: > Because it is not necessarily immediately obvious, you will need > padding also for the Server Certificate handshake messages. > And, because the key exchange is side-effected by properties of > the Server Certificate, you may additionally need padding for the > ServerKeyExchange and ClientKeyExchange handshake messages, so > that the protocol doesn't leak of one of the service uses > an RSA certificate and the other uses an ECDSA (or EdDSA) certificate. This sounds like a good argument to come up with a default padding scheme for all handshake messages for even clients that don't use application data padding. Dave ___ 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] TLS 1.3 - Support for compression to be removed
On 23/09/15 06:55, Tony Arcieri wrote: > They should not be relying on a poorly conceived feature > which has been repeatedly demonstrated to introduce vulnerabilities in what > is supposed to be a *security protocol* just because they don't want to > implement compression themselves. I see people asserting that doing compression as part of a security layer results in bad security. I see other people asserting that a compression layer above a security layer is both sufficient and the way to go. I see existing applications who are using a transport _service_ which used to (allegedly) provide both security and compression. Why is it not possible for TLS1.3 to provide that same service combination, but implemented by design in a layered fashion? -- Cheers, Jeremy ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Fri, Sep 25, 2015 at 07:40:05PM +0100, Jeremy Harris wrote: > Why is it not possible for TLS1.3 to provide that same service > combination, but implemented by design in a layered fashion? TLS is correctly agnostic of semantic boundaries, in application data. For this to work, applications would need to be able to ask TLS to enable and disable compression at any time after the handshake, once some uncompressed or compressed data has gone by. This requires new application protocol verbs "STARTCOMPRESSION", "STOPCOMPRESSION", and underlying support in the TLS layer. A suitable application I/O library that supports pushing and popping protocol "modules" onto a raw I/O stream, would be a better vehicle for this than forcing dynamic compression support into TLS. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
> > This requires new application protocol verbs "STARTCOMPRESSION", > > "STOPCOMPRESSION", and underlying support in the TLS layer. > I wonder if it would have been possible to do this via renegotiation, though > this has overhead. Intriguing, but moot of course, since renegotiation is gone. :) Interesting corner-cases to think about: is compression restarted, or do you preserve all state to pick up where you left off (e.g., the zlib dictionary)? Either either one probably has some security issues to think about. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] '15 TLS Fall Interim Minutes
On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > I’ve gone ahead and posted the minutes/list of decisions to: > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of it in the minutes. (it's a suggestion from Karthik to generate a new client random on retry) Did this get discussed? https://github.com/tlswg/tls13-spec/issues/185 Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] '15 TLS Fall Interim Minutes
On Fri, Sep 25, 2015 at 6:13 PM, Dave Garrett wrote: > On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of > it in the minutes. (it's a suggestion from Karthik to generate a new client > random on retry) > > Did this get discussed? > > https://github.com/tlswg/tls13-spec/issues/185 > > No. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removedL
On Sat, Sep 26, 2015 at 12:19:17AM +, Salz, Rich wrote: > > I wonder if it would have been possible to do this via renegotiation, though > > this has overhead. > > Intriguing, but moot of course, since renegotiation is gone. :) Interesting > corner-cases to think about: is compression restarted, or do you preserve > all state to pick up where you left off (e.g., the zlib dictionary)? > Either either one probably has some security issues to think about. It would have had to be a restart. But of course it is not happening. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
