Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On 21 November 2016 at 14:13, Eric Rescorla wrote: >> IMO, the compression methods section of ClientHello should be ignored as >> mentioned by Martin Rex. > > I'm not seeing any good reason for this. We don't want anyone to offer > compression and it's not > like it's difficult for

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Sun, Nov 20, 2016 at 5:42 PM, Yuhong Bao wrote: > I can't help but notice the text: > "Versions of TLS before 1.3 supported compression with the list of > supported compression methods being sent in this field. For every TLS 1.3 > ClientHello, this vector MUST

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

I can't help but notice the text: "Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field. For every TLS 1.3 ClientHello, this vector MUST contain exactly one byte set to zero, which corresponds to the “null” compression method

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

(This is the same comments as yesterday, just resending them as my mail client turned my text into an unreadable mess, hopefully this is better). Hi, Very well written draft and an excellent protocol. The things I have found is mostly editorial. I think it’s ready. I will try to make sure that

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Unfortunately, Outlook seems to be incapable of properly quoting a message for inline replies, so I will have to top-post with the relevant bits. I’ll try to put together some text on side-channel resistance along with my pull request for editorial changes. With respect to

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben wrote: > I have reviewed this document and have a few minor comments. I also have > many editorial notes that can be addressed out of band. > > In the abstract and introduction, we have text about the properties that > TLS is

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Martin Rex writes: >There is a concept called "provable correctness", The problem with provable whatever is that it merely proves that, as far as the provers can tell, the thing they're dealing with conforms to some abstract model. I don't think you can prove much about whatever

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

> There is a concept called "provable correctness", and folks (such as those Hm, your arguments against it are that heuristics will expose the information anyway. Has provability advanced far enough to include that concept? ___ TLS mailing list

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On 11/10/2016 11:13 AM, Martin Rex wrote: > > There is a concept called "provable correctness", and folks (such as > those from the miTLS implementation) are using this approach to check/prove > whether TLS provides certain security properties (rather than just > assuming that these properties are

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Benjamin Kaduk wrote: [ Charset windows-1252 unsupported, converting... ] > On 11/09/2016 11:42 AM, Martin Rex wrote: > > Nobody so far has provide a single example of *REAL* value. > > For the hiding of ContentType to provide real value, the prerequisites are: > > > > (1) this value will be

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Eric Rescorla wrote: > > I'm not quite following who's who in this scenario, so some potentially > stupid > questions below. > > As I understand it, you have the following situation: > > - A Web application server > - Some middleware, which comes in two pieces > - A crypto-unaware network

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Daniel Kahn Gillmor wrote: > > Martin Rex wrote: >> >> The problem here is that this breaks (network) flow control, existing >> (network socket) event management, and direction-independent connection >> closure, and does so completely without value. > > Martin, you keep saying things like

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Wed 2016-11-09 03:31:22 -0600, Martin Rex wrote: > The problem here is that this breaks (network) flow control, existing > (network socket) event management, and direction-independent connection > closure, and does so completely without value. Martin, you keep saying things like "without

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

> the PDUs are still pretty much predictable > heuristically (by their ordering), even when they're padded. ... > So besides being completely pointless, can you describe any realistic problem > that is worth breaking middleware at the endpoints so badly? I found the language difference

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Thu, Nov 03, 2016 at 08:38:32PM +0200, Yoav Nir wrote: > > > On 3 Nov 2016, at 20:20, Martin Rex wrote: > > > > -- so why would we need a backwards-incompatible change in a > > protocol that protects something that no longer exists, > > but which severely breaks

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

> On 3 Nov 2016, at 20:20, Martin Rex wrote: > > Yoav Nir wrote: >> >> On 3 Nov 2016, at 16:31, Martin Rex wrote: >>> >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>> which has existed through SSLv3->TLSv1.2 would be a problem.

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On 11/03/2016 01:15 PM, Martin Rex wrote: > Salz, Rich wrote: >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>> which has existed through SSLv3->TLSv1.2 would be a problem. >> Because it's kind of implied in the charter, about making as much private as >>

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Yoav Nir wrote: > > On 3 Nov 2016, at 16:31, Martin Rex wrote: >> >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. With the >> removal of renegotiation from TLSv1.3, it is even less of a

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Salz, Rich wrote: >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. > > Because it's kind of implied in the charter, about making as much private as > possible. > >> years), because it is actively

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

I don’t think this makes any difference in applications written on commodity servers using regular socket APIs. It’s a kind of architecture that has a quick special purpose processor that terminates the TCP and splits the incoming stream into records. The application records are forwarded to a

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex wrote: > Ilari Liusvaara wrote: Hiding the types does have its benefits (and it is also used for zero-overhead padding scheme). >>> >>> Nope, ZERO benefits. But it totally breaks the middleware >>> _at_the_endpoints_! >> >>

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, > which has existed through SSLv3->TLSv1.2 would be a problem. Because it's kind of implied in the charter, about making as much private as possible. > years), because it is actively being used to signal state of

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Ilari Liusvaara wrote: >>> >>> Hiding the types does have its benefits (and it is also used for >>> zero-overhead padding scheme). >> >> Nope, ZERO benefits. But it totally breaks the middleware >> _at_the_endpoints_! > > Also, things like this should have been discussed like year or two >

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

The concern here is that people won’t review it until the end and that is definitely not what we want. I’d really like get the most out of our f2f meeting in Seoul so pretty please people review it before Seoul. spt > On Oct 27, 2016, at 07:07, Salz, Rich wrote: > > So

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Ilari Liusvaara wrote: > Martin Rex wrote: >> Joseph Salowey wrote: >> >> There are two seriously backwards-incompatible changes in the >> current proposal that provide zero value, but completely break >> backwards-compatibility with existing middleware infrastructure. >> >> >> (1) hiding of

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex wrote: > If the server_name remains in plaintext and full sight in ClientHello > (where it needs to be for TLSv1.2 backwards compatibility anyway), > then I don't have an issue. (I'm sorry for not reading the draft in full) Good to

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

If the server_name remains in plaintext and full sight in ClientHello (where it needs to be for TLSv1.2 backwards compatibility anyway), then I don't have an issue. (I'm sorry for not reading the draft in full). Eric Rescorla wrote: > >> (2) hiding of the TLS extension SNI. >> Right now it

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Sat, Oct 29, 2016 at 3:00 AM, Martin Rex wrote: > Joseph Salowey wrote: > > > > This is a working group last call announcement for > draft-ietf-tls-tls13-18, > > to run through November 20. If possible, we would like to receive > comments > > on the list by November 13 so they

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

So isn't it really a WGLC that runs until end of January 2017? -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls