Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny wrote: >>provokes me to bring it up. Here's the crux of it; is it really a >>security win to recommend the AEAD cipher suites for TLS 1.2 users? I'm skeptical about the benefit of padding to 16 bytes. While it does

Re: [TLS] Include Speck block cipher?

On 17 March 2016 at 21:09, Martin Thomson wrote: > On 18 March 2016 at 12:37, Mike Hamburg wrote: >> No. The goal should be to remove ciphers, not add new ones, unless we have >> a really compelling reason. > > A necessary, but sufficient set of

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hi On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" wrote: >On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann > wrote: >> After a number of, uh, gentle reminders from people who have been >>waiting for >> this,

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hi On 16/03/2016 18:44, "Watson Ladd" wrote: >On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny > wrote: >> Hi >> >> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" >>> on behalf of watsonbl...@gmail.com> wrote: >> >>

Re: [TLS] Include Speck block cipher?

There is no serious proposal to use Speck in TLS 1.3. One major reason is that there is insufficient cryptanalysis of it. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

On Wed, Mar 16, 2016 at 2:30 PM, Adam Langley wrote: > On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny > wrote: > >>provokes me to bring it up. Here's the crux of it; is it really a > >>security win to recommend the AEAD cipher suites for TLS

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

https://tools.ietf.org/html/draft-gutmann-tls-lts-01#section-3.2 > TLS-LTS adds a hash of the domain parameters into the master secret > to protect against the use of manipulated curves/domain parameters: > > o TLS-LTS implementations MUST include a SHA-256 hash of the EDH or > ECDH

Re: [TLS] Simple, secure 0-RTT for the masses

On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara wrote: > > Benefits Forward Secrecy and Idempotence: > > > > * Client and server should erase the existing ticket upon use. > > > > (a captured early data section is mooted for replay quite quickly in the > > default

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Wan-Teh Chang writes: >This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section 8.2.2, >with the additional requirement that the comparison in Step 4 be constant- >time, right? Good catch, thanks! I've added it to the draft. Peter.

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

Hi Henry, Extension_data field can be zero-length: opaque extension_data<0..2^16-1>; The TLS 1.3 draft specifies matching rules for two extensions: KU and EKU and then says: "Separate specifications may define matching rules for other certificate extensions." Which means that you should be

Re: [TLS] Include Speck block cipher?

Piling on, I can't see why we would want to do this -Ekr On Thu, Mar 17, 2016 at 7:09 PM, Martin Thomson wrote: > On 18 March 2016 at 12:37, Mike Hamburg wrote: > > No. The goal should be to remove ciphers, not add new ones, unless we > have > >

[TLS] Include Speck block cipher?

Hello all. I have just found on the ietf archives an email discussion about the inclusion of the SPECK Cipher in the tls standards. It's reference is below : https://www.ietf.org/mail-archive/web/tls/current/msg13824.html Even though that this cipher originates from the NSA one cannot find a

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been waiting for > this, I've finally got around to posting the TLS-LTS draft I mentioned a while > back. It's now available as: > >

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny wrote: > Hi > > On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" on behalf of watsonbl...@gmail.com> wrote: > >>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann >>

[TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted)

On Fri, Mar 18, 2016 at 1:57 AM, Peter Gutmann wrote: > Watson Ladd writes: > >>As written supporting this draft requires adopting the encrypt-then-MAC >>extension. But there already is a widely implemented secure way to use MACs >>in TLS:

Re: [TLS] Include Speck block cipher?

On 18 March 2016 at 12:37, Mike Hamburg wrote: > No. The goal should be to remove ciphers, not add new ones, unless we have > a really compelling reason. A necessary, but sufficient set of reasons might include: 1. thorough cryptanalysis 2. advantages over existing ciphers

Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

> On 8 Mar 2016, at 09:30, Eric Rescorla wrote: > > CertificateRequest already allows you to pass an arbitrary number of > extensions by OID. > > http://tlswg.github.io/tls13-spec/#certificate-request > > > What more do

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Alexandre Anzala-Yamajako wrote: > > IMO, the layer creating the plaintext shouldn't have to pad it for security > that's the job of the TLS layer. Yep. And retrofitting random padding into TLS (all protocol versions, all PDUs) could be actually pretty simple and straightforward.

[TLS] TLS 1.2 Long-term Support Profile draft posted

After a number of, uh, gentle reminders from people who have been waiting for this, I've finally got around to posting the TLS-LTS draft I mentioned a while back. It's now available as: http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt Abstract: This document specifies a profile of TLS

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Hubert Kario writes: >also, if it really is supposed to be Long Term Support, why it doesn't say >anything about implementation explicitly being able to handle big key sizes? >both RSA and DHE? I've deliberately avoided getting into that because it's such a rathole, you've

Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been waiting for > this, I've finally got around to posting the TLS-LTS draft I mentioned a while > back. It's now available as: > >

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

> I hadn't seen that! I wonder is there an appetite here for including more > robust LH in TLS1.2 in some form? I mean a real one; as in - let's it get it > into servers and browsers sooner than TLS1.3.  H2 has padding; put it there. There is probably zero interest in adding padding to TLS

Re: [TLS] Include Speck block cipher?

No. The goal should be to remove ciphers, not add new ones, unless we have a really compelling reason. Short source code is not a compelling reason in a protocol so complicated as TLS. Cheers, — Mike > On Mar 16, 2016, at 11:35 PM, Efthymios Iosifides > wrote: > >

Re: [TLS] Simplifying signature algorithm negotiation

On Tue, Mar 15, 2016 at 05:37:20PM +, David Benjamin wrote: > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > > > I would probably characterize it less as suites vs orthogonality, but as > wanting to keep divisions in meaningful and universal places and not > splitting