On Thu, Mar 22, 2018 at 07:10:00PM +0200, Ilari Liusvaara wrote:
> I think BearSSL processes messages chunk-by-chunk. I think it even can
> process individual X.509 certificates chunk-by-chunk.
That's correct. In fact, it can process a complete handshake, including
the X.509 certificate chain, eve
On Thu, Mar 22, 2018 at 05:11:33PM +, Subodh Iyengar wrote:
> Ya I think you have the right idea. The former attack is the one
> that I'm more concerned about, i.e. compression libraries almost
> always provide streaming interfaces. Another case is that TLS
> implementations which are the users
Former and latter is a horrible way to refer to attacks :)
what I really meant is that when a receiver processing of timing of same TLS
record chunks triggers a bug in the decompressor.
Subodh
From: TLS on behalf of Subodh Iyengar
Sent: Thursday, March 22, 201
Ya I think you have the right idea. The former attack is the one that I'm more
concerned about, i.e. compression libraries almost always provide streaming
interfaces. Another case is that TLS implementations which are the users of
some decompression api might also provide the frames to the decom
On Thu, Mar 22, 2018 at 04:58:57PM +, David Benjamin wrote:
> To make sure I understand the issue, the concern is that your decompression
> function provides a chunk-by-chunk interface, there's a bug and the
> division into chunks produces a different result? Or are you suggesting
> that, with
To make sure I understand the issue, the concern is that your decompression
function provides a chunk-by-chunk interface, there's a bug and the
division into chunks produces a different result? Or are you suggesting
that, with the same chunking pattern, the result is still non-deterministic
somehow
Antoine and I were discussing draft-ietf-tls-certificate-compression over lunch
today and we think there could be a potential attack on the current scheme
which could be fixed with some changes.
Currently the CompressedCertificate is included in the handshake transcript..
However let's say a s
I am inclined to agree with Peter. It doesn't quite seem like a registry if
the very first time there is a list of things in it, that list is now frozen.
Why are we closing/reserving all the bits?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.o
> On Mar 22, 2018, at 10:10, Peter Gutmann wrote:
>
> Sean Turner writes:
>
>> I had a quick chat with the iANA folks about the HashAlgorithm and
>> SignatureAlgorithm, which we are effectively closing by marking all
>> unregistered bits as either reserved or depcreated. IANA suggested anothe
Sean Turner writes:
>I had a quick chat with the iANA folks about the HashAlgorithm and
>SignatureAlgorithm, which we are effectively closing by marking all
>unregistered bits as either reserved or depcreated. IANA suggested another
>way which is to just close the registry,
This seems a bit of
I had a quick chat with the iANA folks about the HashAlgorithm and
SignatureAlgorithm, which we are effectively closing by marking all
unregistered bits as either reserved or depcreated. IANA suggested another way
which is to just close the registry, An example for the registry follows:
[Apparently this was stuck in my 'drafts' folder; sorry if it has
since become stale...]
On Mon, Mar 19, 2018 at 07:20:04AM -0700, Colm MacCárthaigh wrote:
> It's true that breaking open cleartext runs counter to the mission of
> end-to-end TLS, but it also seems like operators are going to do it
12 matches
Mail list logo
