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 1.3 implementat
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 contain exactly one byte set to
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 i
(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 3
WGLC comments on draft-ietf-tls-tls13-18
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 3GPP already
next year
mandates support of both TLS 1.3 and DTLS 1.3 in all the places they use
(D)TLS.
Ch
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 psk_key_exchange_mode
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 expected to provide, like
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
expected to provide, like confidentiality, authentication, etc. Do we want to
say an
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 hiding the Con
Benjamin Kaduk wrote:
[ Charset windows-1252 unsupported, converting... ]
> 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
> 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
TLS@ie
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
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 _unc
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 _unconditionally_ provided in TLSv1.3
>
> (2) this value can be demonstrated to be a r
I'm sorry for the confusion. It seems I was wrong about OpenSSL behaviour.
Watson Ladd wrote:
> Martin Rex wrote:
>>
>> If you're vaguely familiar with OpenSSL:
>> when SSL_read() has received and processed a TLS record with a
>> close_notify alert, do you know what happens to further calls
>> of
On 11/09/2016 01:42 PM, Martin Rex wrote:
> Whether or not the calling App wants to shutdown a communication
> at different times in both directions depends on the existing semantics
> of that application (which has just added TLS protection around its
> communication). Reading and processing a cl
>
> There is no magic involved here.
>
> Apps *know* when to perform reads, and when not to perform reads.
> The middleware doesn't because it is protocol ignorant (it is used
> by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc).
>
> Think of a simple HTTP-based server app receiving a HTTP/1.0 reque
On Wed, Nov 9, 2016 at 11:42 AM, Martin Rex wrote:
> in reality, the Google servers perform pathological fragmentation
> of the AppData and use a whooping 36 TLS records for the response
> (curiously no TLS AppData record split between header and body).
>
At the beginning of a connection we aim
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 comp
On Nov 9, 2016 9:43 AM, "Martin Rex" wrote:
>
> 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 wit
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 "without
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 value"
On Wed, Nov 9, 2016 at 1:31 AM, Martin Rex wrote:
> Salz, Rich wrote:
> >> 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 w
Salz, Rich wrote:
>> 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 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 interest
Yoav Nir wrote:
>
>> On 3 Nov 2016, at 20:20, Martin Rex wrote:
>>
>>> With visible content type, you can tell these two flows apart.
>>
>> (a) so what? for those interested, one can tell such flows appart
>> pretty reliably by traffic analysis. So there is exactly ZERO
>> protection
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 existing middlewar
> 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. With the
>>> removal of reneg
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
>> possib
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 problem to
>>
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 bein
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
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 problem to
> keep the contenttype in the
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_!
>>
>> Also, things li
> 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 the
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
> ago.
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 isn't it really a WGLC
On Fri, Oct 28, 2016 at 08:35:45PM +0200, Martin Rex wrote:
> 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-compatibi
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 the
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 hear.
> Eric Res
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
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 can be discussed
On Fri, Oct 28, 2016 at 06:00:03PM +0200, 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) hidi
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 can be discussed at the meeting in
> Seoul. We hope to address any substantive issu
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
45 matches
Mail list logo
