Re: [TLS] DTLS KeyUpdate

On Tue, Oct 31, 2017 at 10:45 PM, Martin Thomson wrote: > (From https://github.com/tlswg/dtls13-spec/issues/25) > > Using the TLS process for KeyUpdate - as the current draft does - > leads to a suboptimal set of choices in implementations. > > Sending KeyUpdate followed immediately by a key chan

[TLS] Draft RHRD

In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, Nick Sullivan concluded: >- on the other hand using draft-rhrd is safer than allowing organizations to >hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with >non-forward-secret cipher suites I think this sets up

Re: [TLS] Draft RHRD

On 01/11/17 14:18, Salz, Rich wrote: > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, > Nick Sullivan concluded: > >> - on the other hand using draft-rhrd is safer than allowing >> organizations to hack single-key escrow into TLS 1.3 or continue to >> use TLS 1.2 with non-fo

Re: [TLS] Draft RHRD

Rich: > On Nov 1, 2017, at 10:18 AM, Salz, Rich wrote: > > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html > , Nick > Sullivan concluded: > > >- on the other hand using draft-rhrd is safer than allowing organ

Re: [TLS] Draft RHRD

* Indeed, anyone can implement the approach in draft-green, which has no opt-in capability. In Prague, we heard that a lot of people would be more comfortable with an opt-in capability, so we specified an extension that does so. I get it. And in retrospect, I am convinced that was a bad d

Re: [TLS] Draft RHRD

Rich, I think you're mixing things up a bit. There is no false comparison. I am not comparing draft-rhrd to the Wireshark option, they are fundamentally different. I'm comparing draft-rhrd to draft-green. The wireshark option requires storage of n keys to inspect n connections, both draft-rhrd and

Re: [TLS] Draft RHRD

* I think you're mixing things up a bit. That’s quite possible. * I'm comparing draft-rhrd to draft-green. The wireshark option requires storage of n keys to inspect n connections, both draft-rhrd and draft-green only require a single master key to inspect n connections. Draft-green r

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

Some feedback, in no particular order: * have a hard think about handshake/termination loads. istm this scheme devolves pretty quickly to a termination per object HTTP/1.0 style so you'll be fairly quickly looking to do some kind of multiplexing and reuse on top of it for the same reasons HTTP evo

[TLS] [Technical Errata Reported] RFC7301 (5176)

The following errata report has been submitted for RFC7301, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". -- You may review the report below and at: http://www.rfc-editor.org/errata/eid5176 -

Re: [TLS] [Technical Errata Reported] RFC7301 (5176)

I don't think that this is an appropriate way to request the addition of ALPN labels. If it is important to register ALPN labels for these protocols, then the HTTP working group can produce a short document defining them. On Thu, Nov 2, 2017 at 4:24 PM, RFC Errata System wrote: > The following e

Re: [TLS] [Technical Errata Reported] RFC7301 (5176)

Wasn't sure what the appropriate route is.. apologies for the noise. :-) Should I file a bug against http-wg ? On Wed, Nov 1, 2017 at 10:30 PM, Martin Thomson wrote: > I don't think that this is an appropriate way to request the addition > of

Re: [TLS] [Technical Errata Reported] RFC7301 (5176)

Maybe you should start by sending an email to the working group, explaining why you think that this is necessary. Because the way to change these things ultimately is to publish an RFC. On Thu, Nov 2, 2017 at 4:33 PM, Ilya Grigorik wrote: > Wasn't sure what the appropriate route is.. apologies f