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

On 7/17/17 1:23 AM, Daniel Kahn Gillmor wrote: > Could you point me (and the list) to those requirements, please? More > specificity than "some countries" would be a useful contribution to this > discussion. At the time when I was working on VoIP there were a few countries, such as South Africa,

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

On Sun 2017-07-16 12:44:04 +0300, Wartan Hachaturow wrote: > On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor wrote: > >> > Not to mention the security & troubleshooting applications which >> > require insight into the cryptostream on the wire. >> >> I asked for examples of regulation

[TLS] 答复: Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

Hi Wing, I noticed that Helloverifyrequest is optional by the server and used when DOS is to be mitigated. But from practical use cases, the IOT server may not have dedicated anti-DOS mechanism. If there is a more power-saving solution with the function of DOS mitigation retained, and don't

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

>From a HTTP standpoint, they are the origin (i.e., endpoint). They just happen >to use HTTP "behind" them. > On 15 Jul 2017, at 10:39 pm, Roland Zink wrote: > > I think reverse proxies are middleboxes regardless if they have official > origin TLS certificates. From the TLS viewpoint they may

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

Thanks for the clarification Watson. I am always looking to learn new tricks and was hoping you might had one for distributed, large scale, remote packet captures.This is one area we have yet to fully conquer. What you describe is something different, but also valuable and useful. But the b

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

It seems that us Enterprise folks have not been clear. Every Enterprise I know has invested HEAVILY in infrastructures that tap, transport and process terabytes of packet trace or .pcap data every day. This is huge and omnipresent in all large Enterprise environments. AND IT WORKS! For

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

Am 16.07.2017 um 00:07 schrieb Watson Ladd: On Jul 15, 2017 12:33 PM, "Roland Zink" > wrote: see inline Roland Am 15.07.2017 um 03:40 schrieb Watson Ladd: On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins mailto:rdobb...@arbor.net>> wrot

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

On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor wrote: > > Not to mention the security & troubleshooting applications which > > require insight into the cryptostream on the wire. > > I asked for examples of regulations that specifically require plaintext > from the network. Some co

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

On Sun, Jul 16, 2017 at 5:14 AM, Salz, Rich wrote: > Within an enterprise that believes they need this kind of > packet-capture-decode thing, what are the other benefits of TLS 1.3? They > can already use good ciphers. They save the cost of not uplifting existing > infrastructure. They lose 0RTT

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

> The main one I'm concerned about is me having to support non-TLS1.3 clients > ;-) 1RTT key exchange is worth it alone. The key point here is Within the enterprise. The amount of work one development team has to do, compared to the world, doesn't matter. ___

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

On Sun, Jul 16, 2017 at 2:08 AM, Ted Lemon wrote: > What it means for users to be denied the benefits of TLS 1.3 is that they > don't get, for example, perfect forward secrecy. Since the proposal was to > do away with that anyway, but for all users, not just some users, that > doesn't seem like

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

Within an enterprise that believes they need this kind of packet-capture-decode thing, what are the other benefits of TLS 1.3? They can already use good ciphers. They save the cost of not uplifting existing infrastructure. They lose 0RTT early-data, which when viewed globally seems like a reaso

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

What it means for users to be denied the benefits of TLS 1.3 is that they don't get, for example, perfect forward secrecy. Since the proposal was to do away with that anyway, but for all users, not just some users, that doesn't seem like it is better than just continuing to use TLS 1.2. It's alre

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

On Sun, Jul 16, 2017 at 1:52 AM, Salz, Rich wrote: > I would also like to understand why TLS 1.2 is not sufficient for, say, > the next five years. > It probably is ... but isn't that the problem? If the answer is "Just let them stay on TLS1.2", I find it very hard to interpret the arguments aga

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

I would also like to understand why TLS 1.2 is not sufficient for, say, the next five years. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell wrote: > > (*) I am not asking that people tell me that "pcap+key-leaking" > might work, but for them to describe when that works but nothing > else works. And that has to include the details of what it is > they can only find in the recovered clea

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

Hiya, On 15/07/17 20:49, Roland Zink wrote: > TLS is a two endpoint protocol. It looks like many of the use cases > describe problems with more than two endpoints but are using TLS because > it is commonly available. So should TLS be extended to be an n-party > protocol (or is this always conside

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

Hiya, On 16/07/17 05:41, Colm MacCárthaigh wrote: > On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell > wrote: > >> On 15/07/17 23:55, Colm MacCárthaigh wrote: >>> So far responses on the mailing list have been saying "Don't use >>> pcap, instead run proxies". >> Sorry, but that is incorrect.