Re: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share"

[Xiaoyin Liu]

Hi Joe,



My understanding is that we can't get rid of HRR unless we require clients to 
send a key_share for every key exchange group in the supported_groups 
extension. This would be a quite large overhead if the client wants to support 
lots of groups.



Also HRR allows servers to request clients to echo Cookies. See section 4.2.2 
Cookie.



Best,

Xiaoyin



From: Joseph Birr-Pixton
Sent: Tuesday, December 27, 2016 4:44 PM
To: tls@ietf.org
Subject: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share"



Hi folks,

It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't
support it right now. It's *precisely the kind of thing* that vendors
could easily ship broken/missing support for, and they'd get away with
it for years until it causes a interop problem.

The only case where it is used is (4.1.1):

  If there is overlap in the "supported_groups" extension but the client
  did not offer a compatible "key_share" extension, then the server will
  respond with a HelloRetryRequest

We could entirely remove HRR if we slightly strengthen the MTI
language covering kx groups:

- Clients must not only "implement", but actually offer a key share
for NISTP-256 for every ClientHello.

Note: Obviously, this doesn't apply to PSK-only connections where
psk_key_exchange_modes was provided and did not contain psk_dhe_ke.

This need not have any additional computational overhead, because the
client can amortise the key generation over all handshakes where the
server does not select P-256 (hopefully most of them!). In any case,
it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the
wire, but only if the client wasn't going to send a NISTP-256 share
otherwise.

Did I miss something? Are there any other uses of HRR in TLS1.3 which
means we can't get rid of it in this way?

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] WG adoption call: draft-thomson-tls-tls13-vectors

[Xiaoyin Liu]

+1

From: Richard Barnes
Sent: Thursday, December 8, 2016 2:11 PM
To: Eric Rescorla
Cc: 
Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors

+1

On Thu, Dec 8, 2016 at 8:57 AM, Eric Rescorla 
> wrote:
+1

On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner 
> wrote:
All,

There's been some interest on the list and more in Seoul to adopt 
http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ as a TLS WG 
item.  We marked the draft as a "Candidate for WG Adoption" in the datatracker, 
but now it's time to officially do the WG call for adoption.  So, if you would 
like for this draft to become a WG document and you are willing to review 
various versions as it moves through the process, then please let the list know 
by December 21st.  If you are opposed to this being a WG document, please say 
so (and say why).

Cheers,

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

[TLS] What is the meaning of three dots

[Xiaoyin Liu]

Hi,

What is the meaning of three dots (…) in “ClientHello…ServerHello” and 
“ClientHello…Server Finished”, in section 7.1 Key Schedule? It seems this 
syntax is not defined in this document.

[1] https://tlswg.github.io/tls13-spec/#rfc.section.7.1

Thank you!

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

Re: [TLS] supported_versions question

[Xiaoyin Liu]

I think for question 1, it should ignore legacy_version, and select a version 
from supported_versions, because if a client only supports TLS 1.1 and TLS 1.3, 
in order to connect to pre-TLS1.3 server, it has to set legacy_version to TLS 
1.1.



I have no idea about questions 2 or 3.



Best,

Xiaoyin



From: Matt Caswell
Sent: Monday, October 31, 2016 2:44 PM
To: tls@ietf.org
Subject: [TLS] supported_versions question



A few supported_versions questions:

1) What should a server do if supported_versions is received but
ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
ignore legacy_version?

2) What should a server do if supported_versions is received,
ClientHello.legacy_version == TLS1.2, but supported_versions does not
contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
handshake, use the legacy_version, or use use the versions in
supported_versions?

3) If the answer to (2) above is ignore the legacy_version, and just
use the versions in supported_versions, which client_version should be
used in the RSA pre-master secret calculation? The one in
legacy_version, or the highest one in supported_versions? Presumably
it has to be the one in legacy_version, otherwise thing will fail when
the client talks to a server that doesn't understand
supported_versions?

Matt

___
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] How should inability to access key revocation lists impact the TLS handshake?

[Xiaoyin Liu]

But I think the problem is that there is no TLS alert for “revocation status 
inaccessible”.



Best,

Xiaoyin

From: Salz, Rich
Sent: Monday, October 24, 2016 2:15 PM
To: Ryan Carboni; tls@ietf.org
Subject: Re: [TLS] How should inability to access key revocation lists impact 
the TLS handshake?



> How should inability to access key revocation lists impact the TLS handshake, 
> if previous public keys and/or certificate hashes are not cached?

Nobody does revocation on the web, for some almost all encompassing definition 
of nobody.

Instead, OCSP and OCSP stapling.

> I cannot see this in the standard. Considering that all one has to do is DDOS 
> a certificate authority nowadays...

General PKI and key lifecycle issues are, properly, not part of the TLS spec.

/r$
___
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] WG adoption of draft-sandj-tls-iana-registry-updates-01

[Xiaoyin Liu]

+1

Xiaoyin

From: Eric Rescorla
Sent: Saturday, October 22, 2016 11:26 AM
To: Stephen Farrell
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1

This draft just codifies stuff that we had already agreed on but had been 
awkwardly stuffed in TLS 1.3. Having it separate is an improvement.

-Ekr




On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell 
> wrote:

Hi all,

Sean and Joe wrote up this IANA registry draft as per
discussions at WG meetings and on the list. As they've
done the initial work, but are WG chairs, they wanted
me (as responsible AD) to call consensus for it. (They
wrote this up as finding authors for such fairly boring
stuff was hard - thank them for taking one for us all
when you see 'em:-)

Based on the earlier discussions and limited mails on
this draft, I do think there's consensus to adopt this
approach and that the text in the I-D [1] is a good
enough starting point for the WG.

If you think otherwise, please comment to the list in
the next week.

If you've questions about all this from a process-crap
POV, feel free to ask those on or off the list as you
think appropriate;-)

Note that if this is adopted as a WG item, the chairs
might decide to continue as editors or recruit someone
else. In the former case, I'm fine with doing the WGLC
stuff when this is ready (which it nearly is IMO, so
there may or may not be a need for new authors, depends
on what the WG think of the text I'd guess).

Cheers,
S.



[1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01


___
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] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Xiaoyin Liu]

Why does this draft normatively depend on TLS 1.3, even if the cipher suites 
defined in this draft use the old syntax, which TLS 1.3 no longer uses?



Best,

Xiaoyin

From: Sean Turner
Sent: Tuesday, October 18, 2016 9:19 AM
To: Daniel Migault
Cc: tls@ietf.org
Subject: Re: [TLS] early IANA code point assignment request for 
draft-ietf-tls-ecdhe-psk-aead



I think there might be consensus to ask for code points but not early.  This 
draft can’t really proceed any faster than the TLS1.3 and 4492bis drafts.

spt

> On Oct 17, 2016, at 12:03, Daniel Migault  wrote:
>
> Hi,
>
> I am not clear what the consensus is for the following points. Is there any 
> consensus for requesting the following ones?
>
> BR,
> Daniel
>
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};
> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};
>
>
>
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson  
> wrote:
> I'm mainly just looking to economize on different configurations.
>
> On 9 October 2016 at 16:32, John Mattsson  wrote:
> > Hi Martin,
> >
> >
> > AES_256_CCM_8 was not in the first versions of the draft but added later
> > after request from IoT people (probably afraid of quantum computers).
> >
> >
> > While I think it makes very much sense to have short tags in wireless
> > radio, I do not know how large need there is for AES-256 in IoT for
> > constrained devices, or how large the need would be to truncate the tag in
> > these cases.
> >
> >
> > My current understanding is that Grover’s algorithm may never be more
> > cost-effective than a cluster of classical computers, and that quantum
> > computers therefore likely do not affect the lifetime of AES-128.
> >
> >
> > I do not have any strong opinions regarding keeping AES_256_CCM_8 or not.
> > We should not give the impression that AES-256 is needed for practical
> > resistance to quantum computers anytime soon, it is however a requirement
> > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seems
> > like the best choices in most cases.
> >
> >
> > Cheers,
> > John
> >
> >
> >
> > On 12/08/16 08:29, "TLS on behalf of Martin Thomson"  > on behalf of martin.thom...@gmail.com> wrote:
> >
> >>Looking at those emails, I am prompted to wonder if anyone can justify
> >>the existence of a ciphersuite with a double-sized key and half-sized
> >>authentication tag.  RFC 6655 doesn't really explain how that is a
> >>useful thing.
> >>
> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos 
> >>wrote:
> >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
>  All,
> 
>  We've received a request for early IANA assignments for the 6 cipher
>  suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh
>  e-psk-aead/.  Please respond before August 23rd if you have concerns
>  about early code point assignment for these cipher suites.
> >>>
> >>> I have previously raised an issue [0] on these ciphersuites. The same
> >>> requirement was noted also by Peter Dettman as something special in
> >>> [1]. However, there has been no reaction from the authors (now in CC).
> >>>
> >>> regards,
> >>> Nikos
> >>>
> >>> [0].
> >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
> >>> [1].
> >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
> >>>
> >>> ___
> >>> 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
>
> ___
> 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] how close are we?

[Xiaoyin Liu]

Not directly related to Rich's question, but will we settle the "TLS 1.3 -> TLS 
2.0" discussion (PR #612) before 
WGLC? Or has this already been closed as "keeping the current name"?


Best,

Xiaoyin



From: TLS  on behalf of Salz, Rich 
Sent: Tuesday, October 11, 2016 10:23 PM
To: tls@ietf.org
Subject: [TLS] how close are we?


I've been away, and sick, for most of the post three weeks.



How close is this ready to WGLC?  Is it really just polishing the shiny bits?  
I mean I can kinda understand that, but also parts of this seems like 
lsat-midnight late-night hacking.



Looking for some input here.





--

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] Industry Concerns about TLS 1.3

[Xiaoyin Liu]

Andrew,



Then I think your option is to persuade the regulators not to require TLS 1.3 
for internal networks. Also, unlike SSL 3.0 – TLS 1.1, TLS 1.2 is not currently 
known to be weak or insecure, if properly implemented and not using insecure 
cipher suites. So in my opinion, it makes sense to keep using TLS 1.2 
internally.



Best,

Xiaoyin



From: BITS Security
Sent: Monday, September 26, 2016 3:02 PM
To: Peter Bowen
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3



Peter-

Outbound TLS connections require MITM for decryption.  Inbound or internal TLS 
connections can be decrypted with an RSA private key under TLS 1.2.

The PCI DSS is already requiring TLS 1.2 for financial institutions that 
participate in the Payment Card Industry.  .BANK (exclusive top level banking 
domain) is also planning to require TLS 1.2.   We're anticipating that a 
regulatory body like these will require TLS 1.3 at some point in the future.  
Financial institutions then have to comply if they want to continue to do 
business with the companies represented by the regulatory body (like large 
credit card companies in the case of PCI).

-Andrew




-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security 
Cc: Yaron Sheffer ; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security  
wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might 
> expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange versus DH 
for key exchange would only seem to apply when the network tapping system has 
access to the RSA key, right?  So the part of this about monitoring the network 
for external chat and such doesn't really change if the client is using TLS 1.1 
or 1.3, as you still can't decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat under 
control of the monitor, so it can support TLS 1.2 as long as needed.  TLS 1.0 
came out in 1999 and is still now (in 2016) widely deployed.  While I hope TLS 
1.3 deployment is speedy, I don't forsee browsers dropping TLS 1.2 and earlier 
support any time soon.

Thanks,
Peter
___
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] Industry Concerns about TLS 1.3

[Xiaoyin Liu]

Andrew,



I don’t understand why your “choice is being removed”, because you can keep 
using TLS1.2 in your internal network, can’t you?



Best,

Xiaoyin



From: BITS Security
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich; 
nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3



Rich (et al.) -- I understand where you are coming from but I will poke a 
little bit at this portrayal.

We are not here hat-in-hand asking for a return to RSA key exchange to the 
proposed standard.  We do however want to raise our concern (and hopefully your 
awareness) of what appears to be an unintended consequence of the move to 
PFS-only choices.

What is happening from our perspective is choice is being removed and an 
adequate replacement has (seemingly) not been identified.  This lack of choice 
may not affect everyone and every use-case but it will predictably affect 
large, complex, highly regulated enterprises in a serious manner.  This is a 
classic case of security requirement being in conflict with a different 
security requirement.

IETF protocols are run extensively both on the public Internet and within 
private enterprises.  Any decisions made by the TLS Working Group will affect 
both environments, and the needs and requirements of both environments should 
be considered.

-Andrew


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3


> It would be very interesting to get the network diagnostic and operations 
> people (rather than the architects) of the above companies involved in this 
> conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a 
mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is 
not a secret.  It was incumbent on them to reach out and get involved.

> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).

Don't try to equate "listen to each other" with "meet my requirement."  The 
message has been stated, very clearly, from individuals, WG members, through 
document editors and WG chairs and up to Security Directors:  static RSA is not 
coming back to TLS 1.3 .  Since before the last IETF this was the message, 
consistently.  So perhaps you should answer the question first -- why aren't 
*you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to 
prevent PFS in their existing deployment?  Why won't additional controls to 
prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far 
all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to 
TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 
too.

Look, pretty much the entire world is being spied on by national-scale 
adversaries who are recording all traffic for eventual decryption and 
correlation.  *Almost everyone* is having their traffic surveilled. The 
problems of debugging a set of enterprise apps doesn’t amount to a hill of 
beans in that world. It just doesn't. Same for a particular industry's 
regulatory requirements.

> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
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] Should TLS 1.3 servers send "signature_algorithms" extensions

[Xiaoyin Liu]

Thank you for your explanation, Eric!

Xiaoyin

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Monday, September 19, 2016 7:13 PM
To: Xiaoyin Liu <xiaoyi...@outlook.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Should TLS 1.3 servers send "signature_algorithms" extensions



On Mon, Sep 19, 2016 at 3:56 PM, Xiaoyin Liu 
<xiaoyi...@outlook.com<mailto:xiaoyi...@outlook.com>> wrote:
Hello,

There seems to be a conflict in the TLS 1.3 spec on whether servers should send 
“signature_algorithms” extension or not. In section 4.2.2 Signature 
Algorithms<https://tlswg.github.io/tls13-spec/#signature-algorithms>, it says:
Servers which are authenticating via a certificate MUST indicate so by sending 
the client an empty “signature_algorithms” extension.

But in section 8.2 MTI 
Extensions<https://tlswg.github.io/tls13-spec/#mti-extensions>, it says:
Servers MUST NOT send the “signature_algorithms” extension

So should a server send am empty “signature_algorithms” extension or not in 
ServerHello?

Section 8.2 is a bug in the spec. Servers need to send sig_algs if they are 
signing.

David Benjamin has suggested an alternative encoding which I may put in a 
future draft, but for -15, you need to send it.

-Ekr


Thank you!
Xiaoyin

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

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

[TLS] Should TLS 1.3 servers send "signature_algorithms" extensions

[Xiaoyin Liu]

Hello,

There seems to be a conflict in the TLS 1.3 spec on whether servers should send 
"signature_algorithms" extension or not. In section 4.2.2 Signature 
Algorithms, it says:
Servers which are authenticating via a certificate MUST indicate so by sending 
the client an empty "signature_algorithms" extension.

But in section 8.2 MTI 
Extensions, it says:
Servers MUST NOT send the "signature_algorithms" extension

So should a server send am empty "signature_algorithms" extension or not in 
ServerHello?

Thank you!
Xiaoyin
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version negotiation, take two

[Xiaoyin Liu]

I support this proposal.

Xiaoyin

From: David Benjamin
Sent: Thursday, September 8, 2016 12:09 PM
To: tls@ietf.org
Subject: [TLS] Version negotiation, take two

Hi folks,

I'd like to revisit the question of version negotiation.

EKR wrote up some text for moving version negotiation to an extension:
https://github.com/tlswg/tls13-spec/pull/632

I would like us to adopt this proposal.

In Berlin, this really got framed as a pragmatic question: the current version 
negotiation has a lot of intolerance and so let's work around that. So, 
understandably, this seemed like a "let's adopt a hack forever" proposal. I 
think that framing is wrong. The intolerance situation is serious, but I think 
there's also a strong argument that the current scheme isn't very good.

The current scheme is very simple. The client advertises a maximum version and 
the server selects based on that. This is the only piece of TLS negotiation 
which works this way. Elsewhere (extensions, cipher suites, signature 
algorithms), one side offers a list and the other side picks out of it. I think 
it's clear now that strategy is more robust: every time we've bumped version 
numbers, we've had intolerance problems and this time is no exception (see 
below). By contrast, we regularly introduce new cipher suites, extensions, 
etc., and while we do see the occasional failure, they are much rarer and 
typically within the level of breakage that clients can tolerate and deal with 
by reaching out to affected servers. Moreover, lists lend themselves to 
future-proofing via draft-davidben-tls-grease-00 in a way the current scheme 
does not.

An additional benefit is lists make it much easier to roll out prototype/draft 
versions. Currently, we are using a hack where the client offers {3, 4} but 
also includes a draft version number in an extension. This does work, but 
requires servers process that extension in perpetuity or at least until all 
draft version clients go away.  With a list, it's trivial to offer a draft 
version by just including it. This is the strategy HTTP/2 used (via ALPN) and 
it worked well.

Despite all of the above, it probably wouldn't be worth fixing version 
negotiation in 1.3 except for intolerance. Unfortunately, this fourth time, 
it's the same story as before. A probe of Alexa top million sites with 
BoringSSL's TLS 1.3 code (the Go version), shows 1.63% of TLS-capable hosts 
reject a TLS 1.3 ClientHello. Note these are top sites and traffic is 
top-heavy, so we can expect much higher usage-weighted numbers. Qualys SSL 
Pulse reports 3.6%:
https://blog.qualys.com/ssllabs/2016/08/02/tls-version-intolerance-in-ssl-pulse

(Ignore the drop in the graph. We've long fixed the ClientHello record-layer at 
{3, 1}. TLS 1.3 only codified existing practice here.) If instead we use a TLS 
1.3 ClientHello with version TLS 1.2, the breakage drops to 0.017%. (Some of 
this is an NSS signature algorithms bug, fixed last year, which we hope to 
clear by deploying RSA-PSS in browsers early. The rest appears to be noise from 
transient errors which crop up in large tests.)

These numbers are *far* too high for clients to accept as damage, which means 
that they (at least browsers) will be forced to do fallback. This represents a 
security risk (cf. POODLE) as well as hides serious interop problems. The 
situation is even worse for non-browser clients, which may be unable to deploy 
at all (Ubuntu 12.04, despite shipping an OpenSSL release with TLS 1.2, had to 
disable it on the client.
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576/comments/4 )

The major arguments against this change seem to be:

1. It's inelegant to have two mechanisms.
2. We should fix broken servers

The first is true, but as with other changes, EKR's PR replaces the 1.2 
mechanism with one for 1.3, so we'll just have one going forward. The second 
would be nice, but as a practical matter, I spend a lot of time trying to get 
those servers fixed and it doesn't work very well here. Better is simply to 
move to a situation where once those servers upgrade they will be correctly 
behaving forever (instead of just handling 1.3 correctly and breaking with 
1.4). This change does that.

Thanks,

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

Re: [TLS] TLS 1.3 -> TLS 2.0?

[Xiaoyin Liu]

> From: Hubert Kario [mailto:hka...@redhat.com]
> Sent: Wednesday, August 31, 2016 4:48 AM
> To: Xiaoyin Liu <xiaoyi...@outlook.com>
> Cc: tls@ietf.org
> Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?
> 
> On Tuesday, 30 August 2016 22:20:45 CEST Xiaoyin Liu wrote:
> > > -Original Message-
> > > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario
> > > Sent: Tuesday, August 30, 2016 4:14 PM
> > > To: tls@ietf.org
> > > Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?
> > >
> > > On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote:
> > >
> > > > * Keep the version ID as { 3, 4 } (already weird counting;
> > > > changing risks more intolerance)
> > >
> > >
> > > IMNSHO this alone is enough of a reason not to do this
> > >
> > > it's enough explaining to people that SSLv3.3 is really TLSv1.2, now
> > > we'll have
>  SSLv3.4 == TLSv1.3 == TLSv2.0
> >
> >
> > I don't think this is a problem. People will forget "TLS 1.3" and will
> > only remember "TLS 2.0" after some time.
> 
> well, that's not the experience of our support engineers, people still confuse
> SSLv3 with TLSv

It's normal that people confuse SSLv3 with TLS. SSL 3.0 was a released and 
widely deployed protocol, and the term "SSL" is still widely used today to 
refer to TLS. But the situation is much better if we rename TLS 1.3: TLS 1.3 
spec has not been released, it is not supported by any non-testing clients or 
servers, and there are not many documents, papers or blogs mentioning TLS 1.3. 
This is why I said "TLS 1.3" is similar to "Windows 9" in terms of naming.

> if the WG really wants a TLSvX.0 name, the X really should be bigger than 3
> 

Well, I prefer TLS 2.0, because it sounds more natural that major version 2 
comes after major version 1. But TLS {>3}.0 is also fine to me, if the WG 
thinks people may get confused between SSL 2.0 and TLS 2.0.

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

Re: [TLS] TLS 1.3 -> TLS 2.0?

[Xiaoyin Liu]

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario
> Sent: Tuesday, August 30, 2016 4:14 PM
> To: tls@ietf.org
> Subject: Re: [TLS] TLS 1.3 -> TLS 2.0?
> 
> On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote:
> > * Keep the version ID as { 3, 4 } (already weird counting; changing
> > risks more intolerance)
> 
> IMNSHO this alone is enough of a reason not to do this
> 
> it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we'll 
> have
> SSLv3.4 == TLSv1.3 == TLSv2.0

I don't think this is a problem. People will forget "TLS 1.3" and will only 
remember "TLS 2.0" after some time. Just like few people still remember 
"Windows 9" today, even if "Windows 9" had been rumored in the news every day 
before Microsoft officially announced "Windows 10".

Also this spec hasn't reached WGLC, so I don't think it's too late to make a 
change to its name.


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

Re: [TLS] TLS 1.3 -> TLS 2.0?

[Xiaoyin Liu]

I support this change as long as there is no technical change (version ID 
remains 0x0304).



Best,

Xiaoyin

From: Dave Garrett
Sent: Tuesday, August 30, 2016 2:19 PM
To: tls@ietf.org
Subject: [TLS] TLS 1.3 -> TLS 2.0?



I occasionally see people ask why we're calling it TLS 1.3 when so much has 
changed, and I used to simply think that it was too bikesheddy to bother 
changing at this point. However, now that we've redone negotiation, we have new 
TLS 1.3+ only cipher suites. The old are not compatible with the new (new 
codepoints needed for old ciphers) and the new are not backwards compatible 
with the old (they'll just be ignored). We actually risk misconfiguration in 
the future if the distinction isn't made clear. I think it's time we just 
renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a major 
version seems more appropriate.

Note that contrary to what some people seem to think, version numbers are not 
completely without meaning. To someone who doesn't really know/care that much 
what TLS is, making sure to use the latest major version of a security protocol 
carries more weight than a minor version. It also makes it clear that there are 
new features here (e.g. 0-RTT). There's some de facto standardization in 
versioning which does carry some useful information. We're not just dealing 
with programmers here; this stuff needs to be clear for managers and 
non-professionals. If we want to get everyone upgraded eventually, messaging is 
important.

Specific proposed changes:
* Mass rename TLS 1.3 to TLS 2.0 in all places (or TLS 2)
* Keep the version ID as { 3, 4 } (already weird counting; changing risks more 
intolerance)
* Rename the new cipher suites to have a "TLS2_" prefix to be less confusing 
for the registry & end configuration
* Add a sentence noting the development history here, and that all documents 
that refer to TLS 1.3 refer to TLS 2.0 (e.g. HTTP/2)

This is a relatively simple set of changes to make that I think can be 
beneficial in the long run, and is essentially just editorial. Rebranding might 
not be something everyone really wants to bother with, but if we expect this to 
be in use for a decade or more (whether we like it or not), we should probably 
make sure to be as clear as possible at the start.


Dave

___
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] [Technical Errata Reported] RFC4492 (4783)

[Xiaoyin Liu]

Why is the type editorial? According to [1], an editorial errata is "a 
spelling, grammar, punctuation, or syntax error that does not affect the 
technical meaning". Although the mistake in RFC4492 is clearly a typo, I think 
it does affect the technical meaning. So I would prefer to leave the type as 
technical.


[1] https://www.rfc-editor.org/errata-definitions/

Best,

Xiaoyin



From: TLS  on behalf of Sean Turner 
Sent: Tuesday, August 23, 2016 9:19 PM
To: 
Cc: he...@florent-tatard.fr; sean+i...@sn3rd.com; b...@openssl.org; Kathleen 
Moriarty; ch...@corriente.net; nel...@bolyard.com; vipul.gu...@sun.com
Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (4783)

This looks correct, but I'd change the "type" to editorial.  Unless anybody 
disagrees with by next Monday, I'll ask Stephen to accept this.

I've also submitted an issue in the 4492bis github repo to get this fixed in 
the new draft.  I'd submit a PR, but I'm still digging out from being absent 
last week.

spt

> On Aug 19, 2016, at 13:13, RFC Errata System  
> wrote:
>
> The following errata report has been submitted for RFC4492,
> "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security 
> (TLS)".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=4492=4783
>
> --
> Type: Technical
> Reported by: Florent Tatard 
>
> Section: 5.7
>
> Original Text
> -
> Actions of the sender:
>
>   The client selects an ephemeral ECDH public key corresponding to the
>   parameters it received from the server according to the ECKAS-DH1
>   scheme from IEEE 1363 [6].  It conveys this information to the client
>   in the ClientKeyExchange message using the format defined above.
>
> Corrected Text
> --
> Actions of the sender:
>
>   The client selects an ephemeral ECDH public key corresponding to the
>   parameters it received from the server according to the ECKAS-DH1
>   scheme from IEEE 1363 [6].  It conveys this information to the server
>   in the ClientKeyExchange message using the format defined above.
>
> Notes
> -
> The client conveys data to the server, not itself.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC4492 (draft-ietf-tls-ecc-12)
> --
> Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
> Transport Layer Security (TLS)
> Publication Date: May 2006
> Author(s)   : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. 
> Moeller
> Category: INFORMATIONAL
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>

___
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] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Xiaoyin Liu]

> Date: Fri, 3 Jun 2016 11:33:54 +0300
> From: ilariliusva...@welho.com
> To: tls@ietf.org
> Subject: Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, 
> and server time]
> 
> On Fri, Jun 03, 2016 at 08:37:34AM +0200, Nikos Mavrogiannopoulos wrote:
> 
> > A simpler proposal is:
> > Consider TLS 1.3 as a feature, and negotiate it using an empty
> > extension. If the extension is present a server assumes TLS 1.3.
> 
> Well, AFAIK, in current editor's draft, key_share or pre_shared_key
> is always present and none are meaningful in TLS.1.2.
But they cannot be used to distinguish TLS 1.3 with any future versions, if 
these two extensions still exist in TLS 1.4, 1.5, ... .
Best,Xiaoyin
  ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls