Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

[Kyle Rose]

To be honest, the purist in me likes the general idea here, though I think
I prefer "kex" as I'm used to that with SSH.

Then again, that isn't even quite correct, as the most popular mechanism is
DH, which is key agreement based on the exchange of inputs to a formula: no
keys are actually exchanged.

I fear we're bike shedding with this proposal. Across all of computing,
there are plenty of mechanisms that appear to be misnamed for the same
reason: unforeseen but reasonable extension beyond their
originally-intended applications.

The actual name in TLS is "10", so as long as we all agree on that and
understand the history behind "supported_groups", I'm not sure it matters.

Kyle

On Sep 13, 2016 2:27 PM, "William Whyte" 
wrote:

I'd like to just check and see if there are any objections to this PR.
There seems no reason to bake a particular cryptographic family into our
terminology. This is a low-cost change that will save us from looking silly
in a few years time.

Cheers,

William

On Tue, Sep 13, 2016 at 1:19 PM, Sean Turner  wrote:

> There appears to be no consensus to adopt the change proposed by this PR.
>
> The small condolence here is that the name+semantics for this extension
> has been changed once before and if the extension really needs to be
> renamed in 5-7 years we’ve got precedence for doing so.
>
> spt
>
> > On Aug 29, 2016, at 15:52, Zhenfei Zhang 
> wrote:
> >
> > Hi list,
> >
> >
> >
> > I have created a pull request
> >
> > https://github.com/tlswg/tls13-spec/pull/604
> >
> >
> >
> > I would like to suggest that we change the terminology "NamedGroup" to
> "KeyExchangeMethod".
> >
> >
> >
> > In [1], it is suggested that we redefine the syntax, which leads to the
> separation of public key crypto
> >
> > and symmetric crypto during a handshake. Because of this separation, new
> terminology was defined
> >
> > for key exchange algorithms and authentication algorithms for public key
> crypto in the key exchange
> >
> > extension. "NamedGroup" was used to refer the underlying key exchange
> parameters, which comes
> >
> > from the "Supported Elliptic Curves" in previous versions.
> >
> >
> >
> > The use of "NamedGroup" implicitly requests the key exchange algorithm
> to be Deffie-Hellman type.
> >
> > While it is safe for now, it would be nice to have some crypto agility,
> and future proof. It would make
> >
> > the transition to other key exchange primitives (such as lattice based
> key exchange) or methods
> >
> > (such as key encapsulation mechanism) easier in the future, if we do not
> restrict the key exchange
> >
> > by certain "Group".
> >
> >
> >
> > Knowing that NIST has planned to standardize quantum-safe cryptography
> within 7 years of time
> >
> > (which can and should be accelerated), and those algorithms cannot be
> described in terms of "group",
> >
> > the current terminology will due for a redesign by then. So I would
> suggest to change the
> >
> > "NamedGroup" now rather than later.
> >
> >
> >
> >
> > Overall, this will have the following impact
> >
> >
> >
> > 1. HelloRetryRequest
> >
> >
> >
> > Change HelloRetryRequest structure to
> >
> >
> >
> > struct {
> >
> > ProtocolVersion server_version;
> >
> > KeyExchangeMethod selected_kem;
> >
> > Extension extensions<0..2^16-1>;
> >
> > } HelloRetryRequest;
> >
> >
> >
> > 2. Negotiated Groups
> >
> >
> >
> > Throughout, change "supported_groups" to "supported_kems"; change
> "NamedGroupList" to
> > "KeyExchangeMethodList"; change "named_group_list" to "kem_list"; change
> NamedGroup to
> >
> > KeyExchangeMethod
> >
> >
> >
> > 3. Key Share:
> >
> > Change KeyShareEntry structure to
> >
> >
> >
> > struct {
> >
> > KeyExchangeMethod kem;
> >
> > opaque key_exchange<1..2^16-1>;
> >
> > } KeyShareEntry;
> >
> >
> > [1] https://github.com/ekr/tls13-spec/blob/15126cf5a08c445aeed97
> c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md
> >
> >
> >
> > Thanks for your time.
> >
> >
> >
> > Zhenfei Zhang
> >
> > ___
> > 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] Finished stuffing

[Ilari Liusvaara]

On Tue, Sep 13, 2016 at 12:04:40PM -0500, Benjamin Kaduk wrote:
> 
> 
> On 09/09/2016 03:19 PM, Ilari Liusvaara wrote:
> > On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
> 
> >> I have a slight (i.e., unjustified) preference for doing
> >> ClientHello-with-block-of-zeros rather than prefix-of-ClientHello.  (Is
> >> there a reason to require this extension to be the last one with
> >> block-of-zeros?  Clearly there is for prefix-of-ClientHello.)
> > What about the case where client tries DHE-PSK and gets attempt
> > rejected because of missing group (or because address verification)?
> > 0-RTT is gone yes, but the PSK attempt isn't.
> >
> > What happens to the hash in this case?
> >
> >
> 
> I feel like I must be missing something, but I don't really understand
> the question.  (Sadly, waiting in the hope that someone else did
> understand and would respond didn't work.)  The 0-RTT failed, so the
> full handshake will have an actual Finished message, with a different
> hash calculated (including over the "hello_finished" extension).  The
> most plausible way I could interpret the question seems to be asking
> about the lack of Hash(resumption_context) in the 1-RTT Finished, but
> the security properties of that should be the same as for the
> hello_finished, so I'm still puzzled.
> 
> Sorry for being dense...

I mean the following case (perhaps bit misconfigured server):

Client: 
ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,...,finished=zot)
Server: HelloRetryRequest(group=24)
Client: 
ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,24:quux,...,finished=???)


What is the finished data calculated over in the second case?


-Ilari

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

Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

[William Whyte]

I'd like to just check and see if there are any objections to this PR.
There seems no reason to bake a particular cryptographic family into our
terminology. This is a low-cost change that will save us from looking silly
in a few years time.

Cheers,

William

On Tue, Sep 13, 2016 at 1:19 PM, Sean Turner  wrote:

> There appears to be no consensus to adopt the change proposed by this PR.
>
> The small condolence here is that the name+semantics for this extension
> has been changed once before and if the extension really needs to be
> renamed in 5-7 years we’ve got precedence for doing so.
>
> spt
>
> > On Aug 29, 2016, at 15:52, Zhenfei Zhang 
> wrote:
> >
> > Hi list,
> >
> >
> >
> > I have created a pull request
> >
> > https://github.com/tlswg/tls13-spec/pull/604
> >
> >
> >
> > I would like to suggest that we change the terminology "NamedGroup" to
> "KeyExchangeMethod".
> >
> >
> >
> > In [1], it is suggested that we redefine the syntax, which leads to the
> separation of public key crypto
> >
> > and symmetric crypto during a handshake. Because of this separation, new
> terminology was defined
> >
> > for key exchange algorithms and authentication algorithms for public key
> crypto in the key exchange
> >
> > extension. "NamedGroup" was used to refer the underlying key exchange
> parameters, which comes
> >
> > from the "Supported Elliptic Curves" in previous versions.
> >
> >
> >
> > The use of "NamedGroup" implicitly requests the key exchange algorithm
> to be Deffie-Hellman type.
> >
> > While it is safe for now, it would be nice to have some crypto agility,
> and future proof. It would make
> >
> > the transition to other key exchange primitives (such as lattice based
> key exchange) or methods
> >
> > (such as key encapsulation mechanism) easier in the future, if we do not
> restrict the key exchange
> >
> > by certain "Group".
> >
> >
> >
> > Knowing that NIST has planned to standardize quantum-safe cryptography
> within 7 years of time
> >
> > (which can and should be accelerated), and those algorithms cannot be
> described in terms of "group",
> >
> > the current terminology will due for a redesign by then. So I would
> suggest to change the
> >
> > "NamedGroup" now rather than later.
> >
> >
> >
> >
> > Overall, this will have the following impact
> >
> >
> >
> > 1. HelloRetryRequest
> >
> >
> >
> > Change HelloRetryRequest structure to
> >
> >
> >
> > struct {
> >
> > ProtocolVersion server_version;
> >
> > KeyExchangeMethod selected_kem;
> >
> > Extension extensions<0..2^16-1>;
> >
> > } HelloRetryRequest;
> >
> >
> >
> > 2. Negotiated Groups
> >
> >
> >
> > Throughout, change "supported_groups" to "supported_kems"; change
> "NamedGroupList" to
> > "KeyExchangeMethodList"; change "named_group_list" to "kem_list"; change
> NamedGroup to
> >
> > KeyExchangeMethod
> >
> >
> >
> > 3. Key Share:
> >
> > Change KeyShareEntry structure to
> >
> >
> >
> > struct {
> >
> > KeyExchangeMethod kem;
> >
> > opaque key_exchange<1..2^16-1>;
> >
> > } KeyShareEntry;
> >
> >
> > [1] https://github.com/ekr/tls13-spec/blob/
> 15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md
> >
> >
> >
> > Thanks for your time.
> >
> >
> >
> > Zhenfei Zhang
> >
> > ___
> > 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] Fwd: New Version Notification for draft-sandj-tls-iana-registry-updates-00.txt

[Benjamin Kaduk]

For the 16-bit fields, do we want to leave first-octet-zero values as IETF 
Consensus and leave 1-254 for Specification Required?

I suspect we'll need to wordsmith the text for the "Recommended" field in the 
cipher suite registry some; Standards-Track may or may not quite match up 
exactly with what we want (though it seems like it would be pretty good), but I 
would maybe say "for cipher suites marked 'No', it is possible that the 
cryptographic properties are not reviewed, and they may be bad or good".

Should the session_ticket extension also be updated to point to this document 
(as was done for the new_session_ticket handshake message type)?

I guess the security considerations should probably mention that making it 
easier for "anyone" to get a codepoint assigned comes with a risk that people 
will assume that having a codepoint means it's secure.  The "Recommended" 
column attempts to address that, and software authors are encouraged to read 
the primary sources to determine the applicability of an entry to their 
software.



Some minor notes on snippets of the document follow.

The markdown-to-html conversion seems to have left long lines in sections 10 
and 12; maybe there are some syntax errors around there?
(Also, "however the value is computed different" should be "differently".)

   o  Change the IANA registry policy [RFC5226 
] for the TLS
  ExtensionType Values, TLS Cipher Suite, and TLS
  ClientCertificateType Identifiers registries.  These more relaxes
  rules are more condusive to TBD.

"relaxed".  Huh, and thunderbird is also suggesting "conducive", that I missed.

The TBD seems to be "experimentation and test deployment of draft 
specifications".


   o  Add the designated expert intructions as a note to the TLS
  ExtensionType Values, TLS Cipher Suite, and TLS
  ClientCertificateType Identifiers registries to inform IANA-
  registry-focused, non-RFC-reading what's expected from the
  registry.

"instructions"

The "non-RFC-reading" compound adjective doesn't have an associated
noun.  "Readers" could work, but since "reading" is right there, maybe
"viewers" is better.


   This document proposes no changes to the TLS Alert
   [I-D.ietf-tls-tls13
],
 TLS ContentType [I-D.ietf-tls-tls13
],
 TLS
   HandshakeType, [I-D.ietf-tls-tls13
]
 and TLS Certificate Status Types
   [RFC6961 ]; Standards Action, for the 
1st three, and IETF Review, for
   the last, are appropriate for these one-byte code points because of
   their scarcity.

I think "registries" is missing after the list.


In "The following extensions are only applicable to D/TLS protocol
vesions prior to 1.3: truncated_hmac, srp, encrypt_then_mac,
extended_master_secret, session_ticket, and renegotiation_info are not
applicable to TLS 1.3." (another long line), the "only applicable [...]
prior to 1.3" and "are not applicable to TLS 1.3" are redundant.  Also,
"versions" with an 'r'.

-Ben

On 09/07/2016 01:57 PM, Sean Turner wrote:
> Here is a draft that proposes changes to a number of TLS-related registries, 
> e.g., adding notes to indicate orphaned extensions and registries, adding the 
> missing no_application_protocol alert.  The motivation for this draft was to 
> not have everything that needs to be fixed be done in the TLS1.3 draft.  
> We’re positive it needs review.
>
> A repo for the draft can be found at:
> https://github.com/seanturner/draft-sandj-tls-iana-registry-updates
> PRs welcome.
>
> spt
>
>> Begin forwarded message:
>>
>> From: internet-dra...@ietf.org
>> Subject: New Version Notification for 
>> draft-sandj-tls-iana-registry-updates-00.txt
>> Date: September 07, 2016 at 14:10:25 EDT
>> To: "Joe Salowey" , "Sean Turner" , 
>> , "Joseph A. Salowey" 
>>
>>
>> A new version of I-D, draft-sandj-tls-iana-registry-updates-00.txt
>> has been successfully submitted by Sean Turner and posted to the
>> IETF repository.
>>
>> Name:draft-sandj-tls-iana-registry-updates
>> Revision:00
>> Title:   D/TLS IANA Registry Updates
>> Document date:   2016-09-07
>> Group:   Individual Submission
>> Pages:   8
>> URL:
>> https://www.ietf.org/internet-drafts/draft-sandj-tls-iana-registry-updates-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-sandj-tls-iana-registry-updates/
>> Htmlized:   
>> https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-00
>>
>>
>> Abstract:
>>   This document changes the IANA registry policy for a number of D/TLS-
>>   related registries, renames 

Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

[Sean Turner]

There appears to be no consensus to adopt the change proposed by this PR.

The small condolence here is that the name+semantics for this extension has 
been changed once before and if the extension really needs to be renamed in 5-7 
years we’ve got precedence for doing so.

spt

> On Aug 29, 2016, at 15:52, Zhenfei Zhang  
> wrote:
> 
> Hi list,
> 
> 
> 
> I have created a pull request
> 
> https://github.com/tlswg/tls13-spec/pull/604
> 
> 
> 
> I would like to suggest that we change the terminology "NamedGroup" to 
> "KeyExchangeMethod".
> 
> 
> 
> In [1], it is suggested that we redefine the syntax, which leads to the 
> separation of public key crypto 
> 
> and symmetric crypto during a handshake. Because of this separation, new 
> terminology was defined
> 
> for key exchange algorithms and authentication algorithms for public key 
> crypto in the key exchange 
> 
> extension. "NamedGroup" was used to refer the underlying key exchange 
> parameters, which comes 
> 
> from the "Supported Elliptic Curves" in previous versions.
> 
> 
> 
> The use of "NamedGroup" implicitly requests the key exchange algorithm to be 
> Deffie-Hellman type. 
> 
> While it is safe for now, it would be nice to have some crypto agility, and 
> future proof. It would make 
> 
> the transition to other key exchange primitives (such as lattice based key 
> exchange) or methods 
> 
> (such as key encapsulation mechanism) easier in the future, if we do not 
> restrict the key exchange
> 
> by certain "Group".
> 
> 
> 
> Knowing that NIST has planned to standardize quantum-safe cryptography within 
> 7 years of time 
> 
> (which can and should be accelerated), and those algorithms cannot be 
> described in terms of "group",
> 
> the current terminology will due for a redesign by then. So I would suggest 
> to change the 
> 
> "NamedGroup" now rather than later.
> 
> 
> 
> 
> Overall, this will have the following impact
> 
> 
> 
> 1. HelloRetryRequest
> 
> 
> 
> Change HelloRetryRequest structure to
> 
> 
> 
> struct {
> 
> ProtocolVersion server_version;
> 
> KeyExchangeMethod selected_kem;
> 
> Extension extensions<0..2^16-1>;
> 
> } HelloRetryRequest;
> 
> 
> 
> 2. Negotiated Groups
> 
> 
> 
> Throughout, change "supported_groups" to "supported_kems"; change 
> "NamedGroupList" to 
> "KeyExchangeMethodList"; change "named_group_list" to "kem_list"; change 
> NamedGroup to
> 
> KeyExchangeMethod
> 
> 
> 
> 3. Key Share:
> 
> Change KeyShareEntry structure to
> 
> 
> 
> struct {
> 
> KeyExchangeMethod kem;
> 
> opaque key_exchange<1..2^16-1>;
> 
> } KeyShareEntry;
> 
> 
> [1] 
> https://github.com/ekr/tls13-spec/blob/15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md
> 
> 
> 
> Thanks for your time.
> 
> 
> 
> Zhenfei Zhang
> 
> ___
> 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] Version negotiation, take two

[Sean Turner]

All,

There appears to be an emerging consensus here to adopt the change proposed by 
this PR.  Please indicate whether you are unwilling (and why) to accept this 
change by September 16th.

J

> On Sep 08, 2016, at 12:04, David Benjamin  wrote:
> 
> 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

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

Re: [TLS] Finished stuffing

[Benjamin Kaduk]

On 09/09/2016 03:19 PM, Ilari Liusvaara wrote:
> On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
>> I made a few notes on the pull request.  Generally, I support the
>> change, but I get the sense that it may aid the cryptographic properties
>> if we keep the resumption_context and do not overload the resumption_psk
>> as much.
> One problem with this is that authentication_methods can include
> nontrivial methods even for "static" PSKs, and if server takes such
> method, you have an attack unless you bind the PSK secret used. And
> "static" PSKs don't have resumption_context.

Agreed.

>  
> And I would expect that someone will be crazy enough to try to
> provision "static" PSK with the information required to perform
> 0-RTT (ALPN (or indication there is none) and associated cipher)...

Wasn't Hannes just asking about that? ;)

>> I have a slight (i.e., unjustified) preference for doing
>> ClientHello-with-block-of-zeros rather than prefix-of-ClientHello.  (Is
>> there a reason to require this extension to be the last one with
>> block-of-zeros?  Clearly there is for prefix-of-ClientHello.)
> What about the case where client tries DHE-PSK and gets attempt
> rejected because of missing group (or because address verification)?
> 0-RTT is gone yes, but the PSK attempt isn't.
>
> What happens to the hash in this case?
>
>

I feel like I must be missing something, but I don't really understand
the question.  (Sadly, waiting in the hope that someone else did
understand and would respond didn't work.)  The 0-RTT failed, so the
full handshake will have an actual Finished message, with a different
hash calculated (including over the "hello_finished" extension).  The
most plausible way I could interpret the question seems to be asking
about the lack of Hash(resumption_context) in the 1-RTT Finished, but
the security properties of that should be the same as for the
hello_finished, so I'm still puzzled.

Sorry for being dense...

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

Re: [TLS] Version negotiation, take two

[Kyle Rose]

On Thu, Sep 8, 2016 at 12:04 PM, David Benjamin 
wrote:

> The major arguments against this change seem to be:
>
> 1. It’s inelegant to have two mechanisms.
> 2. We should fix broken servers
>

There's also:

3. Implementors will find a way to screw this up, too.

But if you follow through with your plan to have Chrome randomly add a
really high version to the list to smoke out servers that fail when they
see unsupported versions, it's plausible version intolerance could be in
the noise next time around.

If you time-limit that behavior for a particular version of Chrome (say, to
a few months), you could even have it randomly add the next version or
current version + 2 to the list to detect and report on selective
next-version intolerance. I'd say this kind of failure mode is unlikely,
but... Murphy's Law.

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

Re: [TLS] Version negotiation, take two

[Benjamin Kaduk]

This is the best proposal I've seen given the deployment constraints
imposed by reality.  Perhaps it could be tweaked to improve it slightly,
but I support merging this version.

-Ben

On 09/08/2016 11:04 AM, David Benjamin wrote:
> 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 

Re: [TLS] Oracle's plans for Java crypto (mostly TLS-related)

[Peter Gutmann]

Salz, Rich  writes:

 >FYI:  https://www.java.com/en/jre-jdk-cryptoroadmap.html   

>From that page:

  2017-01-17 DSA Increase the minimum key length for DSA certificates to 1024 
bits.

Will Oracle also be announcing upcoming support for Windows 95, that
newfangled Linux thing that's just appeared, and 32-bit compilers?

  2017 H2 Diffie-Hellman For SSL/TLS, increase the minimum key length to 1024 
bits.

They missed out:

  2017 For SSL/TLS, discontinue MSDOS and Windows 3.1 support.

(The first, and weakest, PGP key I generated, quarter of a century ago under
DOS, was 1024 bits, same as what Oracle is setting their minimum to next
year some time).

Peter.

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