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
> Switching to a protocol like TLS 1.3 as it is today to fix that thing it is
> an overkill.
The primary purpose of a security protocol is to support security as best as
possible. Knowing security gaps causes distrust in general. Probably not in the
security protocol experts community, but in t
> On 12 Jan 2016, at 21:31, Ilari Liusvaara wrote:
>
>> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:
>>
>>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson wrote:
>>>
>>> The same concern still applies: what does it mean to allocate code
>>> point for the 4492bis-05 description?
>>
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
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
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 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:
>
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 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)
> 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
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
Hi All,
Looks like I jumped too soon on this one. In particular, both the CFRG
signature draft and 4492bis need to be updated. Let's hold of on code
point assignment until then.
Thanks,
Joe
(crawling back under my rock now)
On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov
wrote:
>
> > On 12
We (OpenSSL) have already tested interop of chacha/poly with other browsers and
TLS stacks, and now it all works. (The official IETF version, not the QUIC
version).
We (Akamai) are planning on enabling it for our customers in a few weeks, in
case anyone might be interested.
Thanks.
Chrome is also expecting to ship the cipher in Chrome 49. It's available in
Canary and Dev channel right now. It should interop with OpenSSL's master
branch as of when I last tested this.
David
On Wed, Jan 13, 2016 at 12:48 PM Salz, Rich wrote:
> We (OpenSSL) have already tested interop of chac
I have a question about the even-vs-odd restrictions on the length of
a valid variable-length vector defined in TLS specification after
reading the section 4.3 of RFC 5246 [1] which states that: "The length
of an encoded vector must be an even multiple of the length of a
single element (for example
On 01/13/2016 02:44 PM, Jong-Shian Wu wrote:
> I have a question about the even-vs-odd restrictions on the length of
> a valid variable-length vector defined in TLS specification after
> reading the section 4.3 of RFC 5246 [1] which states that: "The length
> of an encoded vector must be an even mu
On Thu, Jan 14, 2016 at 4:53 AM, Benjamin Kaduk wrote:
> It means "whole-number" as opposed to fractional, i.e., there should not
> be unused "junk bytes" at the end.
>
> -Ben
Ah, so that is not about even vs odd numbers at all. Thank you very
much for the quick clarification!
_
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
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
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
20 matches
Mail list logo
