Our telemetry shows that there are tons of machines (including recently
manufactured tablets) without persistent clocks (i.e. no battery powering the
system clock). Such machines indeed boot with date/time in the past millennium;
they cannot hard-fail on OCSP errors (which greatly reduces the va
Hi Dave,
Dave Garrett wrote:
>
> enum {
>handshake_failure(40),
>unsupported_cipher_suites(71), /* formerly insufficient_security */
>unsupported_dh_groups(72), /* new */
>client_authentication_failure(73), /* new */
>(255)
>} AlertDescription;
>
On Wednesday 22 July 2015 16:10:27 Dave Garrett wrote:
> Consensus was my current WIP proposal is not viable, for some of the
> following main reasons:
>
> 1) cost/benefit analysis doesn't seem to be worth it
> 2) backwards compatibility handling
> 3) some argue harder to implement; others argue e
On Wednesday 22 July 2015 19:55:58 Blake Matheny wrote:
> One of the topics of discussion at the WG discussion was whether
> ServerConfiguration.expiration_date should be an absolute or relative
> value. Subodh (CC) dug into our production data and found that nearly half
> of the TLS errors we see
On Wed, Jul 22, 2015 at 04:10:27PM -0400, Dave Garrett wrote:
> Consensus was my current WIP proposal is not viable, for some of the
> following main reasons:
>
> 1) cost/benefit analysis doesn't seem to be worth it
> 2) backwards compatibility handling
> 3) some argue harder to implement; others
On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
> Dave Garrett wrote:
> >
> > enum {
> >handshake_failure(40),
> >unsupported_cipher_suites(71), /* formerly insufficient_security */
> >unsupported_dh_groups(72), /* new */
> >client_authentication_fail
On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> vast swaths of web servers are misconfigured; introducing a more complex
> mechanism to server configuration when the existing situation is
> incomprehensible to many administrators won't help (and even many people that
> write the var
On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> Right now, the restrictions section prohibits:
> RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available
So much for using NULL ciphers for client-server authentication
On Thursday, July 23, 2015 12:00:34 pm Viktor Dukhovni wrote:
> On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> > Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0,
> > or abort with a fatal error.
>
> Who's going to police the Internet to remove all the legac
On 23/07/15 16:43, Dave Garrett wrote:
> We should just get more serious about banning old crap entirely to
> make dangerous misconfiguration impossible for TLS 1.3+
> implementations.
>
> Right now, the restrictions section prohibits: RC4, SSL2/3, &
> EXPORT/NULL entirely (via min bits) and has
It is Windows Server 2003 SMTP service that has this problem.
There is a hotfix for it.
I had been asking for these fixes to be pushed out and the KB article corrected
before Windows Server 2003 ended support.
> Date: Thu, 23 Jul 2015 16:00:34 +
> From: ietf-d...@dukhovni.org
> To: tls@iet
On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
wrote:
>
>
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restrictions section
On Thursday 23 July 2015 18:06:04 Stephen Farrell wrote:
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restrictions section proh
On Thursday 23 July 2015 11:43:45 Dave Garrett wrote:
> On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> > vast swaths of web servers are misconfigured; introducing a more complex
> > mechanism to server configuration when the existing situation is
> > incomprehensible to many administr
Our data suggests that during successful handshakes the clock skew of mobile
devices is within a few hours, and is within years for unsuccessful cases.
Having relative time thus is definitely better from the client's perspective.
With this however, there is a tradeoff on the server. The expiry
On Wed, Jul 22, 2015 at 9:39 PM, Dave Garrett wrote:
> Hubert Kairo found quite a few more spots in need of explicit error
> designations, which have been amended into PR #201.
> https://github.com/tlswg/tls13-spec/pull/201
>
> I just noticed one error in the current draft text that was wrong and
On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote:
> On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> wrote:
> > A suggestion - could we remove mention of anything that
> > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > and then have someone write a separate draft that
On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
> I mean I kinda agree that 'insufficent security' is a misleading name,
> but as it has been used for decades in TLS I'm a bit hesitant if it's a
> good idea to change the name now.
Alternate bikesheddy response: what about renaming it to
Dave Garrett wrote:
> On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
>> I mean I kinda agree that 'insufficent security' is a misleading name,
>> but as it has been used for decades in TLS I'm a bit hesitant if it's a
>> good idea to change the name now.
>
> Alternate bikesheddy resp
On Thursday, July 23, 2015 03:31:06 pm Aaron Zauner wrote:
> Fine with that. Now that I think about it again; I'm also fine with the
> original proposal. The thing is 'insufficient security' has a nicer ring
> to it than 'unsupported XYZ'.
It's wrong, though. If a server rejects a client connectio
Dave Garrett wrote:>
> It's wrong, though. If a server rejects a client connection because the
> server only supports RC4 and the client doesn't, the correct error for the
> server to return is "insufficient_security". If you invert the meaning, I
> guess the server has insufficient security,
It's not clear to me that there is consensus that more granular error
codes are a good idea. I'll defer to the chairs on the process question.
-Ekr
On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett
wrote:
> Hubert Kairo found quite a few more spots in need of explicit error
> designations, which h
Rather than renaming and otherwise modifying the meaning of the existing
alerts, would it be better to define new, more granular alerts in 1.3? We can’t
ascribe new meanings to alerts generated by the code we’ve shipped in the past.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Resco
Thanks for the detailed comments, Ilari.
Based on the discussion at the TLS WG meeting, I created a pull request:
https://github.com/tlswg/tls13-spec/pull/209
> - Mechanism like proposed looks dangerous when combined with HTTP/2.
I believe the same issue already exists in HTTP/1 where multiple r
On Thursday, July 23, 2015 10:52:59 pm Andrei Popov wrote:
> Rather than renaming and otherwise modifying the meaning of the existing
> alerts, would it be better to define new, more granular alerts in 1.3? We
> can’t ascribe new meanings to alerts generated by the code we’ve shipped in
> the pa
> I'm proposing renaming "insufficient_security" to
> "unsupported_cipher_suites", which is explicitly what it's been for since TLS
> 1.0.
Not quite. Insufficient_security alert is defined as follows:
" Returned instead of handshake_failure when a negotiation has
failed specifically because t
On Fri, Jul 24, 2015 at 05:01:37AM +, Andrei Popov wrote:
>
> > - The certificate_types field in CertificateRequest is pretty much
> > useless, since all supported algorithms are of signature type.
> If the signature_algorithms extension officially becomes MTI, then
> perhaps we can discus ge
On Thu, Jul 23, 2015 at 06:06:04PM +0100, Stephen Farrell wrote:
>
>
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restriction
Sound good to me; if the group agrees to remove certificate_types, I'll make
this change in the PR.
-Original Message-
From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi]
Sent: Friday, July 24, 2015 8:33 AM
To: Andrei Popov
Cc: tls@ietf.org
Subject: Re: [TLS] Commentary on the cli
29 matches
Mail list logo
