Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 17 Jul 2017, at 21:11, Watson Ladd wrote: How do you detect unauthorized access separate from knowing what authorization is? I think we're talking at cross purposes, here. Can you clarify? Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you? Many don't. And being able

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017 3:42 AM, "Roland Dobbins" wrote: On 15 Jul 2017, at 3:40, Watson Ladd wrote: DDoS mitigation can be done at endpoints > Not at scale. That's why it isn't done that way. I'm all in favor of things like mod_security. But they can't do the heavy lifting on

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 Jul 2017, at 20:49, Roland Dobbins wrote: Based on my experience troubleshooting, I disagree with your disagreement; while in many circumstances a great deal can be inferred from one end, it's sometimes vitally necessary to gain visibility from multiple points in the relevant

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 Jul 2017, at 20:35, Blumenthal, Uri - 0553 - MITLL wrote: :-) It’s the Law Enforcement job to make the dumber ones disappear. We aren't talking about law enforcement, per se - and it's law enforcement's job to make them *all* disappear. Let’s exchange our criminals – I’d much rather

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

But it's also important for understand that security is additive in nature, not all the criminals are bright or sophisticated, & so the emergence of a few smarter ones doesn't make those less so disappear. :-) It’s the Law Enforcement job to make the dumber ones disappear. The question

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 7/17/2017, 11:04, "Roland Dobbins" wrote: The actual concern of intranet operators is the inadvertent breakage of an important mechanism used for troubleshooting and security in the context of TLS-encrypted traffic on their own networks, within their own

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 19:28, Blumenthal, Uri - 0553 - MITLL > wrote: Organized crime capabilities are reaching the level of nation states, ankle biters reach up to where the organized crime was yesterday… I understand all this - I have to deal with it

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017, at 17:08, Salz, Rich > wrote: Let's not guess. Agreed. --- Roland Dobbins > ___ TLS mailing list TLS@ietf.org

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 7/17/2017, 12:45, "TLS on behalf of Roland Dobbins" wrote: On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote: > it could easily be enabled accidentally on the Internet, or coercively > required > of certain

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

> The standard definition of “traffic analysis” is deducing > information from the metadata and the patterns of communications. It > explicitly does NOT rely on knowing the content of the traffic (which > is assumed to be opaque). That's what I was trying to get across

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 Jul 2017, at 19:01, Roland Dobbins wrote: Many organizations do this, today. And some also go the passive-only route - I forgot to mention that. They'll use commercial IDS/IPS, or Snort with viewssld, et. al. --- Roland Dobbins

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 Jul 2017, at 18:55, Watson Ladd wrote: So FS has no impact on this, correct? It's often desirable to be able to inspect closer to the internal user traffic sources/destinations, as well as at the proxy. It can greatly reduce the scope of traffic which is to be analyzed in any given

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017 9:48 AM, "Roland Dobbins" wrote: On 17 Jul 2017, at 18:40, Simon Friedberger wrote: I'm not sure the same considerations should apply to both those situations. > Actually, they do, when you're on your network prior to the egress point - apologies for being

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 Jul 2017, at 18:40, Simon Friedberger wrote: I'm not sure the same considerations should apply to both those situations. Actually, they do, when you're on your network prior to the egress point - apologies for being unclear about that. Many enterprises force all outbound

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 17 Jul 2017, at 18:35, Benjamin Kaduk wrote: it could easily be enabled accidentally on the Internet, or coercively required of certain entities, e.g., by national security letter, once enablement is just a configuration setting (as opposed to writing code) Yes, concur. So, in order

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17/07/17 17:32, Roland Dobbins wrote: > Sure - detecting attempted additional compromise and lateral movement > utilizing exploits within TLS-encrypted traffic. This is about decrypting traffic inside your network. > Another is detecting (and subsequent blocking of) the download of >

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 07/17/2017 11:35 AM, Benjamin Kaduk wrote: > > So, in order to have something that is verifiably opt-in by both > parties, it seems like it would have to be a ClientHello/ServerHello > extension (included in the transcript for the generated traffic keys) > where both sides commit that they are

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 07/17/2017 10:18 AM, Yoav Nir wrote: >> On 17 Jul 2017, at 17:06, Roland Dobbins wrote: >> >> On 16 Jul 2017, at 11:19, Salz, Rich wrote: >> >>> The key point here is Within the enterprise. >> +1 > It’s an illusion that inside the enterprise uses different technologies than

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Mon, Jul 17, 2017 at 10:32 AM, Roland Dobbins wrote: > On 17 Jul 2017, at 16:52, Carl Mehner wrote: > >> Do you have an example of where malware would be on your intranet where >> using this >> draft would help you? > > > Sure - detecting attempted additional compromise

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 17 Jul 2017, at 16:25, Yoav Nir wrote: ISTM that this is a great argument *against* allowing the administrators in the data center to be able to access the plaintext. The joke is that obviating crypto by going around is something bad guys can and will do, sorry for being unclear!

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 Jul 2017, at 16:52, Carl Mehner wrote: Do you have an example of where malware would be on your intranet where using this draft would help you? Sure - detecting attempted additional compromise and lateral movement utilizing exploits within TLS-encrypted traffic. Another is

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 17 Jul 2017, at 17:06, Roland Dobbins wrote: > > On 16 Jul 2017, at 11:19, Salz, Rich wrote: > >> The key point here is Within the enterprise. > > +1 It’s an illusion that inside the enterprise uses different technologies than outside the enterprise. IP was for

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 Jul 2017, at 16:23, Blumenthal, Uri - 0553 - MITLL wrote: It may, or it may not – depending on the sophistication of your adversary. It is not given that you’d be able to “simply detect the presence of an additional crypto layer”, particularly if measures are taken to hide it. Sure.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> > My guess is that industries interested in the DH key proposal would > > want 0-RTT. I think they would want to prevent replay attacks and > > might even see configuration errors of this as a risk (allowing 0-RTT > > inadvertently). > > Concur 100%. We should not design this based on

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 16 Jul 2017, at 11:19, Salz, Rich wrote: > The key point here is Within the enterprise. +1 --- Roland Dobbins ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 16 Jul 2017, at 11:43, Kathleen Moriarty wrote: > My guess is that industries interested in the DH key proposal would > want 0-RTT. I think they would want to prevent replay attacks and > might even see configuration errors of this as a risk (allowing 0-RTT > inadvertently). Concur 100%.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 17 Jul 2017, at 16:04, Blumenthal, Uri - 0553 - MITLL wrote: “But we (the (network) authorities) are the good guys, and we need to break the guarantees TLS provides so we can catch criminals – and here is how we propose to break TLS-1.3”. The actual concern of intranet operators is the

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Mon, Jul 17, 2017 at 9:11 AM, Dobbins, Roland wrote: > > > On Jul 17, 2017, at 15:59, Carl Mehner wrote: > > the only way that this draft would help you > with malware analyzing) > > > This statement is factually incorrect. It’s not the only way, as I've just

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Mon, Jul 17, 2017 at 10:23 AM, Blumenthal, Uri - 0553 - MITLL wrote: > And why are you unable to understand that that in the case of an > additional layer of > attacker-generated crypto nestled within a TLS tunnel, as you posited, that > the ability > to simply detect

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 17 Jul 2017, at 16:20, Roland Dobbins wrote: > > On 17 Jul 2017, at 16:15, Yoav Nir wrote: > >> Obligatory XKCD link: > > This one is actually more relevant, IMHO: > > ISTM that this is a great argument *against* allowing the administrators

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

And why are you unable to understand that that in the case of an additional layer of attacker-generated crypto nestled within a TLS tunnel, as you posited, that the ability to simply detect the presence of such an additional layer of unexpected crypto, even without the ability to

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 17 Jul 2017, at 16:15, Yoav Nir wrote: > Obligatory XKCD link: This one is actually more relevant, IMHO: --- Roland Dobbins ___ TLS mailing list TLS@ietf.org

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> On 17 Jul 2017, at 13:48, Salz, Rich wrote: > >>> DDoS mitigation can be done at endpoints >> >> Not at scale. That's why it isn't done that way. > > Sometimes it is. > > Can we stop making definitive declarations like this? > > There are more things in the world,

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 15:59, Carl Mehner > wrote: the only way that this draft would help you with malware analyzing) This statement is factually incorrect. It’s not the only way, as I've just explained. Again, why are you trying to pretend that the use of this

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

A higher-level view on this issue. TLS has been designed as a protocol that allows two entities to communicate securely over a network controlled by an adversary, including abusive authorities. “But we (the (network) authorities) are the good guys, and we need to break the guarantees TLS

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

I have not heard any assertions that looking at unencrypted tls traffic is not valuable. I agree that there are cases that it is. What I and others have disagreed with is that the examples provided on the list and in the draft of where it is necessary are either not applicable, or simply 'easier'

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 15:40, Carl Mehner > wrote: Why would malware use this draft? Nobody said anything about malware using this draft. What I'm saying is that the ability to look inside the TLS tunnel & infer the presence of an additional, unexpected

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Mon, Jul 17, 2017 at 8:35 AM, Dobbins, Roland wrote: >> On Jul 17, 2017, at 15:15, Carl Mehner wrote: >> beginning to encrypt traffic inside the TLS tunnel. > Yes, some (but by no means all) are - which means that in such cases, the > ability to look inside

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 15:15, Carl Mehner > wrote: beginning to encrypt traffic inside the TLS tunnel. Yes, some (but by no means all) are - which means that in such cases, the ability to look inside the TLS tunnel so as to be able to detect the presence of an

[TLS] Last Call: (ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2) to Proposed Standard

The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Protocol version 1.2' as Proposed Standard The IESG plans to make a decision in the next few

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Mon, Jul 17, 2017 at 8:02 AM, Dobbins, Roland wrote: > > > On Jul 17, 2017, at 14:14, Russ Housley wrote: > > I think that the IDS is trying to detect the an infected server trying to > migrate to another server. Malware often includes a series of

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 14:14, Russ Housley > wrote: I think that the IDS is trying to detect the an infected server trying to migrate to another server. Malware often includes a series of exploits that are tried in sequence to infect a

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017, at 14:21, Tom Ritter > wrote: It should be visible on the outside on the connection, so middle boxes that don't break TLS can see that TLS is being broken. With the caveat that the details of how it's actually implemented are key (pardon

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Predicting the future is hard. Does anyone have a crystal ball that says this MUST be done within, say, three years? We can look at the PCI DSS timeline for previous revs - there's no guarantee it would be the same, of course. And there are other relevant regulators, as well. Perhaps

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

>> Which brings me to my second question (or first, depending on how you read >> email).  Will this be needed within five years?  Within three? > That's a very good question.  > Unfortunately, we don't know, yet. But we do know it will happen at some > point as a matter of course.  

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017, at 13:50, Salz, Rich > wrote: Which brings me to my second question (or first, depending on how you read email). Will this be needed within five years? Within three? That's a very good question. Unfortunately, we don't know, yet.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On Jul 17, 2017 6:06 AM, "Roland Dobbins" wrote: On 16 Jul 2017, at 0:34, Daniel Kahn Gillmor wrote: Strongly enough to support a proposal that would require this to be > opt-in from both sides, with an explicit and verifiable exfiltration > authority, so that no standard

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On Jul 17, 2017, at 14:01, Martin Thomson > wrote: My point was that you don't get that visibility when it is malware at both ends of the connection (assuming a modest amount of competency from the authors). Seeing it when it's only

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 17 July 2017 at 12:59, Roland Dobbins wrote: >> At the point that I have sufficient control over a host that I can run >> my software, then I would pin certificates and the best you could do >> is block me. None of the advice about configuration of trust anchors >>

[TLS] I-D Action: draft-ietf-tls-exported-authenticator-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename:

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> Being able to continue to utilize vetted, well-understood, standards-based > cryptography on intranets once regulatory bodies such as PCI/DSS mandate > TLS 1.3 or above - which will happen, at some point in the not-too-distant > future. Which brings me to my second question (or first, depending

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

> > DDoS mitigation can be done at endpoints > > Not at scale. That's why it isn't done that way. Sometimes it is. Can we stop making definitive declarations like this? There are more things in the world, Horatio, then are dreamt of in your philosophy.

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 16 Jul 2017, at 0:34, Daniel Kahn Gillmor wrote: Strongly enough to support a proposal that would require this to be opt-in from both sides, with an explicit and verifiable exfiltration authority, so that no standard implementation of the proposed mechanism could be accidentally turned on

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 14 Jul 2017, at 12:17, Kathleen Moriarty wrote: Otherwise, with the proposed solution, your still relying on indicators of compromise that can be detected using the encrypted traffic. Actually, it's often important to have visibility into the intranet cryptostream in order to detect and

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

On 14 Jul 2017, at 8:02, Martin Thomson wrote: Just an aside, though I think Kathleen already made this point:  If I were writing malware, I would use TLS.  It's pretty good at what it does and it's hard to distinguish from legitimate uses (there are some trick's suggested by McGrew's research

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 16 Jul 2017, at 0:07, Watson Ladd wrote: How does an endpoint not know the source? You do not seem to have a good grasp of Internet operations at scale and necessary division of functions. --- Roland Dobbins

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 15 Jul 2017, at 18:18, Kathleen Moriarty wrote: When I have done this in the past in environments I've managed, I always used a one way cable (receive only), set up the interface for receive only, and then use the same protection mechanism offered by the switch. Yes! Back in the old days,

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

On 15 Jul 2017, at 3:40, Watson Ladd wrote: DDoS mitigation can be done at endpoints Not at scale. That's why it isn't done that way. I'm all in favor of things like mod_security. But they can't do the heavy lifting on boxes which are already burdened by handling legitimate traffic. If

Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt

On 17 July 2017 at 11:37, Kazuho Oku wrote: > One minor request: it would be great if you could add examples for the > exporters. Bug in a exporter is hard to find unless you have an > interop between applications that actually use it (however TLS itself > doesn't use it). It

Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt

Thank you for updating the draft. I really appreciate your effort to have the example vectors documented. It will be a great help to the implementers. One minor request: it would be great if you could add examples for the exporters. Bug in a exporter is hard to find unless you have an interop

Re: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt

I've revised the draft. It now covers -21. I had to make a few changes to ensure that the changes to the resumption secret for tickets was exposed in the draft, you can now see the resumption secret being split based on the ticket_nonce. On 17 July 2017 at 09:18,

[TLS] I-D Action: draft-ietf-tls-tls13-vectors-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : Example Handshake Traces for TLS 1.3 Author : Martin Thomson Filename:

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

Chair slides are up: https://www.ietf.org/proceedings/99/slides/slides-99-tls-sessb-chairs-slides-06.pdf Further bash: I talked to Nick last night and since we have time on Monday he whipped up some slides on Exported Authenticators in TLS (aka