As many of you probably know, we recently lost Kim Cameron, a giant in the
identity and access space.
This caused me to rethink the reasons for the failure of Identicard, one of
his most promising proposals. Identicard made using public key
authentication easy, just pick the persona you want to au
Ilari Liusvaara wrote:
> Martin Rex wrote:
>> Ilari Liusvaara wrote:
>
>>> Then there's also similar problems with RSA. And then RSA PKCS #1
>>> v1.5 encryption is on just about every "do not use!" list. Get it
>>> wrong (good luck getting it right) and it is game over.
>>
>> Getting PKCS#1 v1.5
On Thu, Jan 14, 2016 at 12:27:07PM +0100, Martin Rex wrote:
> Ilari Liusvaara wrote:
> [ Charset UTF-8 unsupported, converting... ]
Pfft...
> > Then there's also similar problems with RSA. And then RSA PKCS #1
> > v1.5 encryption is on just about every "do not use!" list. Get it
> > wrong (good l
Ilari Liusvaara wrote:
[ Charset UTF-8 unsupported, converting... ]
> On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote:
> > Ilari Liusvaara wrote:
> > >
> > > To actually fix the known problems with TLS 1.2, you would at minimum
> > > need a new extension, since there is currently no way
On Thu, Jan 14, 2016 at 10:40:44AM +0100, Martin Rex wrote:
> Ilari Liusvaara wrote:
> >
> > To actually fix the known problems with TLS 1.2, you would at minimum
> > need a new extension, since there is currently no way to fix the broken
> > server authentication.
>
> One Boolean signaling is suf
Ilari Liusvaara wrote:
>
> Peter Gutmann wrote:
>
>> Salz, Rich writes:
>>
TLS needs an LTS version that you can just push out and leave to its own
devices
>>>
>>>So don't you have that with TLS 1.1 and appropriate cipher and option
>>>choices?
>>
>> Based on the feedback I've had, I'm
On Thu, Jan 14, 2016 at 12:14:48AM +, Peter Gutmann wrote:
> Salz, Rich writes:
>
> >> TLS needs an LTS version that you can just push out and leave to its own
> >> devices
> >
> >So don't you have that with TLS 1.1 and appropriate cipher and option
> >choices?
>
> Based on the feedback I've
Nikos Mavrogiannopoulos writes:
>That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite
>of the code base. Given that the majority of the issues in TLS
>implementations are in the code bases and not in the protocol, it is very
>risky to switch to such a new version just like
Salz, Rich writes:
>> TLS needs an LTS version that you can just push out and leave to its own
>> devices
>
>So don't you have that with TLS 1.1 and appropriate cipher and option
>choices?
That's the approach suggested previously by Peter Bowen, assemble it yourself
from a huge list of extension
Salz, Rich wrote:
>
>> TLS needs an LTS version that you can just push out and leave to its own
>> devices
>
> So don't you have that with TLS 1.1 and appropriate cipher and option choices?
Actually, you already have that with TLSv1.0 plus the known mitigations.
The only cryptographical improve
> TLS needs an LTS version that you can just push out and leave to its own
> devices
So don't you have that with TLS 1.1 and appropriate cipher and option choices?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wednesday 13 January 2016 12:32:05 Peter Gutmann wrote:
> Hubert Kario writes:
> >So lets not repeat those mistakes
>
> Exactly, there are more than enough new ones for 2.0-called-1.3 to
> make that we don't (necessarily) have to repeat existing ones
> (although I'm sure we will in some cases)
Hubert Kario writes:
>So lets not repeat those mistakes
Exactly, there are more than enough new ones for 2.0-called-1.3 to make that
we don't (necessarily) have to repeat existing ones (although I'm sure we will
in some cases).
And that's exactly my point, we're throwing away 20 years of refini
On Wednesday 13 January 2016 15:11:47 Dmitry Belyavsky wrote:
> Hello Hubert,
>
> On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario
wrote:
> > On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote:
> > > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann
> > >
> > > wrote:
> > > > Yoav Nir writes:
>
Hello Hubert,
On Wed, Jan 13, 2016 at 2:52 PM, Hubert Kario wrote:
> On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote:
> > On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann
> >
> > wrote:
> > > Yoav Nir writes:
> > > To expand on this, I'll take Ilari Liusvaara's comments:
> > >>Bleeding edg
On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote:
> On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann
>
> wrote:
> > Yoav Nir writes:
> > To expand on this, I'll take Ilari Liusvaara's comments:
> >>Bleeding edge ideas? They essentially re-invented SIGMA, which is
> >>over 10 years old. The ba
On Tuesday 12 January 2016 15:14:13 Dave Garrett wrote:
> On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote:
> > On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote:
> > > I hope that Google's efforts to get QUIC as-is specced out go
> > > quickly and smoothly, and that it can be
woch, 13. Januar 2016 10:54
To: Yoav Nir; Peter Gutmann
Cc:
Subject: Re: [TLS] Fixing TLS
On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote:
> Hi, Peter
>
> Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or
> 2.0) that this WG is working on right now, why?
> Other
On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote:
> Hi, Peter
>
> Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or
> 2.0) that this WG is working on right now, why?
> Other groups are not working on HTTP/1.2 or IKEv1.1 or any other
> $protocolv$(major-1).$(minor+1).
Note that
On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann
wrote:
> Yoav Nir writes:
>
>>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
>>that this WG is working on right now, why?
>
> Embedded devices and similar systems with long-term requirements. Most of my
> user base is embe
Yoav Nir writes:
>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
>that this WG is working on right now, why?
Embedded devices and similar systems with long-term requirements. Most of my
user base is embedded (or non-embedded equivalents, systems that need to run
in a
On Tue, Jan 12, 2016 at 12:33 PM, Dave Garrett
wrote:
> On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote:
> > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox
> wrote:
> > > I wish that were the plan (to upgrade QUIC crypto and eventually make
> that
> > > the new crypto platform). If I a
On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote:
> On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote:
> > I wish that were the plan (to upgrade QUIC crypto and eventually make that
> > the new crypto platform). If I am not mistaken, QUICK crypto is going to
> > be archived, TLS 1.3 wi
On Tue, Jan 12, 2016 at 12:18 PM, Tony Arcieri wrote:
> On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote:
>
>> I wish that were the plan (to upgrade QUIC crypto and eventually make
>> that the new crypto platform). If I am not mistaken, QUICK crypto is going
>> to be archived, TLS 1.3 will repl
On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote:
> On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote:
> > I hope that Google's efforts to get QUIC as-is specced out go quickly and
> > smoothly, and that it can be used as a basis to develop an official total
> > TCP/TLS repla
On Tue, Jan 12, 2016 at 11:27:02AM -0800, Bill Cox wrote:
>
> I'll just second what David said here. 0-RTT mode is here to stay, and I
> don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is
> a huge upgrade for users. The trick is doing this securely...
And I think because
On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote:
> On Tue, Jan 12, 2016 at 11:39 AM, Dave Garrett
> wrote:
>
>> On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
>>
>> Personally, I hope this new version of TLS, save for possibly some minor
>> update & extensions, is the final version. I
On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote:
> I wish that were the plan (to upgrade QUIC crypto and eventually make that
> the new crypto platform). If I am not mistaken, QUICK crypto is going to
> be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the
> transport laye
volutionary TLS 1.3.
Cheers,
Andrei
-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
Sent: Tuesday, January 12, 2016 11:39 AM
To: Bill Cox
Cc: tls@ietf.org
Subject: Re: [TLS] Fixing TLS
On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
> On Tue
On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett
> wrote:
> > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
> >
> > I'll be the bearer of bad news and tell you that your proposal has come up
> > in multiple forms. I suggested
On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen wrote:
> The gaps seem to be:
> - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> (BoringSSL has an implementation using cipher suite 0xca,0xfe)
>
0xca,0xfe has since been removed as nothing was using it. I'm not aware of
anything th
On Tue, Jan 12, 2016 at 09:41:26AM -0800, Eric Rescorla wrote:
> On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara
> wrote:
> >
> > DHE has serious problems. While the present TLS 1.3 way of doing DHE
> > isn't totally horrible, advertise DHE and you can get downnegotiation to
> > TLS 1.2 DHE, and
On Tue, Jan 12, 2016 at 10:06 AM, Dave Garrett
wrote:
> On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote:
> > On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote:
> > > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> > > (BoringSSL has an implementation using cipher
On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote:
> On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote:
> > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> > (BoringSSL has an implementation using cipher suite 0xca,0xfe)
>
> Correction: draft-mattsson-tls-ecdhe-psk-a
On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote:
>> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>>> Martin's comment reminded me of the following that I've been meaning to
>>> post...
>>>
>>> In a recent discussion among
On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara
wrote:
>
> > - Drop 99% of all cipher suites, leaving one traditional one (DHE +
> AES-CBC +
> > HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM +
> HMAC-
> > SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preferenc
On Tue, Jan 12, 2016 at 9:13 AM, Yoav Nir wrote:
> Hi, Peter
>
> Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
> that this WG is working on right now, why?
>
> Other groups are not working on HTTP/1.2 or IKEv1.1 or any other
> $protocolv$(major-1).$(minor+1).
>
> Any
On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote:
> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>> Martin's comment reminded me of the following that I've been meaning to
>> post...
>>
>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>> could be cam
On Tue, Jan 12, 2016 at 02:03:53PM +, Peter Gutmann wrote:
> Martin's comment reminded me of the following that I've been meaning to
> post...
>
> In a recent discussion among some crypto folks, the topic of what TLS 1.3
> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade pa
Hi, Peter
Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) that
this WG is working on right now, why?
Other groups are not working on HTTP/1.2 or IKEv1.1 or any other
$protocolv$(major-1).$(minor+1).
Any TLS library that exists now doesn’t have an implementation of eit
On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
> Martin's comment reminded me of the following that I've been meaning to
> post...
>
> In a recent discussion among some crypto folks, the topic of what TLS 1.3
> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade pat
Martin's comment reminded me of the following that I've been meaning to
post...
In a recent discussion among some crypto folks, the topic of what TLS 1.3
could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. Th
42 matches
Mail list logo
