Julien ÉLIE writes:
> Hi Karthik,
>
>> It may well be true that some (typically unauthenticated) application
>> protocols on top of TLS can survive TLS compression, but it is
>> unlikely.
> [...]
>> HTTP is a particularly bad case because the attacker can potentially
>> inject arbitrary data befo
On Sep 21, 2015, at 10:43 PM, Hubert Kario wrote:
>
>> I doubt anyone would really want to use any keys in the megabyte range
>> anyway. Post-quantum crypto research/experimentation for TLS & other
>> network protocols should really focus on systems with smaller keys.
>> Even if a giant-key schem
> On 22 Sep 2015, at 01:40, Geoffrey Keating wrote:
>
> Daniel Kahn Gillmor writes:
>
>> Consider a server has an ongoing session wrapped in TLS that uses client
>> authentication to approve or deny some requests from the client. It
>> remembers what requests the client has made as some sort
Also, if compression is moved from TLS to upper layer(s) - how would it
mitigate compression-related attacks? Besides "now it's somebody else's
problem"?
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
Original Message
From: Simon Josefsson
Sent: Tuesday, Septem
On Tue, Sep 22, 2015 at 9:23 AM, Blumenthal, Uri - 0553 - MITLL
wrote:
> Also, if compression is moved from TLS to upper layer(s) - how would it
> mitigate compression-related attacks? Besides "now it's somebody else's
> problem"?
Exactly. Upper-level layers can do the analysis to indicate when
Hi all,
On 22 September 2015 at 15:23, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Also, if compression is moved from TLS to upper layer(s) - how would it
> mitigate compression-related attacks? Besides "now it's somebody else's
> problem"?
>
It allows the authors of the layers ab
Hi Henry,
> 1) it will be possible on the same connection to authenticate with multiple
> different certificates,
With the current proposal as it stands, yes.
> 2) the different identities won't ( necessarily ? ) be cumulative ie, a
> server getting the identity I1 and then I2 on the same TLS c
On Tue, Sep 22, 2015 at 6:23 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:
> Also, if compression is moved from TLS to upper layer(s) - how would it
> mitigate compression-related attacks? Besides "now it's somebody else's
> problem"?
This is the wrong way of looking at it. Keepin
"henry.st...@bblfish.net" writes:
> > On 22 Sep 2015, at 01:40, Geoffrey Keating wrote:
> >
> > Daniel Kahn Gillmor writes:
> >
> >> Consider a server has an ongoing session wrapped in TLS that uses client
> >> authentication to approve or deny some requests from the client. It
> >> remember
On 22/09/15 17:23, Tony Arcieri wrote:
> But an unsafe feature shouldn't be kept in
> TLS just because some protocols want to do unsafe things and are too lazy
> to implement their own compression.
Compression does have issues clearly, but it's not correct to describe
people wanting TLS to compr
On 9/21/15, Daniel Kahn Gillmor wrote:
> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni
> wrote:
>> So the client would now need to cache some session data by transport
>> address, and other data by name and port. That's rather complex.
>
> This is already done by HTTP/2 clients, since they c
On Tue, Sep 22, 2015 at 1:35 PM, Stephen Farrell
wrote:
>
>
> On 22/09/15 17:23, Tony Arcieri wrote:
>> But an unsafe feature shouldn't be kept in
>> TLS just because some protocols want to do unsafe things and are too lazy
>> to implement their own compression.
>
> Compression does have issues cl
Hi Tony,
Keeping compression in TLS endorses unsafe usage of a feature known
to introduce compression sidechannels.
Whether other protocols decide to introduce their own secondary
compression layer is their own prerogative. But an unsafe feature
shouldn't be kept in TLS just because some protoc
On Tue, Sep 22, 2015 at 1:39 PM, Jacob Appelbaum wrote:
> On 9/21/15, Daniel Kahn Gillmor wrote:
>> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni
>> wrote:
>>> So the client would now need to cache some session data by transport
>>> address, and other data by name and port. That's rather co
On Tuesday, September 22, 2015 02:16:47 pm Julien ÉLIE wrote:
> Regarding vulnerable protocols, clients (and/or servers) could very well
> disable compression in TLS. And either never use compression or
> implement their own compression, according to their needs.
> It is what happened with BEAST
> On Sep 22, 2015, at 8:35 PM, Stephen Farrell
> wrote:
>
>
>
> On 22/09/15 17:23, Tony Arcieri wrote:
>> But an unsafe feature shouldn't be kept in
>> TLS just because some protocols want to do unsafe things and are too lazy
>> to implement their own compression.
>
> Compression does have i
We discussed this before. Not that we can't discuss it again. Here's a link
to slides I presented at the Toronto Interim in July 2015.
https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing
___
TLS mailing list
TLS@iet
Hi Dave,
No sane security protocol should allow any mode which is known to be
insecure under its common use-case.
Then the default in TLS 1.3 could be to not activate compression.
TLS 1.2 is technically
configurable in a secure manner, but hardly anyone does so correctly.
With TLS 1.3, we n
The security community thinks that compression is risky, error-prone, and that
a security/auth layer is the wrong place to put it.
So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to
move to TLS 1.3 without losing data compression."
Is this accurate?
--
Senior Archit
Hi Rich,
The security community thinks that compression is risky, error-prone,
and that a security/auth layer is the wrong place to put it.
So far, the only counter-argument has been "if TLS 1.2 has a flaw, I
want to move to TLS 1.3 without losing data compression."
Is this accurate?
Thanks
On 22/09/15 19:32, Yoav Nir wrote:
>
>> On Sep 22, 2015, at 8:35 PM, Stephen Farrell
>> wrote:
>>
>>
>>
>> On 22/09/15 17:23, Tony Arcieri wrote:
>>> But an unsafe feature shouldn't be kept in
>>> TLS just because some protocols want to do unsafe things and are too lazy
>>> to implement their
> On Sep 22, 2015, at 9:40 PM, Salz, Rich wrote:
>
> The security community thinks that compression is risky, error-prone, and
> that a security/auth layer is the wrong place to put it.
>
> So far, the only counter-argument has been "if TLS 1.2 has a flaw, I want to
> move to TLS 1.3 without
On 09/22/2015 02:44 PM, Yoav Nir wrote:
>> On Sep 22, 2015, at 9:40 PM, Salz, Rich wrote:
>>
>> The security community thinks that compression is risky, error-prone, and
>> that a security/auth layer is the wrong place to put it.
>>
>> So far, the only counter-argument has been "if TLS 1.2 has a
On Tue, Sep 22, 2015 at 02:56:36PM -0400, Jeffrey Walton wrote:
>
> If compression increases entropy, then one could argue its a desired
> service with security benefits.
Compression does not change the total amount of entropy. It has
the same entropy but in less bits, so you increase the densit
On Sun, Sep 20, 2015 at 9:56 PM, Brian Smith wrote:
> On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla wrote:
>
>> https://github.com/tlswg/tls13-spec/pull/248
>>
>> Aside from some analytic advantages
>>
>
> What are the analytic advantages?
>
The advantages are: a cleaner separation of keys de
I’ve gone ahead and posted the minutes/list of decisions to:
https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
"Versions of TLS prior to 1.3 had limited support for padding. This padding
scheme was selected because it allows padding of any encrypted TLS record
by an arbitrary size (from zero up to TLS record size limits) without
introducing new content types. The design also enforces all-zero padding
octets
Thanks.
What sort of errors are we trying to avoid by making sure implementations have
to check for zeroed padding? Are we really worried some sloppy implementation
is going to leave it uninitialized in a memory-unsafe language and just encrypt
an arbitrary block of memory? This was mentioned a
Benjamin Kaduk writes:
>Well, this just came across my browser:
>http://google-opensource.blogspot.co.uk/2015/09/introducing-brotli-new-
>compression.html
There's a million compression algorithms [0] out there, you shouldn't have any
problem finding one to fit your needs, and you don't really ne
I think there is a compression extension for NNTP:
http://tools.ietf.org/id/draft-murchison-nntp-compress-01.html
it doesn't seem too hard. My 2c: even if this were not the case, optimizing
NNTP in a backwards compatible way does seem like a more important goal
than making transport security as s
On Tue, Sep 22, 2015 at 8:32 PM, Colm MacCárthaigh
wrote:
> it doesn't seem too hard. My 2c: even if this were not the case,
> optimizing NNTP in a backwards compatible way does seem like a more
> important goal than making transport security as secure as possible by
> default.
>
I don't think I
> On 22 Sep 2015, at 01:40, Geoffrey Keating wrote:
>
> Daniel Kahn Gillmor writes:
>
>> Consider a server has an ongoing session wrapped in TLS that uses client
>> authentication to approve or deny some requests from the client. It
>> remembers what requests the client has made as some sort
32 matches
Mail list logo
