[TLS] Re-use and export of DH shares

Hi. I’ve created a PR for TLS 1.3 https://github.com/tlswg/tls13-spec/pull/768 It adds a subsection to the Security Considerations section. It discusses key reuse (do it carefully or do it not). It has the "don't do this or this grape juice might ferment" weasel words suggested by someone at th

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

(This is the same comments as yesterday, just resending them as my mail client turned my text into an unreadable mess, hopefully this is better). Hi, Very well written draft and an excellent protocol. The things I have found is mostly editorial. I think it’s ready. I will try to make sure that 3

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

Hi Rich, I am confused by your response. For those who missed CURDLE, could you please briefly explain why we don't need signature context in non-TLS areas. And even if this is the case, the current thread is about TLS! So why are we now saying that contexts are not needed even for TLS? Th

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

> For those who missed CURDLE, could you please briefly explain why we don't > need signature context in non-TLS areas. The one place we were concerned about attacks was in pre-hash signatures, and we made those a MUST NOT. And yes, your'e right, it's not relevant to TLS. > So why are we now sa

Re: [TLS] Confirming consensus: TLS1.3->TLS*

I'm definitely for 1.3. I get where 4 is coming from, but 1.2 is not going anywhere soon, and we spent the last 10 years training people that the high-numbered one is bad, and that the 1.x ones are cool. I really don't want to have the following conversation, with the exact same people the propon

Re: [TLS] Confirming consensus: TLS1.3->TLS*

The messages on the list seem to be perfectly split between "TLS 1.3" and "TLS 4". I suspect that the "TLS 2017" idea will break this impasse: * it shares the fundamental advantage that led to the "TLS 4" idea; * it has the additional advantage of making the age obvious; * it eliminates t

Re: [TLS] Confirming consensus: TLS1.3->TLS*

I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the major version number we should abandon the minor one). TLS 2017 strikes me as quite bad; we're certainly not planning to do a TLS 2018. I am strongly opposed to TLS 2017. -Ekr On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wro

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

I can't help but notice the text: "Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field. For every TLS 1.3 ClientHello, this vector MUST contain exactly one byte set to zero, which corresponds to the “null” compression method i

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On Sun, Nov 20, 2016 at 2:17 PM, Filippo Valsorda wrote: > I'm definitely for 1.3. > > I get where 4 is coming from, but 1.2 is not going anywhere soon, and we > spent the last 10 years training people that the high-numbered one is > bad, and that the 1.x ones are cool. > > I really don't want to

Re: [TLS] Confirming consensus: TLS1.3->TLS*

On 11/21/16 at 4:56 PM, d...@cr.yp.to (D. J. Bernstein) wrote: The messages on the list seem to be perfectly split between "TLS 1.3" and "TLS 4". I suspect that the "TLS 2017" idea will break this impasse: * it shares the fundamental advantage that led to the "TLS 4" idea; * it has the addition

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On Sun, Nov 20, 2016 at 5:42 PM, Yuhong Bao wrote: > I can't help but notice the text: > "Versions of TLS before 1.3 supported compression with the list of > supported compression methods being sent in this field. For every TLS 1.3 > ClientHello, this vector MUST contain exactly one byte set to

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On 21 November 2016 at 14:13, Eric Rescorla wrote: >> IMO, the compression methods section of ClientHello should be ignored as >> mentioned by Martin Rex. > > I'm not seeing any good reason for this. We don't want anyone to offer > compression and it's not > like it's difficult for 1.3 implementat

Re: [TLS] Confirming consensus: TLS1.3->TLS*

+1 for “TLS 2017” for all the four reasons given in the proposal. My overall preference is TLS 2017 > TLS 4 > TLS 2 or 2.0 > TLS 1.3. Best, Xiaoyin From: D. J. Bernstein Sent: Sunday, November 20, 2016 7:56 PM To: tls@ietf.org Subject: Re: [TLS]

Re: [TLS] Confirming consensus: TLS1.3->TLS*

I give the chairs my full support for whatever colour they wish to paint this bikeshed. > On 18 Nov. 2016, at 1:12 pm, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.iet

Re: [TLS] Confirming consensus: TLS1.3->TLS*

> On Nov 20, 2016, at 7:56 PM, D. J. Bernstein wrote: > > Of course people who prioritize retaining the existing "TLS 1.3" > mindshare will be just as unhappy with "TLS 2017" as with "TLS 4", but > they'll get over it within a few years. :-) This worked well enough for IDNA2003 and IDNA2008 (th

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

So the key schedule changed and therefore we think cross-version attacks are impossible. Have we also analyzed other protocols to ensure that cross protocol attacks, e.g. with SSH or IPsec, are out of the question? Put differently, algorithm designers gave us a cheap, easy to use tool to avoid

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Eric Mill writes: >The near-term annoyance of renaming things by folks close to the WG, and the >chance of some confusion around the edges, seem like small issues compared to >a positive investment in bending the sanity curve of the next 20 years of >lazy enterprise decisions. +1.  I was reading