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

[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

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

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

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

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

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 >

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 >

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

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

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

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

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

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". >>

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

On 7/16/17 7:55 AM, Salz, Rich wrote: > I am not offended. I am saying that if it terminates the connection it > is an endpoint not a middlebox. Well, maybe. That's certainly the general understanding of middleboxes (i.e that they they are not directly addressed [well, NATs, but] and that they