Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

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

[TLS] FW: New Version Notification for draft-jay-tls-omit-aead-explicit-nonce-extension-00.txt

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] Fwd: [pkix] Updated elliptic curve drafts

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

[TLS] TLS 1.3 - Just ditch compression

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

Re: [TLS] Design Alternatives for Kerberos + DH

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

Re: [TLS] Fwd: [pkix] Updated elliptic curve drafts

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

> 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

Re: [TLS] TLS 1.3 - Just ditch compression

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,

Re: [TLS] TLS 1.3 - Support for compression to be removed

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

Re: [TLS] TLS 1.3 - Just ditch compression

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. > >

[TLS] IETF 94 - TLS agenda

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

[TLS] Collision issue in ciphertexts.

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