Re: [TLS] DSA support in TLS 1.3.
On 8/28/15, Dang, Quynh wrote: > Hi all, > > > DSA is supported in the previous versions of TLS. It would be nice if > someone who uses DSA can use it in TLS 1.3 as well. > > > People who don't use DSA, then they don't use DSA. People who use DSA right, > it should be fine for them to use DSA. > > > I don't see a convincing reason to remove support of DSA in TLS 1.3. > What do you suggest for the construction of the k value in DSA? The old NSA backdoor that leaks the private key? Or perhaps a different NIST endorsed construction? All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On 9/16/15, Jeffrey Walton wrote: > On Wed, Sep 16, 2015 at 4:45 AM, Stephen Farrell > wrote: >> >> >> On 16/09/15 09:19, Peter Gutmann wrote: >>> Jeffrey Walton writes: >>> Somewhat off-topic, why does TLS not produce a few profiles. One can be "Opportunistic TLS Profile" with a compatible security posture and include ADH. Another can be a "Standard TLS Profile" and include things like export grade crypto, weak and wounder ciphers SSLv3, etc. Finally, there can be a "TLS Defensive profile" where you get mostly the strong the protocols and ciphers, HTTPS Pinning Overrides are not allowed so the adversary cannot break the secure channel by tricking a user, etc. >>> >>> +1. At the moment you're stuck with everything-all-the-time (or >>> alternatively >>> one-size-misfits-all) where you have to support every single mechanism >>> and >>> quirk and add-on, when all you want most of the time is to set up a >>> basic >>> secure tunnel from A to B. Having profiles would be a great help, so all >>> the >>> other standards groups that build on TLS can refer to, say, the >>> emebedded- >>> device profile or the PFS-with-PSK profile rather than having to hack >>> around >>> the standard themselves. >> >> We have BCP195 [1] that aims for the "general" case (for >> up to TLS1.2) and a draft [2] (current in IESG evaluation) >> for the embedded case. Are those the kind of thing you're >> after? >> >> If so, and you wanted more, the UTA WG [3] (which produced >> BCP195) would maybe be the best place to see if there's >> enough interest in doing more. (The embedded one was done >> in the DICE WG [4] which was setup mostly for that as it's >> to some extent a different set of folks. And that could be >> done again if needed.) >> > This kinda begs the question, who should be responsible for high level > TLS configurations to ease management, maximize security and minimize > interoperability issues. Isn't that the goal of a reasonable protocol, generally? > For that, I'd argue it falls squarely within TLS WG purview. > > One of the things I've noticed (maybe incorrectly): the NSA and other > who want to exert influence do not have to influence a group like the > TLS WG.* None the less, they (NSA) work to do exactly that for various aspects of the IETF. > There's enough mass and dissension that weakening is organic. > A small selection of profiles could be a strategic move to cut-off > that avenue if it is being taken advantage of. Why not design a protocol that is secure regardless of how it is deployed absent issues with entropy? > Strategic planning is something that should to be led by leadership. Democratic participation is strategic - positions of leadership are subject to capture. Should we really follow the leadership when sometimes they are literally paid by the NSA? > Jeff > > * Maybe I should say, "not actively influence them", like the case of > RSA Data Securities and the Dual EC generator. Those were ECI BULLRUN (and friends) and thus very much active. The IETF is targeted by FVEY (and likely others) for human infiltration and considered fair game. Lots more about BULLRUN remain to be found, I'm sure of it. All the best, Jacob ___ 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 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 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
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Dear Bryan, On 11/30/15, Bryan A Ford wrote: > Thanks Bill for the feedback. > > On 11/29/15 6:11 PM, Bill Cox wrote: >> Thanks for the detailed description of why we might want to obfuscate >> TLS record lengths. From a security point of view, the only potential >> attack vector this might create is that the attacker will know in many >> cases the plain text of the first 5 bytes. A weakness in the stream >> cipher might be more easily exploited in this case. IIUC, we feel >> pretty good about the latest AEAD ciphers, and guessing the clear text >> of many bytes in the record already is not too hard. Is that right? >> So, from my fairly uninformed point of view, this seems like a >> reasonable upgrade. > > Just a nitpicky semantic correction: my proposal doesn't "create" the > attack vector you describe (that the attacker will know the plaintext of > the 5-byte header). That weakness is already there in TLS 1.3 as > currently specified, because the TLS header is unencrypted so the > attacker will *definitely* know the 5-byte header. :) This is merely an > existing weakness that is not fixed by my proposal. That is my read as well. I think your proposal sounds pretty interesting. >> I have one concern. These same boxes that hide record lengths by >> merging and breaking up packets arbitrarily likely would deliver the >> packets not well aligned to record boundaries. Is this already the >> case? > > It's already the case that middleboxes of various kinds re-segment > (merge and break up along different boundaries) TCP streams for various > reasons, often as an unintentional side-effect of interposing on the > stream by "accepting" the TCP connection (pretending to be an endpoint) > on one of the middlebox's interfaces and opening a new outgoing > connection on the other interface, and just forwarding the traffic > between them. In fact, Performance Enhancing Proxies (PEPs) are one > class of middlebox that often do this intentionally, so they can get > better control over and fiddle with the way congestion control works > over "troublesome" types of links like high-bandwidth-delay-product > (e.g., satellite) links. > >> If these boxes currently inspect packets when breaking them up to >> split packets along record boundaries, encrypting the lengths will >> defeat this efficiency hack. We might cause an increase in network >> latency in this case. Do any of the routers out there currently use the >> record length field when splitting up packets? > > If I understand your question correctly, you're asking if encrypting TLS > record lengths might break middleboxes that currently want to track TLS > records for some reason, e.g., perhaps to re-segment the TCP stream to > correspond to TLS records (which might "fix" or "revert" the effect of > another middlebox in the path that re-segments TCP in a TLS-oblivious > fashion). I don't know of any middleboxes that do precisely this, but > it's not inconceivable that they could exist. Why would that concern anyone other than to help an attacker? If my ISP requires me to use such a box, I should use it as a proxy or configure it manually. If they use it on me without my consent, it is an attack. I want TLS to break and to do so in a way that fails closed. If another ISP, backbone ISP, or XKeyscore would have a harder job, I fail to see why we should care at all. They're the adversary, we should not give them anything. We should make their job as difficult as possible technically as well as in most other ways as well. I have no sympathy for the what-about-poor-NSAT&T's-big-networks of the world. > More generally, since basically all manner of evil/broken middleboxes do > exist, it's entirely possible that most any change to TLS's wire > encoding *could* disagree with some middleboxes. That's not specific to > the change I'm proposing; any wire-visible change could trigger unknown > middlebox badness. The only solution to this I'm aware of is empirical: > try the change, deploy it experimentally at first, and see what the pain > level is, i.e., see if we find any middleboxes that complain and if so > how prevalent they are. But since TLS 1.3 is already changing a lot of > other prominently wire-visible stuff with respect to prior versions of > TLS that might equally well break middleboxes, it's not clear that my > proposed change in particular is more likely to cause pain than any of > the other changes already made, and in general I don't think we should > let a few broken/evil middleboxes prevent meaningful evolution of the > TLS protocol. > Agreed entirely. TLS should also be able to be composed with anonymity networks in a way that we solve complementary problems, as you've said. The less a hostile Tor exit can learn about a person's TLS 1.3 flow, the better. One could even imagine a key setup over one Tor circuit and then a seemingly unrelated connection using the negotiated key over another Tor circuit. In an ideal world, we'd have two basic
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 11/30/15, Hubert Kario wrote:
> On Monday 30 November 2015 10:58:48 Bryan A Ford wrote:
>> On 11/30/15 2:40 AM, Peter Gutmann wrote:
>> > Nikos Mavrogiannopoulos writes:
>> >> I believe your proposal is a nice example of putting the cart
>> >> before the horse. Before proposing something it should be clear
>> >> what do you want to protect from, what is the threat?
>> >
>> > Exactly. If you want to thwart traffic analysis, you need to do
>> > something like what's done by designs like Aqua ("Towards Efficient
>> > Traffic-analysis Resistant Anonymity Networks"), or ideas from any
>> > of the other anti-traffic- analysis work that's emerged in the past
>> > decade or two.
>>
>> I'm well aware of Aqua and "the other anti-traffic-analysis work
>> that's emerged in the past decade or two": in fact I led one of the
>> major recent systematic projects in that space. See for example:
>>
>> http://dedis.cs.yale.edu/dissent/
>> http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-an->
>> internet-panopticon/fulltext
>> > You get traffic
>> > analysis resistance by, for example, breaking data into fixed-length
>> > packets, using cover traffic, and messing with packet timings, not
>> > by
>> > encrypting TLS headers.
>>
>> Packet padding and header encryption are both important, complementary
>> security measures: you get security benefits from each that you don't
>> get from the other. Yes, you need padding to obtain systematic
>> protection from traffic analysis - when for whatever reason not all
>> implementations are always padding to the exact same standardized
>> record length, header encryption makes padded streams less trivially
>> distinguishable from unpadded streams, and makes streams with
>> different record sizes less trivially distinguishable from each
>> other.
>
> the header contains only one piece of information, and it is public
> already - the amount of data transmitted*
I'm pretty sure TLS has a lot more data...
> If you want to hide how much data was transmitted, you need to establish
> a tunnel that transmits data constantly, at the exact same rate for the
> whole duration of connection.
>
...
> that means that you need to know a). what bandwidth the client has, b).
> what bandwidth the server can spare and c). how much data the user wants
> to get or send to the server (I really don't want to transmit 1GiB of
> data over a 100KiB/s stream if I have a 100Mbps link...).
>
...
> this goes well past the TLS WG charter, if only because it requires very
> close cooperation with the application layer
>
> so while the padding mechanism should be there, we really can't describe
> how it needs to be used, as it can't be made universal nor is it
> necessary for all use cases
>
I think it should be described how it needs to be used...
> * - sure, the record layer boundaries can tell something about the data
> being transmitted, but so can the presence of data transmission taking
> place in the first place (think of a station sending reports only when
> it detects something while keeping connection open the whole time)
>
Yes, they tell something and that something is better removed.
>> One thing that would greatly help Tor and all similar,
>> padded protocols is if they could "blend in" even just a little bit
>> better with the vast bulk of ordinary TLS-encrypted Web traffic, and
>> that's one of the big opportunities we're talking about here.
>
> the initial message in handshake in TLS MUST stay the same thus it is
> impossible to make it look like Tor. Not to thwart the Pervasive
> Monitoring threat of TLA agencies.
That Tor claim is strange and seemingly false in any case. Also, I've
said it before quoting the RFC but I'll say it again: Pervasive
Monitoring is an attack.
>> If you think it is practical for the TLS 1.3 standard to specify a
>> single, fixed record size that all implementations of TLS 1.3 must use
>> (i.e., explicitly freeze not only the version field but the length
>> field), then that would be great for traffic analysis protection and
>> on that basis I would support that proposal. But that frankly seems
>> to me likely a bit too much to ask given the diversity of TLS
>> implementations and use-cases. Tell me if you believe otherwise.
>
> That will just round up to a multiple of 256 bytes the data sizes
> transmitted. Hardly an improvement over the current 16 byte blocks.
>
Closer to 512 bytes is better.
All the best,
Jacob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/1/15, Viktor Dukhovni wrote: > On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote: > >> Bryan A Ford writes: >> >> >It would work just as well and in exactly the same way if the AEAD is >> >replaced with the traditional Encrypt-then-MAC construction, for >> > example. >> >> No it wouldn't, unless the encrypt part is a stream cipher. You're still >> locked into using an AEAD stream cipher or the equivalent of an AEAD >> stream >> cipher built with encrypt+MAC. It won't work with, for example, the OCB >> AEAD >> mode, or CBC + MAC. > > I think we should focus on what would get TLS 1.3 to be adopted: > > * Reasonably implementable in libraries that support older > versions alongside TLS 1.3. > That doesn't change with Bryan's suggestion, I think. > * Interoperable in the field with various capital-intensive > middle boxen. Which would those be? And what is the definition of capital-intensive for those watching on the sidelines? > > This suggests focusing on solidifying the core protocol, and a > healthy dose of skepticism around bells and whistles. If the > protocol is overloaded with too many (alright even more) incompatible > innovations, the net effect is likely less security due to > substantially delayed deployment of the key improvements. This seems borderline absurd. The TLS protocol is doing a major version revision. > Encrypting message lengths looks rather marginal from this perspective, > and quite likely to hinder interoperability and delay both > implementation and upgrades. However cool an idea this might be, > this does not look to me like the right time to add this feature > to TLS. I don't think it will hinder interoperability and not one person has even named a single device that would have issues with it. I think the only thing that comes close is when I've named a classified US government surveillance program (XKeyscore) that would probably have trouble with it. We should add Bryan's feature and not pander to non-specific concerns about middleboxes that should be considered as adversaries. > > At this point, TLS 1.3 is rather feature rich, and it is I think > time to focus on reviewing the already agreed changes (maybe even > drop some if they look inessential). Make it solid, trim the fat, > get it out the door in a usable form. That is part of what is happening in Bryan's suggestion. He found a reasonably practical way to encrypt record headers. His suggestion will make TLS more secure. His suggestion includes a review of a part of the previous state of TLS 1.3 with a proposed improvement. No one is debating it on the cryptographic merits which is surprising. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/1/15, Yoav Nir wrote: > >> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote: >> >> On 12/1/15, Viktor Dukhovni wrote: >>> On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote: >>> >>>> Bryan A Ford writes: >>>> >>>>> It would work just as well and in exactly the same way if the AEAD is >>>>> replaced with the traditional Encrypt-then-MAC construction, for >>>>> example. >>>> >>>> No it wouldn't, unless the encrypt part is a stream cipher. You're >>>> still >>>> locked into using an AEAD stream cipher or the equivalent of an AEAD >>>> stream >>>> cipher built with encrypt+MAC. It won't work with, for example, the >>>> OCB >>>> AEAD >>>> mode, or CBC + MAC. >>> >>> I think we should focus on what would get TLS 1.3 to be adopted: >>> >>>* Reasonably implementable in libraries that support older >>> versions alongside TLS 1.3. >>> >> >> That doesn't change with Bryan's suggestion, I think. >> >>>* Interoperable in the field with various capital-intensive >>> middle boxen. >> >> Which would those be? And what is the definition of capital-intensive >> for those watching on the sidelines? > > Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on > protocols to make sure that the stuff going over TCP port 443 is really > HTTPS rather than an attempt at tunneling. There are some attacks such the > the code that protects against them needs to follow TLS record sizes. For > the most part these are not-so-interesting attacks, causing certain versions > of certain browsers to hang, and they are expensive for the firewall to > protect against, so for the most part these protections are turned off. But > it’s not everywhere. Could you be more specific? Which devices are we saying will break? Do you have model numbers? Are those vendors on this list? Do they agree that this will break and do we agree that they are a relevant stakeholder who has a user's security in mind? For example, do we really care what sandvine or xkeyscore or narus or similar vendors think? I think the answer is no. They're still going to do extremely powerful traffic analysis and the more information TLS leaks, the more they will use it to degrade the security of TLS for all users. It may be that they will be full, on path, attackers and yes, in some cases, they can do different more powerful attacks. Again, we should treat that as a negative thing and make it as hard as is possible. > > If enough middleboxes block TLS 1.3, the browsers will implement a downgrade > dance. If they do that, attackers will be able to exploit the downgrade > dance. I don’t think the net effect is better security. We’d be far better > off writing a separate document on how to use the padding feature that is > already in 1.3 to mitigate traffic analysis without actually flooding your > Internet connection. Splitting records and padding a few can be more > effective than masking the length bits. Censors are going to perform surveillance and then censor; TLS 1.3 should treat surveillance as a security issue and censorship as an attack. It may be that we can't stop certain kinds of on path attacks but man on the side seems nearly entirely do-able. I mean aside from the TCP reset issues do to layer violation concerns. At least we'll have DTLS, which won't suffer from such a trivial denial of service... right? All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>I think the only thing that comes close is when I've named a classified US >>government surveillance program (XKeyscore) that would probably have >> trouble >>with it. > > Why would XKeyscore have trouble with it? My point was that we're hearing a lot of concern trolling for vendors and the only "vendor" that has been explicitly named is XKeyscore: a "vendor" that is without a doubt one that we want to protect against. > Standard off-the-shelf routers, > not > even specialised USG surveillance gear, does fairly sophisticated flow > tracing, packet reassembly, connection analysis, and so on. It's built into > the router. Absolutely and this proposal will do nothing to change that for on path TLS 1.3 with TCP and probably for TLS 1.3 DTLS. > Encrypting the headers is, at best, a minor speedbump to > attackers (while being a major headache for implementers, particularly SSH's > way of doing it), because they can use the native capabilities of the > routing > hardware to sidestep the need to decrypt headers. If they are only a partial observer, I think Bryan's suggestion changes the game for TLS and DTLS to leak less information. If they are a full on path observer, they will have the full leaks of information made possible from TCP. Thus when composed with an anonymizing service, we'll find that these changes contribute to a full solution. > > If people really want to address this then they need to do the following: > > 1. Define a threat model. What are we supposed to be defending against? > >(Note: The Inside-Out Threat Model, "this is the defence, anything that > it >prevents is what we're defending against", is not a threat model). > > 2. List the various measures that can be used to defend against the threat: >Fixed-size packets, padding, quantised packet timing, etc. > > 3. Decide on which ones are necessary to defend against an actual threat, > and >which ones aren't, taking into account cost/benefit tradeoffs (is the >effort/overhead involved worth the gain?). > > 4. Provide guidance for TLS and SSH developers on how they can implement >these. A global passive adversary with a partial view is already harmed by the changes that have been proposed. A global active adversary with a partial view would be stymied too. Bryan has already said it in the thread and replied but I'll agree with him: we've done it and you're seemingly ignoring it. Furthermore some people are concerned about surveillance vendors that are not *opt-in* by the user - rather than treating that concern as abstract, I'd like to see what specific vendors we should help to weaken the security properties of TLS 1.3. > > Once that's done (and in particular #1 and #2), we have a framework within > which we can decide whether encrypting lengths is worth the annoyance it > creates for implementers. > I think this is better left in the part of the thread where Bryan responded - so I'll follow up there next. > Without this, the debate over encrypted lengths is, to quote Linus, nothing > more than "people wanking around with their opinions" (and yeah, that > includes > me). It is not an opinion that TLS is a metadata leaking protocol and it is seems that Bryan has found a way to reduce that leakage. With DTLS and UDP - a surveillance vendor will have very little metadata comparatively once Bryan's solution is part of the spec. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Yoav Nir wrote: > >> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum wrote: >> >> On 12/1/15, Yoav Nir wrote: >>> >>>> >>>> Which would those be? And what is the definition of capital-intensive >>>> for those watching on the sidelines? >>> >>> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on >>> protocols to make sure that the stuff going over TCP port 443 is really >>> HTTPS rather than an attempt at tunneling. There are some attacks such >>> the >>> the code that protects against them needs to follow TLS record sizes. >>> For >>> the most part these are not-so-interesting attacks, causing certain >>> versions >>> of certain browsers to hang, and they are expensive for the firewall to >>> protect against, so for the most part these protections are turned off. >>> But >>> it’s not everywhere. >> >> Could you be more specific? Which devices are we saying will break? Do >> you have model numbers? Are those vendors on this list? Do they agree >> that this will break and do we agree that they are a relevant >> stakeholder who has a user's security in mind? > > I am no expert on middleboxes. I know a little about those that my employer > (Check Point) makes. I only know a little, because I’m on the VPN side of > things, not the IDS/IPS/next generation firewall side. I don't think we should worry about breaking poor little Check Point's traffic analysis devices. Allow me to shift the overton window: their device is a problem and we should treat it as a problem on the network. TLS should mitigate as many of the advantages that they use to harm end users. We should make those devices use as much RAM and as much disk space and as much CPU time as possible. In the words of a Google engineer who discovered the NSA had been doing traffic analysis on his backbone... > These are corporate > firewalls. When it comes to filtering HTTPS connections, firewalls have > three ways to classify the connection: > 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. > 2. #1, and additionally follow the stream looking for certain patterns. > 3. Full “TLS proxy”. > > > Each of these is “heavier” in amount of resources that it consumes and in > the amount of breakage that it might introduce than the one before it, so > you only use a higher-numbered way if the lower-numbered way does not give > you the results you need. Specifically for #2 which is the one we’re > concerned about, there are very few attacks that can be detected by #2 that > cannot be detected by #1. I asked someone who does work on these > “protections” as we call them, and she told me that only two or three > protections require following the stream that do not require proxying, and > those were turned off in the default and recommended profiles. So at least > with a Check Point firewall, mostly you would not get breakage if record > lengths were encrypted, but someone making a client or a server cannot > assume that all paths will be free from such inspection. Also, there are > many firewall vendors and one is installed in most corporate environments. That sounds like you're saying that the vendor you represent won't have issues and that it isn't a problem. Unless I misunderstand, you're claiming a concern and you've just cleared up that concern. So we can move on with Bryan's proposal? > So at least one vendor is listening in on this list, and I have a good hunch > that at least Cisco, Blue Coat and several others are on this list as well. I'd love for Blue Coat to step up and talk about how this is similarly not a problem or how it is a problem for their illegal surveillance business in Syria, where they've been caught selling surveillance and censorship gear. I suspect they won't say much but we can hope, right? > Whether they are relevant stakeholders or not is to me the same question as > whether the network administrator in a corporate environment is a relevant > stakeholder. We just make the middlebox that they deploy. That is a kind of goal post shifting but seeminly weirdly not relevant, if I understand. If it won't trouble the middle box, it doesn't sound like the network administrator will have troubles. It will however reduce off-path reassembly to technique #1 from above and #2 will be partially eliminated and #3 isn't an option for that attacker anyway. We are working on solutions to #1, TLS 1.3 should reduce and if possible, eliminate #2, and #3 is something that should require consent of the user in question. Without consent, TLS 1.3 should hard fail closed as a security measure. >> For example, do we real
Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote: > >> On 02 Dec 2015, at 06:02, Martin Thomson >> wrote: >> > On 1 December 2015 at 08:22, Bryan A Ford >> > wrote: >> >> The 2-byte length field in each record's header no longer indicates >> >> the length of the *current* record but instead indicates the length of >> >> the *next* record. >> > >> > Ensuring that you know the length of the *next* record is difficult >> > and could dramatically degrade latency, or adding extra bogus padding >> > or extra bogus records. For instance, I can always send in bursts of >> > two packets, a one octet packet that promises the remainder of the >> > burst and one that promises a single octet packet. At that point, I >> > get to do what I've always done and you have gained little other than >> > an increase in packet size of around 19 octets (best case). >> >> That type of inefficiency is extremely easy to avoid; please read the >> rest >> of my proposal where I discussed exactly that at length. Yes, a >> particularly stupid implementation could send everything in bursts of two >> packets, but it’s ridiculously easy for a slightly smarter implementation >> to avoid doing that. And what you’ve gained is complete encryption and >> integrity-checking of the whole TLS record before any part is >> interpreted, >> which seems like a nontrivial security improvement. > > > It's not really clear to me what the anti-traffic-analysis benefit of your > proposal > is over and above just padding everything to a fixed size. That's certainly > far > easier for the implementation to do, especially in typical stacks where the > application just calls SSL_Write (or whatever) and so there's no obvious > API point to provide the "next length", so as a practical matter the stack > will very often if not always be in "last block" mode. > I think that it eliminates all static distinguisher in the protocol for all data covered by the encryption. That is a fantastically wonderful benefit. > The primary security improvement of your proposal seems to be that an > active attacker can't generate a packet header that will put the TLS > implementation in a deadlock state where it's waiting for more data that > will never come. This seems of modest value in TLS [0] given that the > attacker > can cause the connection to be torn down by modifying any packet. > I agree, that this is not exactly the same as leaving the connection > deadlocked > but it still effectively breaks the connection. In addition, I'm not an > expert on TCP internals, but can't you also cause a similar deadlock by > removing a TCP segment sent to the receiver and then ACKing it to the > sender so that there is a gap in the TCP stream? Yes, any TLS connection may be broken by TCP's total lack of confidentiality, integrity or authenticity. It seems that normally this happens at setup by IP:port blocking or during later transmission of a selector/distinguisher that triggers an attack (TCP RST or others). There is good work in this area by David Stainton with his Honeybadger project - he actually classified and implemented most of these TCP attacks to help detect QUANTUMINSERT attacks in the wild: https://www.noisebridge.net/pipermail/noisebridge-discuss/2015-April/046273.html > > -Ekr > > [0] This issue doesn't apply to DTLS because the stack will just move onto > the next UDP datagram. An off-path attacker can't do much with DTLS, if designed correctly. Especially if they only see some packets - they'd only get the UDP headers and then the rest should be uniformly distributed random data, no? An attacker could thus only interfere during setup - which if they're on path - we can't stop and expect; the PKI should (ha!) help with this issue. After that point, especially with devices that move or are otherwise multi-homed, would be able to spray encrypted packets out to the network with little other than the UDP headers for an attacker to use. Bryan's proposal makes things strictly better with regard to a network attacker - especially a partial view or off-path attacker who can only inject packets or who require a selector to trigger an attack. Effectively, an attacker will be forced to shut down the connection at setup time or to use the layer separation issues with TCP at any point. The key difference is that they will have the same information as they did at setup time, which again seems as a strict improvement over the current status quo. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Mike Copley wrote: > > On 2/12/2015, at 1:38 pm, Yoav Nir wrote: > >> >>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum wrote: >>> >>> >>>> These are corporate >>>> firewalls. When it comes to filtering HTTPS connections, firewalls have >>>> three ways to classify the connection: >>>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. >>>> 2. #1, and additionally follow the stream looking for certain patterns. >>>> 3. Full “TLS proxy”. >> >>>> Whether they are relevant stakeholders or not is to me the same question >>>> as >>>> whether the network administrator in a corporate environment is a >>>> relevant >>>> stakeholder. We just make the middlebox that they deploy. >>> >>> That is a kind of goal post shifting but seeminly weirdly not >>> relevant, if I understand. If it won't trouble the middle box, it >>> doesn't sound like the network administrator will have troubles. >>> >>> It will however reduce off-path reassembly to technique #1 from above >>> and #2 will be partially eliminated and #3 isn't an option for that >>> attacker anyway. >>> >>> We are working on solutions to #1, TLS 1.3 should reduce and if >>> possible, eliminate #2, and #3 is something that should require >>> consent of the user in question. Without consent, TLS 1.3 should hard >>> fail closed as a security measure. >> >> A TLS proxy requires user consent (or at least device administrator >> consent) with TLS 1.2. TLS 1.3 does not change that. > > With SNI it’s possible to operate a transparent TLS proxy without the users > consent. The proxy only has visibility of the SNI hostname - no user data > (source: the company I work develops routers with such a proxy). Yes, we use that for a pluggable transport ( https://trac.torproject.org/projects/tor/wiki/doc/meek ) to bypass such proxies - connect to google.com, use http header to route to blocked.com, and so on. > It’s quite > useful in hotspot/public wifi environments where making policy decisions > based on hostname is more than sufficient, and explicit user configuration > of proxy settings is a non-starter. That is an attack in my book and public hotspots that do MITM are also a problem that we need to solve. It is partially solved with WISPr XML, I think. Though everything in this space is awful because it breaks everything by default while a system thinks it is online. > As long as the SNI data is still > available in the clear, encrypting subsequent headers won't impact the > ability for our particular proxy to operate, as it’s just a generic TCP > relay agent at that point. I hope that we'll hide the SNI data by default and I understand that a discussion about encrypted SNI is currently scheduled for some point in the future. > With all that being said, I think the concerns about length hiding are > better addressed through other means rather than header encryption. Not sure > if this is the right place to consider, but would DTLS 1.3(?) be able to > encrypt headers and still handle packet loss and re-ordering? If DTLS needs > cleartext headers, would it be better to advise one approach for both > protocols? I'm pretty sure that encryption is the only way to "hide" the data we want to hide... All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir wrote: >> >> I don’t think Bryan’s proposal will hurt the capabilities of a Check >> Point >> firewall, and it will make life difficult for me as a developer no more >> than it will make life difficult for developers of OpenSSL, NSS, >> SChannel, >> or any of a dozen other TLS implementations. I don’t know about the other >> IDS/IPS/Firewall devices. >> > > The people who will be inconvenienced (if any) by changing the record > framing in an > externally visible way are not largely developers of middleboxes or stacks > but > rather (1) users and (2) client vendors and (3) server operators, who have > to > deal with connections being arbitrarily broken and/or damaged by inspection > devices which expect to be able to observe packet framing. Those are also exactly the same parties that benefit from the changes. Other people who benefit are ISPs, who can't log data that encryption prevents them from seeing, and there are probably others too. > > In Seattle, when the topic of stripping off the fixed three bytes of the > record > header came up (which would have had a similar impact), we agreed to defer > it until we had measurements for the level of breakage that it would cause > (an experiment which we at Mozilla are on the hook for). It seems to me > that > this question should be handled similarly. How can it break something that doesn't yet exist and how can we measure that? o_0 Again, I'm surprised that no one is attacking the crypto design that Bryan offered... All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Martin Rex wrote: > Jacob Appelbaum wrote: >> >> I hope that we'll hide the SNI data by default and I understand that a >> discussion about encrypted SNI is currently scheduled for some point >> in the future. > > Hiding SNI data is completely silly security-wise, and any TLSv1.2 > backwards-compatible ClientHello must include a plaintext visible SNI. > Not hiding SNI data is completely silly security wise. SNI data is used by attackers to perform denial of service attacks and to automate man-in-the-middle attacks. We have bare keys in TLS that may also be ephemeral - why would we want to reveal a selector to the network that we know is used for active attacks against the protocol? The question for a few people, myself included, is how we might protect the SNI data in an efficient manner. > So your client will have to know a-priori, out-of-band or be configured > to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello > with cleartext SNI. > I think that is false. One could easily use the "cleartext" SNI field and insert an encrypted value. A hash of the name would be a simple example but not a secure example, of course. To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less secure and in ways that will only become worse over time. We should remember that TLS 1.3, while not yet finished or deployed, is a future legacy protocol. We shouldn't burden the future with the failures of TLS 1.2 or any other SSL/TLS mistakes of the past. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Salz, Rich wrote: >> I think that is false. One could easily use the "cleartext" SNI field and >> insert an encrypted value. A hash of the name would be a simple example >> but not a secure example, of course. > > Encrypted SNI doesn't give you the kind of protection you think that it > does. We (me and a colleague) did a pretty thorough analysis that showed > this. It was not a conclusion we expected, or wanted, to reach. It was > presented at the TLS Interim before the IETF in Toronto. Slides should be > online. (For example, the adversary will know the IP address or might not > care about false positives, etc.) > Without a concrete proposal, I don't think we have any protection. My thoughts were more about the idea that we would *want* protection of SNI data - it seems blindingly obvious to me that we want it as we know SNI is used for attacks in addition to multi-homing tricks. I'm aware that layer issues make for many layers of selectors for attack. If we can avoid adding them in TLS, we can also work on improving things on every level. IP address blocking has the "collateral freedom" problem, of course. > In spite of this, another colleague (Brian Sniffen) came up with a way to do > it at the tail end of the Seattle interim. Encrypt the "true" SNI in the > semi-static DH key of a "fronting" site. And then the front decrypts the > true SNI and forwards to the obscured site. Ekr and dkg presented it in > Yokohama, but not very well. :) They're presumably working on something > better. > I'm certainly interested in reviewing any cryptographic details for a possible SNI protection scheme. It sounds interesting and am looking forward to learning more. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Salz, Rich wrote: >> it seems blindingly obvious to me that we want it > > Few things, particularly in the security arena, are blindingly obvious. If > it actually provides no true protection, then it's just as bad as the > security theater in US airports. It provides protection. Specifically it provides confidentially. It doesn't solve the fact that the DNS is a privacy violating nightmare. It doesn't change the fact that the NSA breaks the rules. > >> If we can avoid adding them in TLS > > We're not adding anything as SNI is already in plaintext. (Precision > counts:). And we have already added numerous important privacy protections > to TLS 1.3. Leaving SNI in the clear ensures that attackers will be able to selectively block access by name with ngrep and some basic TCP RST injection. No cryptographic attacks are required and it will be done by simply looking for an objectionable string. The economics of that attack are very low. Forcing an attacker to become a global active or passive adversary and to perform competent traffic analysis is a much higher economic cost. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Martin Rex wrote: > Jacob Appelbaum wrote: >> On 12/2/15, Martin Rex wrote: >>> >>> So your client will have to know a-priori, out-of-band or be configured >>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello >>> with cleartext SNI. >> >> I think that is false. One could easily use the "cleartext" SNI field >> and insert an encrypted value. A hash of the name would be a simple >> example but not a secure example, of course. > > No you can NOT do this (in TLSv1.2 and earlier), because it is entirely > backwards-incompatible. If I configure a vhost to respond to a sha1(example.com) and have a way to visit sha1(example.com) in a browser, I think it doesn't even break the spec. That doesn't really matter - the point was to suggest that there are many ways to solve this problem. Assuming a shared key, we can easily take a field and transform it. There are compelling reasons to do it and there are active attackers who are exploiting the lack of confidentiality in TLS. > > Server-side SNI can even be implemented completely outside of the TLS > protocol stack (that is how I implemented it). I'm curious - are you saying that if the value was encrypted... it would become impossible to implement it outside of the TLS protocol stack? Or is this just an aside? > >> >> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >> secure > > That is a myth. Are you asserting that TLS 1.3 will be less secure or equally secure here? >> >> and in ways that will only become worse over time. We should >> remember that TLS 1.3, while not yet finished or deployed, is a future >> legacy protocol. > > TLSv1.3 is looking more and more like a future market failure to me, > worse than IPv6. Without privacy on the internet, I'll see your market and raise you a TCP RST. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/2/15, Dave Garrett wrote: > On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote: >> Encrypted SNI doesn't give you the kind of protection you think that it >> does. We (me and a colleague) did a pretty thorough analysis that showed >> this. It was not a conclusion we expected, or wanted, to reach. It was >> presented at the TLS Interim before the IETF in Toronto. Slides should be >> online. (For example, the adversary will know the IP address or might not >> care about false positives, etc.) > > URL from Rich's previous email citing this: > https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view > I've read these slides. I'm... at a bit of a loss. The entire slide deck seems so flippant as to be not worth addressing. It just doesn't even pass the giggle test. Though upon reading it, I am struck by two core points: One is that big companies will be pressured by governments. Ironically, Akamai isn't one of those as they're willingly in bed with governments around the world. But I guess as the slides say, the author isn't speaking on behalf of Akamai. That said - good, I want governments to have to go to a company rather than to the user - the company may have a legal team, the user may have hidden or otherwise protected themselves. Hopefully the company is in a position to do nothing or will take action to protect the user's basic liberties. The second is a constant security nihilism. Yeah, a lot of stuff is broken - so lets acknowledge it bit by bit and then fix it all. I would encourage everyone to read the slides as the conclusion in the presentation simply do not follow. If I had been in the audience when they were presented, I would have been at the microphone objecting. The idea that this convinced anyone is baffling. It is clear that privacy concerns exist in many many different protocols and that many protocols need to be fixed. Many people point at other protocols as a way to punt on the issue for their own protocol. The cycle continues and the privacy violations continue without end. > Please don't brush this argument off in favor of the "obvious" answer that > encrypted SNI is helpful. The sad truth is that it's a lot of effort with a > lot of risk for virtually no gain. I was quite in favor of encrypted SNI > before reading it, and I had to concede the point after. If we can come up > with a way to do it easily, ok, but it's not an avenue worth spending too > much time on. > The idea of splitting the world, as the slides do, into three basic camps (liberal democracy with good traffic analysis, liberal democracy with bad traffic analysis and horrible dangerous places) is simply not serious. The idea that our liberal democracies do perfect traffic analysis and so we should ensure *everyone* including *non-NSA* attackers can do it for *free* is just bizarre to me. It is incorrect as a conclusion to do nothing because some people somewhere *may* be good at traffic analysis. The logic of the slides suggest that raising the cost from a kid-in-a-cafe to NSA is proof that we shouldn't bother. Again, the security nihilism monster appears. We should reject this nihilism and fix the problem. Encrypted SNI makes sense as it makes traffic analysis harder. Encrypting DNS queries makes sense too. Composing it with other systems may or may not make sense. Even when TLS is composed with a tool to do traffic analysis resistance, the exit node of the TA-resistance network can still do selective attacks based on SNI. In that case the DNS is likely to be resolved at a different exit point. Thus if we want to punt again and say, hey, traffic analysis resistance is better left to Tor or something else, please consider that plaintext selectors make Tor's job harder. These changes make it more expensive and in some cases, it will stop attackers who would otherwise be able to make an attack happen undetected. It requires an attacker to spend more money on CPU, memory and on other resources to do correlation across multiple collection points. Kicking the can down the road doesn't even begin to summarize why leaving SNI unencrypted is incorrect. Metadata is a serious problem and reducing it whenever possible (eg: we won't fix TCP/IP on the IETF TLS list), even in liberal democracies, helps to solve the problems we face from mass surveillance. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/3/15, Salz, Rich wrote: >> It provides protection. Specifically it provides confidentially. > > It is far from clear that the privacy gains anything in the form of > practical protection. Having looked at it, I'm unconvinced. And I've been > a privacy/crypto advocate for a very very long time. > I resolve DNS through Tor and so in that case, my TLS connections often exit over a different circuit. My TLS connection would not otherwise leak the host I'm requesting if the protocol had a way to protect that data. It doesn't. The protocol leak is the problem. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/3/15, Eric Mill wrote: > On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum > wrote: > >> On 12/2/15, Salz, Rich wrote: >> >> it seems blindingly obvious to me that we want it >> > >> > Few things, particularly in the security arena, are blindingly obvious. >> If >> > it actually provides no true protection, then it's just as bad as the >> > security theater in US airports. >> >> It provides protection. Specifically it provides confidentially. >> >> It doesn't solve the fact that the DNS is a privacy violating >> nightmare. It doesn't change the fact that the NSA breaks the rules. >> > > And what Don and Rich's analysis is trying to isolate is how much real > protection you get from that level of confidentiality, so that a decision > that weighs all available factors can be made, including the complexity > cost. I'm sorry but that analysis is just not a serious and rigorous analysis. > It's not just a collective action problem because DNS isn't encrypted too. The conclusion summary is that because there are many problems, we won't address our part of the problems. The conclusion is that SNI privacy isn't worth it because those who live in liberal democracies with poor traffic analysis, well they just don't matter much. Which is... just... well, as I said above, I just don't take this seriously. > Their analysis also looks at what you get when both are encrypted. And > regardless of DNS being encrypted, rainbow-table style reverse lookups of > IP to DNS name are always possible. That doesn't mean encrypted SNI isn't > worth it -- it clearly provides a security attribute (confidentiality) to > an important piece of information. You're now suggesting an attacker that computes rainbow-tables to arrive a possibility which in itself sounds like a massive improvement over what was an absolute certainty. > But it's not enough to drive ahead and say that some attribute outweighs > every other consideration. For example, HSTS' persistence of memory can be > abused as a tracking device: > > http://zyan.scripts.mit.edu/sniffly/ > > And this was known at the time the spec was finalized: > > https://tools.ietf.org/html/rfc6797#section-14.9 > > But HSTS creates security benefits that are well worth the cost of that > tracking potential (which can also be mitigated through preloading). There > are a lot of browsers and communities which use and advocate for HSTS that > might generally balk at creating tracking devices. > Yes, tracking with HSTS is a problem and there is work being done to mitigate that tracking concern. > I'm not advocating a strong stance on whether encrypted SNI is worth > pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But > it's useful to keep the debate framed in its full context, rather than > narrowing it to a black-and-white discussion over whether a generally good > attribute is good or not. Sure and that full context includes RFC 7258: "Pervasive Monitoring Is an Attack" - something that defines reasonably clearly many of the concerns I've stated. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/3/15, Martin Thomson wrote: > There are a lot of inaccuracies in that presentation, so I wouldn't > pin too much on it. > I'm not pinning too much on it and I was surprised by the amount it was suggested would win me over. I actually went in thinking that I'd be crushed and concede; imagine my surprise! > In any case, before we all get too excited about this, there are some > solutions, I've seen a write-up of one of them, but it was a little > hard to follow first time around. Some of the things that are > described as impossible aren't that hard to fix. On the flip site, it > doesn't provide a fully general solution. The question up for debate seems to be if we should bother and I think that yes, we should bother. I spent some time today thinking about solutions for encrypting not only SNI but also other headers. It isn't entirely clear how to solve this problem in a few cases - but especially in the case of a repeated visit or a site that has an HSTS entry, I can see a few ways to protect the information. > > Expect to see something very soon. Until then, I don't think that an > in-depth on what isn't even at a straw-man level of detail is that > helpful. We need details before we can say whether the cost-benefit > makes sense. Where is the design actually happening? I know a few cryptographers who are interested in the design process. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
On 12/2/15, Eric Rescorla wrote: > On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum > wrote: > >> On 12/2/15, Eric Rescorla wrote: >> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford >> wrote: >> > >> >> On 02 Dec 2015, at 06:02, Martin Thomson >> >> wrote: >> >> > On 1 December 2015 at 08:22, Bryan A Ford >> >> > wrote: >> >> >> The 2-byte length field in each record's header no longer indicates >> >> >> the length of the *current* record but instead indicates the length >> of >> >> >> the *next* record. >> >> > >> >> > Ensuring that you know the length of the *next* record is difficult >> >> > and could dramatically degrade latency, or adding extra bogus >> >> > padding >> >> > or extra bogus records. For instance, I can always send in bursts >> >> > of >> >> > two packets, a one octet packet that promises the remainder of the >> >> > burst and one that promises a single octet packet. At that point, I >> >> > get to do what I've always done and you have gained little other >> >> > than >> >> > an increase in packet size of around 19 octets (best case). >> >> >> >> That type of inefficiency is extremely easy to avoid; please read the >> >> rest >> >> of my proposal where I discussed exactly that at length. Yes, a >> >> particularly stupid implementation could send everything in bursts of >> two >> >> packets, but it’s ridiculously easy for a slightly smarter >> implementation >> >> to avoid doing that. And what you’ve gained is complete encryption >> >> and >> >> integrity-checking of the whole TLS record before any part is >> >> interpreted, >> >> which seems like a nontrivial security improvement. >> > >> > >> > It's not really clear to me what the anti-traffic-analysis benefit of >> your >> > proposal >> > is over and above just padding everything to a fixed size. That's >> certainly >> > far >> > easier for the implementation to do, especially in typical stacks where >> the >> > application just calls SSL_Write (or whatever) and so there's no >> > obvious >> > API point to provide the "next length", so as a practical matter the >> stack >> > will very often if not always be in "last block" mode. >> > >> >> I think that it eliminates all static distinguisher in the protocol >> for all data covered by the encryption. That is a fantastically >> wonderful benefit. > > > Wouldn't that benefit be equally achieved by simply padding all records > to a fixed length? You could do this with no protocol change and, as I > said, it's far easier for the implementation. > Padding is potentially useful but has two issues that come to mind which are both non-issues in most cases. The first is the economic cost for extra bytes and the second is the security of the padding scheme. Padding strategies are a complement super encryption but probably not a replacement. Padding protects against one set of attackers (bean counters) and super encryption provides confidentiality against another set of attackers (GPA/APA). >> > [0] This issue doesn't apply to DTLS because the stack will just move >> onto >> > the next UDP datagram. >> >> An off-path attacker can't do much with DTLS, if designed correctly. >> Especially if they only see some packets - they'd only get the UDP >> headers and then the rest should be uniformly distributed random data, >> no? > > > DTLS records do in fact contain a length field because it's possible to > pack >1 record into a single UDP datagram. In practice, I think that > most stacks do 1:1 except perhaps during the handshake. They also > contain a sequence number to aid in reconstruction (important > in this case because TLS 1.3 uses the sequence number to > form the AEAD nonce). > > However, as you suggest, an attacker can't DoS DTLS connections by > injecting a small number of packets because the DTLS stack will just > reject bogus packets. This alone makes me think that DTLS with encrypted record headers is going to be a killer feature. Especially if an implementation rotates over ip:port and keeps sessions open even as clients move between networks. We'll hopefully see clients keyex on one network and keep a session open as they move to another network. That would make interception or attacking that client very difficult for an off-path partial view attacker, as well as very difficult even for a fully on-path mitm. The downside is that it won't compose very well with existing anonymity systems. The other other upside is that those systems can use this mode in the future for client -> network, inter network communication and network -> everywhere communications. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/3/15, Salz, Rich wrote: >> I actually went in thinking that I'd be crushed and concede; imagine my >> surprise! > > The fact that you viewed it as "crushed and concede" implies to me that your > mind was already made up, and that no description of trade-offs was going to > sway you. Is that belief unfair to you? No, I said explicitly the opposite: I expected that you would change my mind because you took the time to think about it, write slides and present it. I'm late to the party, so I had an open mind and was shocked that this was what had convinced anyone at all. I'm sympathetic to the government pressure angle but I do not believe that because one is afraid, one does better by preemptively capitulating. If Akamai wants to leave their users insecure, I look forward to another CDN offering privacy options. Such choice is missing if that isn't an option and it isn't on as a strong default. In any case, I await the specific cryptographic details and some of the people in my cryptographic research group (non-Tor) are interested. When it is published, I'll see if it actually helps to solve the problem at hand. If we can't design a cryptographic scheme to protect SNI, I'd understand fully why we won't have such a protection deployed. If we design it and then we're unhappy about DNS, well, great, one problem down - next up, dnsop works to solve the DNS query privacy problem. There is already work being done there - so I think we're on the way. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Hello, On 12/3/15, Aaron Zauner wrote: > PS: > > Aaron Zauner wrote: >> No it's not. It's a very short presentation from a TLS-WG interim >> meeting. The threat-model concerns Akamai's (and other's) current and - >> possibly - future use of TLS. We're not trying to build an Onion routing >> protocol. Given the FUD on the Tor dev list, this is a good thing. While >> the presentation might have flaws from the perspective of an Onion >> routing protocol developer, it reflects the point of view of a lot of >> people/companies on this list, I assume. >> > > I don't think traffic analysis is in the treat model for TLS proper. I'm confused by what you mean by traffic analysis. We encrypt content in TLS because we know that we want confidentiality. We want that because we know people do basic traffic analysis looking for sensitive data in plaintext. There are many kinds of traffic analysis adversaries. I think TLS isn't trying to beat a global active adversary, for example, while also providing anonymity. It seems that TLS is trying to beat a global passive adversary from violating the confidentiality of the protocol. A lack of confidentiality in many cases allows for attackers to do better traffic analysis and selective denial of service attacks. Failure to deal with very simple traffic analysis leads to much more serious attack vectors being actively exploited in the wild. > If > we wanted to circumvent traffic analysis we'd have to introduce noise > and randomness (Pond does a good job there using Tor and other > mechanisms). I don't see how we can engineer a low-latency (now even > 0-RTT) network security protocol that will do that in a performant > manner. When time comes and people have 10-40-100GE at home, maybe. > Infiniband would be nice. But that will still leave out use for 3rd > world countries (which still run on XP anyway). This is a technical list > and we should keep politics and FUD aside as best as possible. The architecture of the network protocol is the politics. There is no separation. RFC1984 and RFC 7258 cover this topic nicely. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
On 12/3/15, Watson Ladd wrote: > On Thu, Dec 3, 2015 at 6:36 AM, Jacob Appelbaum > wrote: >> On 12/2/15, Eric Rescorla wrote: >>> On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum >>> wrote: >>> >>>> On 12/2/15, Eric Rescorla wrote: >>>> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford >>>> wrote: >>>> > >>>> >> On 02 Dec 2015, at 06:02, Martin Thomson >>>> >> wrote: >>>> >> > On 1 December 2015 at 08:22, Bryan A Ford >>>> >> > wrote: >>>> >> >> The 2-byte length field in each record's header no longer >>>> >> >> indicates >>>> >> >> the length of the *current* record but instead indicates the >>>> >> >> length >>>> of >>>> >> >> the *next* record. >>>> >> > >>>> >> > Ensuring that you know the length of the *next* record is >>>> >> > difficult >>>> >> > and could dramatically degrade latency, or adding extra bogus >>>> >> > padding >>>> >> > or extra bogus records. For instance, I can always send in bursts >>>> >> > of >>>> >> > two packets, a one octet packet that promises the remainder of the >>>> >> > burst and one that promises a single octet packet. At that point, >>>> >> > I >>>> >> > get to do what I've always done and you have gained little other >>>> >> > than >>>> >> > an increase in packet size of around 19 octets (best case). >>>> >> >>>> >> That type of inefficiency is extremely easy to avoid; please read >>>> >> the >>>> >> rest >>>> >> of my proposal where I discussed exactly that at length. Yes, a >>>> >> particularly stupid implementation could send everything in bursts >>>> >> of >>>> two >>>> >> packets, but it’s ridiculously easy for a slightly smarter >>>> implementation >>>> >> to avoid doing that. And what you’ve gained is complete encryption >>>> >> and >>>> >> integrity-checking of the whole TLS record before any part is >>>> >> interpreted, >>>> >> which seems like a nontrivial security improvement. >>>> > >>>> > >>>> > It's not really clear to me what the anti-traffic-analysis benefit of >>>> your >>>> > proposal >>>> > is over and above just padding everything to a fixed size. That's >>>> certainly >>>> > far >>>> > easier for the implementation to do, especially in typical stacks >>>> > where >>>> the >>>> > application just calls SSL_Write (or whatever) and so there's no >>>> > obvious >>>> > API point to provide the "next length", so as a practical matter the >>>> stack >>>> > will very often if not always be in "last block" mode. >>>> > >>>> >>>> I think that it eliminates all static distinguisher in the protocol >>>> for all data covered by the encryption. That is a fantastically >>>> wonderful benefit. >>> >>> >>> Wouldn't that benefit be equally achieved by simply padding all records >>> to a fixed length? You could do this with no protocol change and, as I >>> said, it's far easier for the implementation. >>> >> >> Padding is potentially useful but has two issues that come to mind >> which are both non-issues in most cases. The first is the economic >> cost for extra bytes and the second is the security of the padding >> scheme. >> >> Padding strategies are a complement super encryption but probably not >> a replacement. Padding protects against one set of attackers (bean >> counters) and super encryption provides confidentiality against >> another set of attackers (GPA/APA). > > But as several people have noted, encrypting record lengths doesn't > actually protect the lengths of the records > as well as you think it does. I think it protects the length data exactly as much as it does. :-) It doesn't solve the problem that for a given TCP flow, we'll have a byte counter, of course. That is also why I'm quite interested in DTLS with super encryption. Especially with users roaming across networks, I'm hopeful that we'll blind partial view attackers even more than ever. > Timing packets is not some exotic and > unavailable technology. I don't understand what > attacks padding and introduction of dummy packets doesn't defend > against that encryption of record lengths does. We should also ensure that we have padding and dummy packets, of course. Still I don't see that we'll turn TLS into ATM nor do I believe that we understand an optimal padding strategy. I think you are correct that an attacker with a clock and a bean counter is a valid problem. I also think that the more state we force an attacker to hold, the more expensive it becomes to perform correlated traffic analysis across global networks. Super encryption of records also means that accidents at one layer may not be as catastrophic at another layer. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/3/15, Martin Rex wrote: > Jacob Appelbaum wrote: >>> >>>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >>>> secure >>> >>> That is a myth. >> >> Are you asserting that TLS 1.3 will be less secure or equally secure >> here? > > Even TLSv1.0 is sufficiently secure already, so that there > are plenty of other attack surfaces *MUCH* easier to attack. > > http://www.schneier.com/books/practical_cryptography/preface.html > >Arguing about whether a key should be 112 bits or 128 bits long is >rather like pounding a huge stake into the ground and hoping the >attacker runs right into it. You can argue whether the stake should >be a mile or a mile-and-a-half high, but the attacker is simply going >to walk around the stake. I look forward to using that poor saps TLS 1.0 services - where TLS isn't the weakest link! > If you design anything around TLS where the "secrecy" of the servername > is important, then you are acting extremely irresponsible. There are so > many ways and places where the servername WILL be leaked, (URLs, bookmarks, > HTTP-Header-Fields, HTTP-Referer headers, etc.) that bottom line, > encrypting > SNI amounts to crazy and pointless idea. > Huh - Could you please enumerate all of the places that TLS leaks a hostname requested by a client? Each one of them is a problem and we should correct it. TCP/IP and DNS are out of scope, though obviously related. > Using sha1(servername) instead of servername is (a) not confidential > and (b) backwards-incompatible with the existing protocol&usage and > the installed base. That was not a serious suggestion. If you think that I seriously suggested hashing the server name, I'm sorry. Please re-read my email and understand that I was suggesting that we can change the value of a field easily to make the attack more expensive. To make it worth doing, we want a better scheme than a straight hash of a name, of course. > No matter how many hoops you jump, encrypting > SNI will never become anything close to a TOR hidden service. > And for the vast majority of servers, there is going to be such > a small number of virtual services, that distinguishing them will > always be trivial by their traffic patterns. There is nothing that > TLS could do about app-determined traffic patterns of unrelated > TLS sessions. We probably agree here - there is a case where you want to compose with Tor. However there is a different issue which is that by leaving the client requested name in the clear, an attacker, even against a Tor exit node, can denial of service a specific client with nothing more than a word list. This is no different from HTTP without TLS for tearing a connection down; it becomes different with TLS 1.2 and DTLS (and probably with something like Bryan's super encryption). Sadly, DTLS doesn't compose with Tor and so, we want a similarly hard to distinguish TCP protocol that does compose with Tor. None the less - eventually a long term attacker may be able to learn things about public websites (eg: which wikipedia page you visited) - for non public websites, I don't believe that you can make the same claim. Additionally, the bar for an attack has just been seriously raised from ngrep to a pretty sophisticated attacker with long term funding. > You could use innocent servernames or multi-SAN server certs plus *NO* SNI. > and both would provide higher security and be much easier to implement > than encrypting SNI. I look forward to your proposal that removes the need for encrypting SNI. I think it will be interesting to compare your construction with the soon to be shown encrypted SNI proposal. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/4/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>TCP/IP and DNS are out of scope, though obviously related. > > Why are they out of scope? They are out of scope for the TLS working group as far as I understand the organization of the IETF in terms of mandate. Am I incorrect? Should we discuss the privacy failures of IPv6 on this list as well? I'm happy to do so but I think this is out of scope. > You can't just ignore a threat if it's > inconvenient, you need to look at the overall picture. That is exactly what I've been saying over the last several days and really for many years. The collective action failures here are not because I can't see the overall picture but because there is blame shifting. If we look at one specific protocol and solve things, we find that composed with other solutions, we're really working toward an overall solution. > Arguing over > plugging > a mousehole in the corner of the barn is pointless when two of the four > walls > are missing. As Martin has pointed out: > > There are so many ways and places where the servername WILL be leaked, > (URLs, bookmarks, HTTP-Header-Fields, HTTP-Referer headers, etc.) that > bottom line, encrypting SNI amounts to crazy and pointless idea. TLS protects the HTTP headers, bookmarks don't travel across the network and a url needs to be sent by a protocol to be leaked to the network. The client requested hostname is leaked a single time. Plugging that leak by encrypting it is not impossible and that someone might share a URL doesn't mitigate the usefulness of reducing that specific information leakage in TLS. The point is not to hide that a server has a name - the point is to protect a flow within a relevant time frame. This may prevent an adversary from selecting it for storage (ex: XKeyscore selector on cs.auckland.ac.nz) or it may prevent an adversary from doing an active attack from even as lowly as an off-path position having seen just a single or small subset of packets from a given flow. There are other reasons as well. That DNS has problems doesn't mitigate that TLS itself has problems when it stands alone. > > I'm not sure if I'd call it crazy and pointless, just not worthwhile. > You're > leaking server-name information in a great many other locations and ways, > and > encrypted SNIs causes so many problems, that the cost/benefit tradeoff > doesn't > make it worthwhile (which, I guess, could be classed as "pointless"). As a TLS user - I'm only leaking SNI at Tor exit nodes and there is no other choice for me. I'm living in the world where DNS and other channels are not leaking on the same path as my TLS connection. Still, my TLS connections have a lot of information that is available to a sniffer on a Tor exit or XKeyscore on the whole internet. Removal of the SNI field is not an option - encrypting it should be an option, if not a strong default. > > Perhaps someone could write an RFC for a play-with-experimental-features TLS > extension, where implementers could encrypt lengths and SNIs and anything > else > they want, and then test them out in the real world to see what effect it > has. Or they could just call MinimaLT or CurveCP with mandatory Elligator TLS 1.3 and be done with it. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
On 12/2/15, Watson Ladd wrote: > On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum >> >> I think that it eliminates all static distinguisher in the protocol >> for all data covered by the encryption. That is a fantastically >> wonderful benefit. > > What's a "static distinguisher"? Padding solves this problem as well, > but it also solves problems resulting from TCP segmentation down the > stack, which header encryption doesn't. What does header encryption > offer that padding does not? > Fixed parts of a protocol are often considered as static distinguishers - most are unavoidable unless you take the Scramblesuit design approach and have a keyexchanged out of band. Elligator is another useful design in this direction. In the case of TLS, we've seen a specific Oakley group used as the distinguisher that selected all related (TCP) flows for disruption. Changing that to a (well formed) randomly selected value allowed traffic to flow freely again. Other static values like a site specific plaintext name are used much more commonly. I could imagine for example that all records with a given length can be selected and dropped, for example. Common VoIP applications that use fixed lengths are thus even easier to censor with an exposed length field. With that value hidden and with *random* padding, I think the ease of selecting specific flows would be reduced and the cost would be much higher. No everyone needs padding but many people will want that value hidden without a useful way to do it unless the protocol supports it by default. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3
On 12/5/15, Ryan Carboni wrote: >> >> If Akamai wants to leave their users insecure, I look forward to >> another CDN offering privacy options. Such choice is missing if that >> isn't an option and it isn't on as a strong default. > > > The NSA has contracts with ISPs to have access to their user's content. > Which did you have in mind? AT&T? Sure. And for unilateral access they do it without contracts such as the TAT cable. > Is a CDN an ISP? > Are you asking if the CDN gives data to the NSA, I guess you'd just have to ask them directly. I guess they won't answer or they'll be legally obliged to lie. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
On 12/6/15, Peter Gutmann wrote: > Jacob Appelbaum writes: > >>On 12/4/15, Peter Gutmann wrote: >>> Jacob Appelbaum writes: >>>>TCP/IP and DNS are out of scope, though obviously related. >>> Why are they out of scope? >> >>They are out of scope for the TLS working group as far as I understand the >>organization of the IETF in terms of mandate. Am I incorrect? > > They're out of scope in that TLS can't impose behaviour on DNS, but they're > not out of scope when it comes to considering what impact DNS has on TLS. Of course. Thankfully there is work to fix DNS by... using TLS! > For > example the whole reason why TLS has certificates is because the TLS (well, > SSL then) folks realised that DNS wasn't secure, and that TLS had to deal > with > that issue. Otherwise, the SSL folks could have just said that DNS issues > are > out of scope, and we'll wait for DNSSEC to appear at some point and fix > things > (this is speaking from a 1995 time frame). Hopefully someday, we'll have the DNS security problem solved. Until then, I look forward to the TLS working group to not making name privacy _harder_ to implement. The great irony of DNS potentially using TLS for privacy is... oh, so much for that strategy. >>Or they could just call MinimaLT or CurveCP with mandatory Elligator TLS >> 1.3 >>and be done with it. > > That would probably be an easier process than the current one, provided > you're > ready to commit completely to the Bernstein monoculture. I admit, I'm biased here. I'd rather have a monoculture of security than polyculture of insecurely designed by commitee. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI
On 12/6/15, Dave Garrett wrote: > On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote: >> Can we embed an EncryptedExtension inside an existing EE? That would let >> us do TOR purely within TLS, right? > > If clients are allowed to send any encrypted extensions other than the > tunneling extension (that contains the tunneled hello), then we would have > to allow sending an EncryptedExtension through it, otherwise tunneled peers > would have less capabilities than non-tunneled. I don't see anything in this > design that would prohibit recursively doing this as many times as desired. > (e.g. tunnel of a tunnel of a tunnel of a...) That does sound somewhat > TOR-like, though obviously, lots more would be needed to actually do > anything with that. If this can actually be done, it sounds very promising. > I had a similar thought. There needs to be a way to blind each server that is two hops away to make it work: Alice connects to a server_0, the server routes to server_1, server_1 routes to server_2 and that passes the final TLS to Bob. Alice's TLS message needs to be passed to server_1 without every indicating in an encrypted fashion that server_2 is in the path. In this analogy, server_0 is like the Tor guard, server_1 is the middle node, and server_2 is the exit node. There are some issues with such a design - which is why Tor's design is to use TLS as an outer link layer and then internally to use 512 byte (or slightly larger) cells. I won't get into those here but I find the general idea of tls within tls to be useful. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
