Re: [TLS] TLS 1.3 - Support for compression to be removed
On Tue, Sep 22, 2015 at 1:35 PM, Stephen Farrell wrote: > > > On 22/09/15 17:23, Tony Arcieri wrote: >> But an unsafe feature shouldn't be kept in >> TLS just because some protocols want to do unsafe things and are too lazy >> to implement their own compression. > > Compression does have issues clearly, but it's not correct to describe > people wanting TLS to compress as lazy. They're rather looking for the > same features that TLS has offered for a couple of decades. So if there > were a way to help them, that'd be good. And if not, the onus I think > is on us in this WG to clearly explain why we're removing that feature > in TLS1.3. > > That doesn't have to be text in the TLS1.3 specification but I would > guess the question may keep coming up, so documenting the answer in > some archival form (such as an RFC:-) might be a good plan. I like this idea... and it doesn't have to be compression-specific but could rather be of the variety of "Things that we [don't think make sense/consider harmful/are best done] if done at the TLS layer." This won't help get 1.3 out the door sooner, but it would be very useful to understand important points of consensus in TLS WG that are broader design decisions that may persist past 1.3. best, Joe -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ 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 Tue, Sep 22, 2015 at 1:39 PM, Jacob Appelbaum wrote: > On 9/21/15, Daniel Kahn Gillmor wrote: >> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni >> wrote: >>> So the client would now need to cache some session data by transport >>> address, and other data by name and port. That's rather complex. >> >> This is already done by HTTP/2 clients, since they can access multiple >> servers at the same address:port combination. >> >>> And how often will the same client visit multiple servers at the >>> same transport address? >> >> *.github.io, *.blogspot.com, massive CDNs, etc. It's a common pattern. >> >>> I don't really see this as viable or worth the effort. >> >> I disagree -- the metadata leaked to a passive attacker by mandatory SNI >> is a valuable signal. It is worth trying to protect it. > > I agree - this metadata is usable as a selector for automated > surveillance and for automated exploitation. I agree with Jake and DKG wholeheartedly. I'd add that in addition to surveillance and exploitation, cleartext SNI will be useful for censors at various scales... the same property that it's useful for (distinguishing which domain at an endpoint a TLS conversation is for), can be used to impair or drop flows. I realize there is a small minority of people that participate in TLS WG that feel very strongly about designing a way to have encrypted SNI, but I'd really hope that we can find a way to do it, and that it's not considered too massive of an effort. The uses in which we would want to harden TLS connections against surveillance, exploitation, and censorship will seem to only grow, and having it baked into the infrastructure (and done well) will mean we will have much more deployed ability to resist these kinds of network attacks. >> >>> I don't think SNI hiding is viable without encryption at the >>> transport or network layers. >> >> any encrypted SNI is effectively acting as a shim for transport >> encryption, yes. Then again, TLS is itself "transport layer security", >> so we should try to provide it at least as an option. > > In an ideal world: using ephemeral keys, we must be able to have usage > of the protocol that is selector free. > >> >>> And there's still a metadata leak via DNS which may prove difficult to >>> address. >> >> The DNS community is working to address the DNS leak in DPRIVE. The TLS >> community should be working to fix its own part of the metadata leak. >> > > Agreed, strongly. > > All the best, > Jacob > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 j...@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS to protect customers
+1 On Mon, Mar 19, 2018 at 3:32 AM, Daniel Kahn Gillmor wrote: > On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote: >>> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue wrote: >>> >>> I fail to see how the current draft can be used to provide visibility >>> to an IPS system in order to detect bots that are inside the bank… >>> >>> On the one hand, the bot would never opt-in for visibility if it’s >>> trying to exfiltrate data… >> >> The presumption is that any legitimate application would opt-in, so >> the IPS blocks any TLS connection that does not opt in. > > Thanks for clarifying the bigger picture here, Yoav. > > So if this technology were deployed on a network where not all parties > are mutually trusting, it would offer network users a choice between > surveillance by the network on the one hand (opt-in) and censorship on > the other (opt-out and be blocked). Is that right? > > Designing mechanism for the Internet that allows/facilitates/encourages > the network operator to force this choice on the user seems problematic. > Why do we want this for a protocol like TLS that is intended to be used > across potentially adversarial networks? > > datacenter operators who want access to the cleartext passing through > machines they already control already have mechanisms at their disposal > to do this (whether they can do so at scale safely without exposing > their customers' data to further risks is maybe an open question, > regardless of mechanism). > > Mechanisms that increase "visibility" of the cleartext run counter to > the goals of TLS as an end-to-end two-party secure communications > protocol. > > Regards, > > --dkg > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 CDT's Annual Dinner, Tech Prom, is March 29, 2018. Don't miss the tech event of the year! Reserve a table today.: https://cdt.org/annual-dinner/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
On Mon, Mar 19, 2018 at 6:38 AM, Daniel Kahn Gillmor wrote: > On Sun 2018-03-18 12:08:13 -0400, Viktor Dukhovni wrote: > >> The devices that might use external PSKs will likely be unavoidably >> fingerprinted by source IP address and the target mothership. > > I'm not convinced that this is the case -- it's not at all clear that > IoT devices will be attached to a stable network (so the source IP may > change), and for large deployments, the devices might all share the same > "mothership". But the device might still present significant privacy > concerns (for example, if it's a device that travels with a person, its > presence on the network could be used to track that person). In addition to locative privacy threats, the nature of the IoT device itself might expose something sensitive about the user (e.g., a connected pleasure device, medical device, or solid platinum espresso maker). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG adoption call: draft-rescorla-tls-esni
support, will review On Tue, Jul 24, 2018 at 10:17 PM Joseph Salowey wrote: > > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. > But, we need to confirm this on list. If you would like for this draft to > become a WG document and you are willing to review it as it moves through > the process, then please let the list know by 2359UTC 20180807. If you are > opposed to this being a WG document, please say so (and say why). > > Note that the draft has been marked as a "Candidate for WG Adoption” in > the datatracker. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] SK filtering on SNI, blocking ESNI
It appears South Korea has started censoring traffic across all ISPs based on SNI [1], [2]. Nick points out that they seem to be blocking ESNI entirely [3]. [1]: https://bugzil.la/1494901#c3 [2]: https://news.joins.com/article/23363557 [3]: https://twitter.com/grittygrease/status/1095530153319358465?s=21 -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC5288 (4694)
s/it's/its/ in one place in your errata text, Aaron. On Tue, Jun 14, 2016 at 5:04 AM, Aaron Zauner wrote: > Hi, > > It's been a few weeks. We by now know of at least one other affected vendor. > I think this errata is valid and should be accepted. I'll take any feedback > and improvements if valid. > > Aaron > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Updated TLS-LTS draft posted
https://www.ietf.org/rfcdiff?url1=draft-gutmann-tls-lts-03&url2=draft-gutmann-tls-lts-04 On Sun, Jun 26, 2016 at 9:13 AM, Peter Gutmann wrote: > I've just posted the latest draft, as per Russ' comments and Hubert Kario's > suggestion this removes any mention of the term "profile" from the text, it's > now called an update. It also clarifies some issues that were encountered > during testing, for example what happens during a rehandshake and how > signalling of LTS vs. extended master secret and encrypt-then-MAC are handled. > > There's also an open question as to what should happen when a suite with e.g. > SHA-512 is negotiated. The LTS mandatory suites all use SHA-256, but it's > possible to negotiate a suite with SHA-512 while still using LTS. Presumably > this means the hash size will change to 64 bytes rather than 32. > > Finally, there's now a LTS test server available for interop testing, > temporarily using the next free extension value 26 until a value is > permanently assigned for LTS use, see the draft for details. > > Peter. > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
+1 On Wed, Aug 31, 2016 at 7:05 PM, Richard Barnes wrote: > I am in total agreement with Nick here. "TLS 1.3" accurately describes what > we're doing here, and it's consistent with our past naming scheme. > > There is no upside to changing away from 1.3, and as Nick notes, lots of > potential downside. > > --Richard > > On Wednesday, August 31, 2016, Nick Sullivan > wrote: >> >> I am reluctant to endorse a name change from TLS 1.3 to TLS 2.0. I see a >> few immediate issues with the proposal: >> - it causes confusion with SSL 2.0 >> - it implies wire incompatibility with TLS 1.2 >> - it suggests there will be a forthcoming TLS 2.1 with only minor changes >> >> If we're dead set on bumping the major version for a mostly backwards >> compatible protocol change, we should just drop the minor version and go >> with TLS/2. >> >> Nick >> >> On Wed, Aug 31, 2016 at 12:24 PM Bill Frantz >> wrote: >>> >>> We could call it TLS 3.4 which would match the internal ID. :-) >>> >>> BTW, I think using something other than 1.3 is a good idea. >>> >>> Cheers - Bill >>> >>> - >>> Bill Frantz| When it comes to the world | Periwinkle >>> (408)356-8506 | around us, is there any choice | 16345 Englewood Ave >>> www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 >>> >>> ___________ >>> 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 > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
Just want to +1 the notion that this should be opt-in for both sides and in an extension! On Sat, Jul 8, 2017 at 23:16 Nick Sullivan wrote: > Putting questions of whether or not this belongs as a working group > document, I think there are some necessary requirements for > intra-datacenter passive decryption schemes that are not met by this draft. > > Specifically, any passive decryption scheme should the following two > properties: > 1) Both server and client must explicitly opt-in > 2) A third party should be able to tell whether or not this feature is > enabled by observing the stream > > These two requirements protect services on the wider Internet from being > accidentally (or surreptitiously forced to be) subject to unauthorized > decryption. The static DH proposal satisfies neither of the above > requirements. > > What you likely want is something similar to TLS 1.2 session tickets with > centrally managed session ticket keys. The client would advertise support > for "passive session decryption" in an extension and the server would > return an unencrypted extension containing the session keys encrypted by a > server "passive decryption key". The passive decryption key would be > managed in the same way as the static DH key in this draft: rotated > frequently and synchronized centrally. > > A TLS 1.2 session ticket-like scheme provides the same semantics as this > static DH but provides more safeguards against accidental use outside the > datacenter. Both client and server need to opt in, it's visible from the > network, and limits the data visible to the inspection service to the > session (rather than exposing the master secret which can be used to > compute exporters and other things outside of the scope of session > inspection). Furthermore, in the session ticket-like scheme, a *public > key *could be used to encrypt the session keys, removing the need for a > secure distribution scheme for the endpoints. The passive decryption > private key could me managed in a secure location and only the public key > distributed to the endpoints. > > Session ticket-like scheme advantages vs this static DH proposal: > 1) Mandatory client opt-in > 2) Passive indication that scheme is being used > 3) Decryption service only gets session keys, not master secret > 4) No need for private distribution system for static keys to endpoints > > In summary, even if this was to be considered as a working group document, > I think this is the wrong solution to problem. > > Nick > > On Fri, Jul 7, 2017 at 8:03 AM Matthew Green > wrote: > >> The need for enterprise datacenters to access TLS 1.3 plaintext for >> security and operational requirements has been under discussion since >> shortly before the Seoul IETF meeting. This draft provides current thinking >> about the way to facilitate plain text access based on the use of static >> (EC)DH keys on the servers. These keys have a lifetime; they get replaced >> on a regular schedule. A key manager in the datacenter generates and >> distributes these keys. The Asymmetric Key Package [RFC5958] format is >> used to transfer and load the keys wherever they are authorized for use. >> >> We have asked for a few minutes to talk about this draft in the TLS WG >> session at the upcoming Prague IETF. Please take a look so we can have a >> productive discussion. Of course, we're eager to start that discussion on >> the mail list in advance of the meeting. >> >> The draft can be found here: >> >> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 >> >> Thanks for your attention, >> Matt, Ralph, Paul, Steve, and Russ >> ___ >> 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 > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] possible new work item: not breaking TLS
I also support both time here and a "let's put all the bad breaking TLS ideas in one draft". On Thu, Jul 13, 2017 at 17:52 Blumenthal, Uri - 0553 - MITLL wrote: > I support allocating a time slot for the arguments against the draft-green > (and similar/related approaches). > > I also support documenting the above arguments, possibly in a TLS WG draft. > -- > Regards, > Uri Blumenthal > > On 7/13/17, 08:00, "TLS on behalf of Stephen Farrell" < > tls-boun...@ietf.org on behalf of stephen.farr...@cs.tcd.ie> wrote: > > > Hi again TLS WG chairs, > > I've done a bit more work on the collection of arguments > against the latest break-TLS proposal. [1] I plan to keep > working on that so more input is welcome. (Corrections > where I've gotten stuff wrong are even more welcome.) > > I'd like to again request some time on the agenda to > allow discussion of those points in a more structured > manner than will be possible during the mic-line scrum > that'll likely follow a sales-pitch for draft-green. > > I'd also like to ask the WG if we think it'd be useful > to document the arguments against that and other "let's > break-tls" proposals we've seen in the past in an RFC. > If people think it would be useful, I'd be willing to > do work to edit such a draft, or help edit that. > > Thanks, > S. > > [1] https://github.com/sftcd/tinfoil > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!
Sean, can you let us know what room the new session will be in when you know? (Not on the agenda.) On Fri, Jul 14, 2017 at 4:08 PM, Sean Turner wrote: > >> On Jul 14, 2017, at 15:53, Blumenthal, Uri - 0553 - MITLL >> wrote: >> >> On Jul 14, 2017, at 15:51, Sean Turner wrote: >>> >>> And by the important business I was referring to the TLS and DTLS drafts. >> >> My apology. We’re in agreement then. > > No worries I should have been more explicit. > > spt > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 32 byte randoms in TLS1.3 hello's
On Mon, Jul 24, 2017 at 11:15 AM, Stephen Farrell wrote: > > > Hiya, > > I'm guessing many folks interested in TLS may have been > at the QUIC session in Prague and hence missed out on the > excellent talk by Stephen Checkoway on the juniper dual-ec > incident. (I highly recommend taking a peek at the slides [1] > or reading the paper [2] or watching the video wherever > that may be;-). Video of Steve's talk in the IRTF Open session is here and Steve begins around 52:15: https://www.youtube.com/watch?v=JRneMj7LX8U&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=52m15s -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
