Hi Rich,
It is widely recognized that in many cases, TLS-level compression is
flawed (for example NNTP authinfo?).
Though I've read a few pages explaining how CRIME and BEAST attacks
work, I still do not see well how TLS-level compression would make NNTP
vulnerable.
Same thing for POP or IM
On Sun, Sep 20, 2015 at 5:02 AM, Julien ÉLIE wrote:
> Hi Rich,
>
>> It is widely recognized that in many cases, TLS-level compression is
>> flawed (for example NNTP authinfo?).
>
>
> Though I've read a few pages explaining how CRIME and BEAST attacks work, I
> still do not see well how TLS-level c
Hi Watson,
Though I've read a few pages explaining how CRIME and BEAST attacks work, I
still do not see well how TLS-level compression would make NNTP vulnerable.
Same thing for POP or IMAP I believe.
The news server does not leak information. The responses are just OK or KO.
This analysis w
Julien,
It may well be true that some (typically unauthenticated) application protocols
on top of TLS can survive TLS compression,
but it is unlikely. You ask a pointed question about AUTHINFO, so just as a
fun game, let’s analyze its security:
AUTHINFO USER test
381 Enter password
AUTHINFO P
> How compression would make NNTP weaker?
> (Brute-force attack is still necessary, even with compression enabled.)
I don't know, which is why I put a question mark; someone else suggested it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailm
On Sun, Sep 20, 2015 at 11:02:19AM +0200, Julien ÉLIE wrote:
> Though I've read a few pages explaining how CRIME and BEAST attacks work, I
> still do not see well how TLS-level compression would make NNTP vulnerable.
> Same thing for POP or IMAP I believe.
>
> The news server does not leak inform
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 before (and after) the secret. With NNTP y
Hi Geoffrey,
I bet other protocols would also need similar new specifications to
explain how compression can be enabled.
I think that's the idea. TLS compression only works for NNTP because no
confidentiality is required. In other protocols, there's at least
something (if not everything) whe
On Wed 2015-09-16 13:48:27 -0400, Martin Thomson
wrote:
> On 16 September 2015 at 08:30, Ilari Liusvaara
> wrote:
>> As then the application needs to ensure that the authentication
>> occurs between TLS handshake and actually starting up the protocol.
>
> I'm not sure that is necessarily a prob
On Fri 2015-09-18 15:47:27 -0400, "Salz, Rich" wrote:
> Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression
> feature you need? What TLS 1.3 feature is compelling here?
I think this line of argument is worrisome -- we should try to avoid
leaving behind protocols that need TLS, i
On Sat, Sep 19, 2015 at 12:04 PM, Daniel Kahn Gillmor wrote:
> I think we should remove compression and we should also explicitly warn
> users of the protocol about the risks of combining compression with TLS.
+1
--
Tony Arcieri
___
TLS mailing list
https://github.com/tlswg/tls13-spec/pull/248
Folks,
Hugo Krawczyk, Hoeteck Wee, and Bjorn Tackmann suggested a revision
to the key hierarchy that separates out the computation of the MS from the
computation of the keys that are derived from ES and SS. Specifically,
xES and xES are to be used to d
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?
Also, a question that applied even to the older design: I remember the an
HKDF paper and the HKDF paper stating that b
Hi all,
We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as
suggested by DKG in Prague. All comments welcome.
There's an interesting issue here: McEliece keys, which should be
permissible, are larger in size (about 2^20 bytes) than the maximum
permissible extension size (2
On Sun, Sep 20, 2015 at 6: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?
>
As I said, a clearer separation between the input ke
William Whyte writes:
> Hi all,
>
> We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as
> suggested by DKG in Prague. All comments welcome.
>
> There's an interesting issue here: McEliece keys, which should be
> permissible, are larger in size (about 2^20 bytes) than the
Geoffrey Keating writes:
>That would affect the initial client hello, which I think we're trying to
>keep backwards compatible. It might be better to just define a rule like "if
>multiple extensions with the same number are present, their values are
>concatenated".
A better one would be "if you
On Sun, Sep 20, 2015 at 7:59 PM, William Whyte <
wwh...@securityinnovation.com> wrote:
> Hi all,
>
> We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions
> as suggested by DKG in Prague. All comments welcome.
>
> There's an interesting issue here: McEliece keys, which should be
As dkg points out, dynamically authenticating clients later in the connection
brings up
API issues of how to notify the application about the scope of this new
authentication event.
I think it is inevitable that implementation will store the client credential
in the session, and
that the new (a
19 matches
Mail list logo
