On Sun, Nov 01, 2015 at 04:36:43AM +0900, Eric Rescorla wrote:
>
> I've been planning to do a big rewrite of the security "analysis" sections
> and while I don't think it's worth having a real analysis in the protocol
> (the literature is going to do a much better job here than we can), this
> see
Nice analysis! I think that the composition of different mechanisms in the
protocol is likely to
be where many subtle issues lie, and analyses like this one support that
concern.
Several other composition examples were already discussed on this list (for
previous drafts).
For example, when comp
Hi All,
A new TLS extension draft for omitting the explicit nonce included in every
record when AEAD ciphers are used has been proposed. This extension allows the
Client Hello & Server Hello messages to negotiate a method for generating
explicit nonce and thereby omit including it in every TLS/
Hi Eric,
Thanks for your response.
1. There is already no requirement that you have an explicit nonce. RFC5246
merely requires that you specify the length of the explicit nonce, but that
length can be 0, as it is in the ChaCha/Poly drafts. So, rather than build
an extension it would be better to
I strongly oppose any new crypto that does not include a fix for the
ephemeral keygen.
The reason logjam is possible is that the key negotiation is essentially
1) Negotiate a shared secret S1 using the strong, long term server key.
2) Use the shared secret to authenticate ephemeral key parameters
Based on CRIME and BREACH we know that this construction is not secure:
C = encrypt(compress(A || B))
If you control B and A contains sensitive information, strlen(C) tells you
information about A. Vice versa if you control A and B contains sensitive
information.
In the context of a web applicat
Hello Benjamin,
> No, mutual authentication requires the client to receive a message from
> the server.
Yes, I know -- the server needs to handle the session key or the subkey
to prove posession of its KDC-stored service key. By using it, the client
can be convinced or server identity.
> This c
2015/10/03 0:24、Salz, Rich のメッセージ:
>
>> 1) We know CRIME threat, but it can not be risk for everyone.
>> e.g., CVSS v2 Base Score: 2.6 (LOW)
>
> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called it
> 7.5
We know it, but one of indicators.
How can you say the dangerou
> Browsers are not a concern as they already have their own comp/decomp codes.
> HTTP/1 can compress content (Content-encoding and transfer-encoding) and
> HTTP2 has additional header compression.
>
I see,
but contrary,
tls is only for browser?
And more,
if you kick out comp/decomp from
I thought we already decided to remove compression from TLS 1.3.
Russ
On Oct 8, 2015, at 10:10 PM, Scott Arciszewski wrote:
> Based on CRIME and BREACH we know that this construction is not secure:
>
> C = encrypt(compress(A || B))
>
> If you control B and A contains sensitive information, st
On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote:
> I thought we already decided to remove compression from TLS 1.3.
We did.
See here:
https://www.ietf.org/mail-archive/web/tls/current/msg17941.html
On Thursday, October 08, 2015 10:10:51 pm Scott Arciszewski wrote:
> Compression has n
I’ve uploaded the agenda:
https://www.ietf.org/proceedings/94/agenda/agenda-94-tls
I’ll post slides as I get them.
spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
My bad there were some messages sitting in the moderator queue that I let go.
spt
> On Nov 02, 2015, at 10:01, Dave Garrett wrote:
>
> On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote:
>> I thought we already decided to remove compression from TLS 1.3.
>
> We did.
>
> See here:
> h
It's not entirely clear what you are asking for here, but have you
looked at the key derivation in TLS 1.3?
On 16 October 2015 at 01:27, Phillip Hallam-Baker wrote:
>
> I strongly oppose any new crypto that does not include a fix for the
> ephemeral keygen.
>
> The reason logjam is possible is th
Hi Eric,
As you asked the question about how many ciphertext blocks should be safe under
a single key, I think it is safe to have 2^96 blocks under a given key if the
IV (counter) is 96 bits.
When there is a collision between two ciphertext blocks when two different
counter values are used ,
15 matches
Mail list logo
