Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 6:31 PM Ackermann, Michael wrote: > NO > The objective is to be passively observe, out of band and not to be a MitM > or modify/inject text.Just as we all do today. You seem to be confused as to the difference between an active vs passive MitM. Using the term “MitM”

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Who cares about the objective? People are asking about the result. Regards, Uri Sent from my iPhone > On Oct 23, 2017, at 19:32, Ackermann, Michael wrote: > > NO > The objective is to be passively observe, out of band and not to be a MitM or > modify/inject text.Just as we all do today.

[TLS] DTLS 1.3 ACKs

We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. The one thing we ran into was the potential need to ACK in cases where you can't process *any* records (e.g., you receive what's actually EE, but you can't decrypt it). In this case, you want to send an empty ACK. See PR: https:/

[TLS] TLS 1.3 Record Boundaries

Draft-21 says: "Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEa

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

NO The objective is to be passively observe, out of band and not to be a MitM or modify/inject text.Just as we all do today. -Original Message- From: Benjamin Kaduk [mailto:bka...@akamai.com] Sent: Monday, October 23, 2017 6:33 PM To: Ackermann, Michael ; Tony Arcieri ; Adam Caudi

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 3:30 PM, Benjamin Kaduk wrote: > There are no doubt folks here would claim that the writing has been on the > wall for > five years or more that static RSA was out and forward secrecy was on > the way in, and that now is the right time to draw the line and drop the > back

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 05:09 PM, Ackermann, Michael wrote: > No one I am aware of is pushing for a MitM capability to address > this.   In fact it was one of the alternative solutions for which many > implementation issues were cited at the Prague meeting and on this > list.    But I would like to ask,  wha

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 01:42 PM, Ackermann, Michael wrote: > But as stated in several previous Emails, the fact that TLS 1.2 is still > available, does not mean that we won't have applications, business units or > other entities that require TLS 1.3 and we will need to manage, monitor and > secure the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

This can be solved without changes to the protocol or a standardized “backdoor” - and is being done today by at least some enterprises. Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly

Re: [TLS] Closing PR#47 on draft-ietf-tls-iana-registry-updates

On 10/23/2017 12:50 PM, Joseph Salowey wrote: > ekr proposed a PR (#47) for  draft-ietf-tls-iana-registry-updates that > clarified the specification required rules to include Internet Drafts.   > > I believe this is not the intent and we should close the issue.   > > I think the intent of specifica

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill wrote: > Those advocating for some standardized method of subverting the security > properties of TLS have been offered numerous options in good faith, and > continue to reject them all. I’m aware of extremely large enterprises that > in fact require

Re: [TLS] Connection ID Draft

On Mon, Oct 23, 2017 at 2:22 PM, Benjamin Kaduk wrote: > On 10/23/2017 07:12 AM, Eric Rescorla wrote: > > Another comment is about symmetrical CID. >> >> 1. Consider a client sends a normal CID (CID length is not zero, >> named C-CID) to server, but the server doesn’t wants to use client’s

Re: [TLS] Connection ID Draft

On 10/23/2017 07:12 AM, Eric Rescorla wrote: > >  Another comment is about symmetrical CID. > > 1.   Consider a client sends a normal CID (CID length is not > zero, named C-CID) to server, but the server doesn’t wants to use > client’s CID and sends a CID generated by the server

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

To be honest, I’m rather surprised that this group continues to spend time on this. I’m of the opinion that the chairs should step in and put this discussion on hold until the work on TLS 1.3 is complete. This, and any document of the same goal, are eating up time and energy that should be directed

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

But as stated in several previous Emails, the fact that TLS 1.2 is still available, does not mean that we won't have applications, business units or other entities that require TLS 1.3 and we will need to manage, monitor and secure these, as well as older versions. -Original Message---

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 2:12 PM, Ackermann, Michael wrote: > To suggest that I or my industry does not take security seriously, is > inaccurate and immaterial to this discussion. I'm sure you take security seriously. What I'm saying is that you have tunnel vision about it, because you are caught

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* I would put the comment that anyone or any industry is attempting to lay costs for anything off on IETF, in the same unfortunate bucket. Do I misunderstand what you meant by this comment? It is a huge proposition requiring change to virtually every platform and applicatio

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

To suggest that I or my industry does not take security seriously, is inaccurate and immaterial to this discussion. I would put the comment that anyone or any industry is attempting to lay costs for anything off on IETF, in the same unfortunate bucket. These types of subjectively negative sta

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

For the chairs: I second Stephen’s request. Enough is enough. -- Regards, Uri Blumenthal On 10/23/17, 13:54, "TLS on behalf of Stephen Farrell" wrote: On 23/10/17 18:30, Ackermann, Michael wrote: … The arguments did not convince before, and will not convince now. T

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 23/10/17 18:30, Ackermann, Michael wrote: > It is a huge proposition requiring change to virtually every platform > and application.Not to mention all the management, monitoring > and security platforms. It would be very expensive and time > consuming. And when they ask why this is necessa

[TLS] Closing PR#47 on draft-ietf-tls-iana-registry-updates

ekr proposed a PR (#47) for draft-ietf-tls-iana-registry-updates that clarified the specification required rules to include Internet Drafts. I believe this is not the intent and we should close the issue. I think the intent of specification required is to allow a community that needs a code poin

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 1:30 PM, Ackermann, Michael wrote: > The WHY you ask is in the answer. > It is a huge proposition requiring change to virtually every platform and > application.Not to mention all the management, monitoring and security > platforms. > It would be very expensive and ti

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* It is a huge proposition requiring change to virtually every platform and application.Not to mention all the management, monitoring and security platforms. Do you expect that this draft will require no changes to all your management, monitoring, and security platforms? * And w

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

The WHY you ask is in the answer. It is a huge proposition requiring change to virtually every platform and application.Not to mention all the management, monitoring and security platforms. It would be very expensive and time consuming. And when they ask why this is necessary, it is because

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/23/2017 12:39 PM, Ackermann, Michael wrote: 2. Modifying Server, application and logging infrastructure is a huge, expensive proposition, that executive management would not be receptive to at all. Not to mention the logistics to follow if they were. I'd just like to have

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

1. If staying with TLS 1.2 indefinitely was considered acceptable, would we even be having these discussions? DAMMIT. Stop saying indefinitely. What percentage of hosts within your enterprise use TLS 1.2 as the preferred protocol? 1. Modifying Server, application and logging infrastr

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:39 PM, Ackermann, Michael wrote: > If staying with TLS 1.2 indefinitely was considered acceptable, would we > even be having these discussions? This is a vacuous argument. Nobody has provided any evidence of any kind that "enterprise" installations relying on TLS 1.2

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Thursday, 19 October 2017 19:12:11 CEST Blumenthal, Uri - 0553 - MITLL wrote: > If those middleboxes already have sufficient alternative options, why do we > spend time discussing this draft? Why do we need to add yet another > alternative for them? so that they benefit from standardisation, n

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Thanks Rich I have seen these suggestions previously. But as numerous messages on this chain, from various people have discussed, neither of those suggestions are viable from an Enterprise Architecture planning perspective. 1. If staying with TLS 1.2 indefinitely was considered acceptable,

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:25 PM, Ralph Droms wrote: > Is there running code that demonstrates the IPsec+IKE can be deployed and > operated at scale in the sort of environment the enterprise network tips have > described to us? Is there running code that demonstrates that draft-rhrd-tls-tls13-visib

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 12:22 PM, Ackermann, Michael wrote: > My question back to you was WHAT SIMPLIER PROTOCOL? This is what I actually wrote, in the message before the one Kathleen sent: > What they require is visibility into contents of the flow that they are using > encryption to protect.

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* Is there running code that demonstrates the IPsec+IKE can be deployed and operated at scale in the sort of environment the enterprise network tips have described to us? IBM has supported full-scale IPsec/IKE deployment on System/z for a very long time, and it also has an interesting way o

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

* I am merely trying to understand if there are any constructive suggestions amongst all these discussions, that we should consider. Yes. To repeat myself, here are two: 1. Continue to use your existing schemes. You won’t have to change to TLS 1.3 for years. 2. Modify your servers a

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> On Oct 22, 2017, at 2:40 PM, Ted Lemon wrote: > > On Oct 22, 2017, at 1:54 PM, Russ Housley > wrote: >> No one is requiring TLS 1.3 that I know about. However, there are places >> that require visibility into TLS. I will let one of the people that works >> in

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I am merely trying to understand if there are any constructive suggestions amongst all these discussions, that we should consider. Your comment was "It would be better to use a simpler protocol," My question back to you was WHAT SIMPLIER PROTOCOL? If your answer to my question, is to refer to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On 10/22/17 5:26 PM, Steve Fenter wrote: > I know of a number of large enterprises in verticals including financial, > health care, retail, and government, across multiple countries, who are using > packet payload inspection within their data centers. Most of these > enterprises are reluctant t

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Oct 23, 2017, at 10:35 AM, Ackermann, Michael wrote: > I was only asking what your opinion was, based on that statement in your > reply. With respect, Michael, I gave my opinion in the message to which Kathleen replied, so your assertion that you have been reading these messages doesn't se

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

I have. I was only asking what your opinion was, based on that statement in your reply. From: Ted Lemon [mailto:mel...@fugue.com] Sent: Sunday, October 22, 2017 7:44 PM To: Ackermann, Michael Cc: Steve Fenter ; tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 On

Re: [TLS] Connection ID Draft

On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing wrote: > Hi Ekr, > > > > For the post-handshake messages in the draft, I have some comments. > > > > 1. When one peer sends NewconnectionID message to the other, it > uses a newly defined handshake type. This new CID is attached in the > payload

Re: [TLS] Connection ID Draft

Hi Ekr, For the post-handshake messages in the draft, I have some comments. 1. When one peer sends NewconnectionID message to the other, it uses a newly defined handshake type. This new CID is attached in the payload of the record message. But there must be some information for the recei