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

[Yaron Sheffer]

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 a class of potential attacks. Why are we insisting on not using it?


Thanks,
Yaron

On 20/11/16 17:33, Salz, Rich wrote:

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 saying that contexts are not needed even for TLS?


I think because the key schedule changed.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

> 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 (the latter was
finally published in 2010, and even that is not a problem).

So I can get behind TLS 2017.  I had even considered suggesting it,
but did not at the time want to add more options to the mix.

I think the risk of two TLS standards published in a single year
is vanishingly low.  And see no problems with "gaps" in the numbers.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mark Nottingham]

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.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf.
> 
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to not 
> rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision on 
> the list so please let the list know your top choice between:
> 
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
> 
> by 2 December 2016.
> 
> Thanks,
> J
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
Mark Nottingham   https://www.mnot.net/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Xiaoyin Liu]

+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] 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 the "4 sounds too much like 3" complaint; and
   * it eliminates the "where are TLS 2 and TLS 3?" complaint.

Perhaps it's worth starting a poll specifically between "TLS 1.3" and
"TLS 2017"? Or at least asking whether the new "TLS 2017" option would
swing some previous opinions?

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

---Dan

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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 implementations to not offer it.

I understand Martin Rex's rationale: we are effectively mandating a
requirement on implementations of other versions of the protocol.
However, I agree with ekr.  We have - I think - consensus to forbid
compression more broadly than just in TLS 1.3.  It's a foot gun.

And I don't believe that the foot gun is unique to the web case.  For
example, if you don't believe that mail could contain
attacker-controlled data and secrets, then you haven't thought hard
enough about all the ways mail can be used.  Similarly, insert
protocol of choice.  Of course it's definitely true that someone
loaded and cocked the footgun for the web.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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 zero, which
> corresponds to the “null” compression method in prior versions of TLS. If a
> TLS 1.3 ClientHello is received with any other value in this field, the
> server MUST abort the handshake with an “illegal_parameter”  alert. Note
> that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which
> contain other compression methods and MUST follow the procedures for the
> appropriate prior version of TLS."
> 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 implementations to not offer it.


It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST
> NOT.
> One reason for that is that it is not broken the way that say 56-bit
> encryption is.
>

The IETF has already decided this issue:
https://tools.ietf.org/rfcmarkup?doc=7465

-Ekr



> From: TLS  on behalf of Joseph Salowey <
> j...@salowey.net>
> Sent: Wednesday, October 26, 2016 7:56 PM
> To: tls@ietf.org
> Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
>
>
> This is a working group last call announcement
> for draft-ietf-tls-tls13-18, to run through November  20. If possible,
> we would like to receive comments on the list by November 13 so  they
> can be discussed at the meeting in Seoul. We hope to address
> any substantive issues raised during that process shortly thereafter.
>
>
> In order to allow for cryptographic review, we will delay submission of
> the draft to the IESG until the end of January 2017; there will be an
> opportunity to address  any issues discovered by the cryptographic
> community prior to submission to the IESG.
>
>
> Cheers,
>
>
> Joe
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bill Frantz]

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 additional advantage of making the age obvious;
* it eliminates the "4 sounds too much like 3" complaint; and
* it eliminates the "where are TLS 2 and TLS 3?" complaint.

Perhaps it's worth starting a poll specifically between "TLS 1.3" and
"TLS 2017"? Or at least asking whether the new "TLS 2017" option would
swing some previous opinions?

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


The Ecmascript standards body, TC39 has moved to year === 
version. It seems to work well for them.


I don't think that using a year means that there will be a new 
standard every year.


In the unlikely event that there is a standard bug bad enough to 
need a second standard in one year, decimal version(s) could be 
used e.g 2017.1.  It would be understandable and act as 
punishment for us who screwed up.


Cheers - Bill

---
Bill Frantz| Concurrency is hard. 12 out  | Periwinkle
(408)356-8506  | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |- Jeff Frantz | Los Gatos, 
CA 95032


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Mill]

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 have the following conversation, with the exact
> same people the proponents of 4 are trying to help:
>
> "You only support 1.2, you should support 4"
> "Oh, wasn't it that weird other way around where the high one was
> broken?"
> "Ah, no, 4 is the latest and greatest"
> "Oh, ok, then I should support only 4 and 3?"
> "Nono, 3 is terribly broken."
> "Oh, so only 4? Do all clients support it?"
> "Uh, you should keep 1.2"
> "Ah, so 1.2 is better than 3 but worse than 4?"
> "Yeah... I'm sorry"
>
> "4 is great, 3 is bad, 1.2 is good" is harder than "3 is bad, 1.2 is
> good" was, and harder than "3 is bad, 1.2 is good, 1.3 is great" would
> be.
>

While this conversation might not be impossible, I think it's an unlikely
hypothetical. A change to TLS 4 wouldn't be to address confusion for those
who have already internalized the weird version history (which is mostly
people like us on-list), but for people who only think about TLS/SSL when
they're forced to think about it, once every year or few.

For those people, the real conversations I've had were based on superficial
glances and hazy memories of the protocol history that are reconstituted
every time the subject comes up. Naming it TLS 4 wouldn't fix it for
everyone, but it would be all-upside for some -- as well as providing a
helpful opportunity to drop the faux-minor version number and simplify the
numbering overall in the long term.

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.

-- Eric


>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
konklone.com | @konklone 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yuhong Bao]

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 in prior versions of TLS. If a TLS 1.3 ClientHello is 
received with any other value in this field, the server MUST abort the 
handshake with an “illegal_parameter”  alert. Note that TLS 1.3 servers might 
receive TLS 1.2 or prior ClientHellos which contain other compression methods 
and MUST follow the procedures for the appropriate prior version of TLS."
IMO, the compression methods section of ClientHello should be ignored as 
mentioned by Martin Rex.

It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST NOT.
One reason for that is that it is not broken the way that say 56-bit encryption 
is.

From: TLS  on behalf of Joseph Salowey 
Sent: Wednesday, October 26, 2016 7:56 PM
To: tls@ietf.org
Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
  

This is a working group last call announcement for draft-ietf-tls-tls13-18, to 
run through November  20. If possible, we would like to receive comments on the 
list by November 13 so  they can be discussed at the meeting in Seoul. We hope 
to address any substantive issues raised during that process shortly thereafter.


In order to allow for cryptographic review, we will delay submission of the 
draft to the IESG until the end of January 2017; there will be an opportunity 
to address  any issues discovered by the cryptographic community prior to 
submission to the IESG.


Cheers,


Joe

 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[D. J. Bernstein]

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 the "4 sounds too much like 3" complaint; and
   * it eliminates the "where are TLS 2 and TLS 3?" complaint.

Perhaps it's worth starting a poll specifically between "TLS 1.3" and
"TLS 2017"? Or at least asking whether the new "TLS 2017" option would
swing some previous opinions?

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

---Dan

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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 saying that contexts are not needed even for TLS?

I think because the key schedule changed.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yaron Sheffer]

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?


Thanks,
Yaron

On 20/11/16 13:21, Salz, Rich wrote:

In CURDLE this week, we had consensus (to be confirmed on the list, of course) 
that
Signature contexts were created in the TLS arena, we all thought we 
needed them in other areas, and we don't, therefore all CURDLE documents for 
those other areas will specify a zero-length context.

FWIW.

I agree with Yoav's message, for the reasons he states.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz



-Original Message-
From: Sean Turner [mailto:s...@sn3rd.com]
Sent: Friday, November 18, 2016 6:56 PM
To: 
Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis

All,

This is a working group last call for the “4492bis to Standards Track" draft
available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/.  Please
review the document and send your comments to the list by 9 December
2016.

Note that we are particularly interesting in the issue Yoav raises in the
following message:
https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk

Thanks,
J
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

(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 3GPP
already next year mandates support of both TLS 1.3 and DTLS 1.3 in all the
places they use (D)TLS.

Cheers,
John


- I cannot find any text describing the requirements TLS 1.3 put on the
  lower layers. In fact the only text I can find is "which might be hidden
  by TCP". I don't know if the draft should mandate TCP or not, but
  otherwise it should be stated that reliable, in-order transport is
  required, and that the lower layers must allow identification TLS
  messages in the same session (e.g. the 5-tuple when TCP is used).

- I cannot find any text describing that TLS 1.3 outputs a stream identical
  to the inputstream. The current text only states that the input on the
  sender side is application messages. Should state that the TLS is
  reliable and in-order.

- The are no requirements on the TLS API. I think the following should be
  added:
  - SHALL support an exporter API
  - SHALL support an API allowing application to get information regarding
the negotiated connection.
  - SHOULD support an API allowing application to influence the connection
to be negotiated.

- TLS 1.3 also updates RFC5246, but I don't know if you can both update and
  obsolete. If you have to choose, obsolete is better.

- Section 1: This is the only place channel is used in the meaning
  connection. I suggest "channel" -> "connection" as connection is used in
  the rest of the document.

- Section 1: "The TLS standard, however, does not specify ... how to
  interpret the authentication certificates"

  I don't this is really true any more, the draft has significant text on
  certificates. I suggest removing "how to interpret the authentication
  certificates exchanged"

- Figure 1, 4: "pre_shared_key_modes" -> "psk_key_exchange_modes"

- Figure 1. "Server Params" not horizontally aligned with "Key Exch" and
  "Auth" (not sure if this is a feature or a bug).

- Section 2: 
  "CertificateVerify:  a signature over the entire handshake "
  "Finished :  a MAC over the entire handshake "

  Not really true. Maybe add something like "to this point"

- Section 2: The text below Figure 1 should mention psk_key_exchange_modes.
  It talks about all other messages and extensions.

- Section 2.2: OLD "PSKs can be used with (EC)DHE exchange"
   NEW "PSKs SHOULD be used with (EC)DHE exchange"

- Section 2.3: 
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
  be used with the PSK MUST also be provisioned."

  OLD "and the KDF to be used"
  NEW "and the Hash algorithm to be used"
  
  I think this is a little problematic as current PSK provisioning
  mechanisms do not provision a hash algorithm. This means that they need
  to be updated before TLS 1.3 can be used. Otherwise the risk is that one
  endpoint uses SHA-256 and the other SHA-384. To enable PSK systems to
  directly and easily upgrade to TLS 1.3 I suggest the following

  OLD
  "When PSKs are provisioned out of band, the PSK identity and the KDF to
  be used with the PSK MUST also be provisioned."

  NEW
  "When PSKs are provisioned out of band, the PSK identity MUST also be
  provisioned and the Hash algorithm to be used SHOULD be provisioned. If
  no hash algorithm has been provisioned, then SHA-256 SHALL be used."
  
  This would also affect 4.2.6.

- Section 2.3: "the following additional information MUST be provisioned to
  both parties:

   -  The Application-Layer Protocol Negotiation (ALPN) protocol, if any
  is to be used

   -  The Server Name Indication (SNI), if any is to be used"

  I think these two bullets apply to ALL uses of TLS. Or? I suggest moving
  to a general section.

- Section 2.3: "1.  This data is not forward secret, as it is encrypted
  solely under keys derived using the offered PSK."

  This is true for all uses of PSK without (EC)DHE and not only Zero-RTT. I
  suggest moving this text to another more general section. Maybe in
  Section 2 when the three basic key exchange modes are discussed.

- Section 2.3: Zero-RTT with PSK obtained out-of-band is a special case of
  Zero-RTT, with its own requirements and warnings. I think it should be
  moved to its own subsubsection (2.3.1).

- Section 3.5: "enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;"
  The variable 'n' is used for two different purposes. Use n, m or
  something.

- Section 3.8: Same thing here. The variable 'n' is used for two different
  purposes.

- Section 4.0 The cases in Handshake definition in some random order.
  Should keep the same order as the HandshakeType definition.

- Section 4.1.2 "Including a "cookie" extension if one was provided in the
  HelloRetryRequest."
  Could state that this is the HelloRetryRequest cookie echoed 

[TLS] Re-use and export of DH shares

[Yoav Nir]

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

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls