On 08/07/17 16:31, Paul Turner wrote: > Stephen, > > You have referenced RFC 2804, which states the following in section > 3: > > "For the purposes of this memo, the following definition of > wiretapping is used: Wiretapping is what occurs when information > passed across the Internet from one party to one or more other > parties is delivered to a third party"
The draft matches 2804 for many uses of TLS. E.g. anyone with a hosted web service without access to the underlying http server config. That's millions of people I believe. I do not believe that is fixable. > > The Internet Draft describes the use of static (EC)DHE for traffic > entirely inside enterprise networks No it doesn't. There is no definition of enterprise network not any mechanism for constraining deployment to such. Nor can there be, other than pretense and pixie-dust. > and intends to clearly state that > it should not be used for "information passed across the Internet". Yes, you may intend to say something like that but it's nonsense. TLS is used in far too many contexts for that to be a reasonable approach. > If we have not been clear enough on that in the document, please tell > us how we can be more clear. Remove the "standards track" header and go elsewhere is IMO the only sensible outcome. It is not possible, nor useful, to attempt to fix the draft as-is. > Assuming that the document is clear on > this point, it would not then apply to "wiretapping" as defined in > RFC 2804 (as Russ mentioned in an earlier email). Yes, you are both incorrect there. > > It would appear then that your concern is that an organization (or > person) will disregard these two documents and use static (EC)DHE > keys for their Internet connections. Is that correct? > > Assuming that is correct, here are two considerations: > > 1. Why would an organization that wants to deliberately share the Coercion. Eg. a NSL in the US. The proposed method is nice and simple for the web site and from the point of a wiretapper puts the packet capture burden nicely where it's wanted in the middle of the network. > content of TLS encrypted Internet communications with a third party > go to the trouble of implementing static (EC)DHE keys? Since they are > an end point in the communications, they have all of the information > (decrypted) and can share it with the third party without any need > for static (EC)DHE keys (as I believe Watson pointed out). > > 2. There is nothing in the TLS 1.3 protocol today that would prevent > someone from implementing static (EC)DHE keys, even if this document > is not published as an RFC. If published, this RFC would make it > clear that must not be done with TLS 1.3. I would prefer that we impose more strict requirements on the use of non-static public DH values and forget about this draft entirely. I will strongly object to every attempt to do this on the standards-track with the IETF. > > You have stated that there are alternatives by using proxies but > enterprise organizations have stated this is not viable due to the> > complexity and scale of their network environments. And others disagreed with that and don't find any problems with dropping rsa key transport. Assertions that this is necessary are therefore false. It clearly is not needed for lots of deployments. > Our collective > objective is to increase the security of the Internet at large. If so, you are going about it wrong - there BITS-related efforts all seem to me to be in the direction of weakening security. S. > As > such, we have proposed this RFC in order to ensure that TLS 1.3 is > adopted as broadly as possible inside of enterprises, which is an > important step in increasing security. > > Consequently, we would ask that this discussion not be shut down as > you request. > > Paul > > -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On > Behalf Of Stephen Farrell Sent: Saturday, July 8, 2017 10:33 To: > Yaron Sheffer <yaronf.i...@gmail.com>; tls chair > <tls-cha...@tools.ietf.org> Cc: tls@ietf.org Subject: Re: [TLS] > chairs - please shutdown wiretapping discussion... > > > > On 08/07/17 15:27, Yaron Sheffer wrote: >> Hi Stephen, >> >> Like you, I am very unhappy with this draft, and would not support >> its adoption as a WG draft. However I think that open discussion is >> in general good, and that the best venue for discussion of this >> draft is this mailing list. Even if some of this discussion >> devolves into generic "are we pro or against wiretapping" >> questions. > > FWIW I believe that we have had that discussion about breaking tls > over and over on this and other lists. I see no value in doing it yet > again, even if the proximate cause is a new variation of the "here's > a way to break tls" class of drafts. (Someday we should find someone > who'd document all the broken break-tls ideas that have been rightly > rejected over the years.) > >> >> I don't think this is a significant distraction that could derail >> (D)TLS, moreover, you will recall that in Chicago several new >> drafts were adopted to the working group. So the WG does feel that >> TLS is in good enough shape that we can spend some bandwidth on >> other things. > > Maybe I'm more easily distracted, at least by this topic;-) > > Anyway, I'm fine that it's for the chairs to figure that out. > > S. > > >> Thanks, >> >> Yaron >> >> >> On 08/07/17 12:17, Stephen Farrell wrote: >>> Sean/Joe, >>> >>> This is a request that you, as chairs, shut down the distracting >>> wiretapping discussion, at least until DTLS1.3 is done. >>> >>> I have planned to spend time reading draft 21 and DTLS, but that >>> won't happen if we keep having to fight off the latest attempts >>> to break TLS. I'd not be surprised if I weren't the only one >>> finding that distraction an irritating waste of time. Finishing >>> TLS1.3 and getting DTLS1.3 on the way surely needs to not be >>> constantly de-railed by these attempts to break TLS. >>> >>> Therefore I'd ask that you declare this discussion closed for at >>> least that long (i.e until DTLS1.3 is done). >>> >>> I'd also ask that you not allocate agenda time for wiretapping in >>> Prague. >>> >>> Thanks, S. >>> >>> >>> >>> _______________________________________________ TLS mailing list >>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >> >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
