-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/08/15 22:17, Aaron Zauner wrote:
> I'd be happy to receive feedback on the document and am looking
> forward for people to try out AES-OCB in TLS (an upcoming OpenSSL
> version will ship with default-support I am told).
We already have AES-OCB
I looks like we’ve come to WG consensus that the sect571r1 curve should be
removed from the TLS 1.3 & 4492bis drafts.
spt
On Jul 20, 2015, at 09:08, Hubert Kario wrote:
> On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote:
>> On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote:
>>> What
Hi Folks,
This is the Working Group last call for draft-ietf-tls-cached-info-19.
This document has undergone modification since last WGLC so another WGLC is
appropriate. This document is a dependency for the DICE working group
TLS/DTLS profile. Please send your comments to the TLS list by Septemb
On 5 August 2015 at 11:13, Wan-Teh Chang wrote:
> Then, define the ChaChaNonce struct as described in the draft-TLS 1.3.
>
>struct {
>opaque nonce[12];
>} ChaChaNonce;
>
> 1. The 64-bit record sequence number is padded to the left with
> zeroes to 96 bits
I've read this draft before, but this is considerably different to
what I read, and I haven't been following the discussion, so consider
this as a review with fresh eyes.
First the high points. I think that this is useful, the right scope,
and reasonably well formulated. I have a couple of minor
I recently reviewed the most recent TLS 1.3 draft, and I must say that I am
impressed; the protocol appears to be a significant improvement. In
particular, you simplify the protocol significantly, and as we all know,
complexity is the enemy of security. You also drop many of the weak options,
On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) wrote:
> I recently reviewed the most recent TLS 1.3 draft, and I must say that I
> am impressed; the protocol appears to be a significant improvement. In
> particular, you simplify the protocol significantly, and as we all know,
> complex
This is about adding a new signature primitive (such as the
(eventual) CFRG scheme).
There are basically two issues:
1) Do we allocate new ciphersuite codepoints or not? So far
each certificate algorithm in ciphersuite has corresponded
to only one signature algorithm.
Implications of new codepoi
