On Mon, 2015-11-02 at 23:54 -0800, Colm MacCárthaigh wrote:
> * I think the statement "can be implemented easily without being
> vulnerable to software side-channel attacks" is too strong, unless
> one wants to really litigate what "software side-channels are".
> Unless I'm mistaken, as a stream c
On Mon, 2 Nov 2015 22:52:59 +0900
Yoshiaki Hori wrote:
> Name: draft-kiyomoto-kcipher2-tls
> Revision: 02
> Title: Use of KCipher-2 with Poly1305 in Transport Layer
I feel I've written almost the same on multiple occassions lately, but
I'll do it again:
I think one of t
Hi,
As some might remember I've been working on a draft for AES-OCB
cipher-suites in TLS
(https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/). Where,
ideally, OCB would replace CCM [or even GCM, but I don't think that's
realistic] in TLS.
Beginning of this summer Rogaway and IBM (Jutla) f
On 11/02/2015 04:06 PM, internet-dra...@ietf.org wrote:
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01
>
>
Section 2,
% 1. The 64-bit record sequence number is serialized as an 8-byte,
% big-endian value and padded on t
On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos
wrote:
>
> I agree that protecting the length of the communicated data is
> important, but there is nothing specific to this cipher.
I wouldn't contest that; I just think the I-D is over-selling ChaCha20's
side-channel resistance. I would a
Brian Smith wrote:
> This way, one Poly1305 invocation per record could be saved, potentially,
> forapplication_data records, which is the common case.
>
>
This is still true, but...
> An implementation that avavoids sending encrypted alerts and avoids
> renegotiation could avoid writing code
If you are planning to participate in the TLS session here at IETF 94 today —
either locally in Yokohama or as a remote participant — we want to make sure
that you are aware that the IETF is providing a remote participants with a
fairly new way to ask questions or make comments. In addition to u
Just to clarify, I think it is fine to define TLS 1.3 replacement for
tls-unique using Exporters. But I suggest for interoperability this should be
defined as a new channel binding with a new name, as opposed to just redefining
tls-unique.
___
TLS mail
Can you expand on this a bit? Perhaps propose some text.
-Ekr
On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov
wrote:
> Just to clarify, I think it is fine to define TLS 1.3 replacement for
> tls-unique using Exporters. But I suggest for interoperability this should
> be defined as a new chann
Can’t we just say that all previous uses of tis-unique will instead get an
exporter generated with the label “tis-unique” ?
> On 4 Nov 2015, at 11:12 AM, Alexey Melnikov wrote:
>
> Just to clarify, I think it is fine to define TLS 1.3 replacement for
> tls-unique using Exporters. But I suggest
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Ear
This includes three of the pull requests we discussed at the meeting.
I’ve left the change in IANA registry policies out for now because we’re not
yet in agreement about how that should go.
Yoav
> On 4 Nov 2015, at 12:05 PM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is availa
On 4 November 2015 at 11:16, Yoav Nir wrote:
> Can’t we just say that all previous uses of tis-unique will instead get an
> exporter generated with the label “tis-unique” ?
That was my thought here: redefine what it means to generate tls-unique.
That's part of why I asked about the size. We s
On 04/11/2015 11:13, Eric Rescorla wrote:
> Can you expand on this a bit? Perhaps propose some text.
So, tls-unique is defined in RFC 5929 as:
Description: The first TLS Finished message sent (note: the Finished
struct, not the TLS record layer message containing it) in the most
recent T
What is wrong with getTlsUnique2() or getBetterTlsUnique() ? It's not
a drop-in replacement, but it indicates that the app understands the
change. Otherwise, we might have to signal this in TLS 1.2 proper.
1.3 can just be fixed.
On 4 November 2015 at 15:42, Alexey Melnikov wrote:
> On 04/11/201
On 04/11/2015 15:48, Martin Thomson wrote:
> What is wrong with getTlsUnique2() or getBetterTlsUnique() ?
That would be fine, but see below.
> It's not a drop-in replacement,
If it is not a drop in replacement, it should have a different name.
Channel bindings are referenced by names in various
Despite the proposed extended master secret fix in RFC7627, I now think that
tls-unique needs
to be deprecated for all versions of TLS, and that we should design and
recommend
a new channel binding that can be used uniformly by SASL/TokenBinding/FIDO etc.
I have read Simon’s draft and it is a pl
17 matches
Mail list logo
