Hi,
An open issue for draft-ietf-tls-chacha20-poly1305-00 raised by Eric
Rescorla is that this draft doesn't use the draft-TLS 1.3 mechanism
for setting the nonce per record [0]. Is there any support for
switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for
TLS 1.2? The altern
On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote:
> >
> >
> > We agreed on how to do this in Prague. The sticking point was
> establishing
> > the cipher suite. I have WIP text on my machine for b
On 3 August 2015 at 17:21, Andrei Popov wrote:
>> use CertificateRequest within the handshake, and the new content type
>> outside of it
>
> Would the client then also use this new content type for Certificate and
> CertificateVerify messages (when these are sent after the handshake is
> comple
On 4 August 2015 at 05:37, Nikos Mavrogiannopoulos wrote:
> Is there any support for
> switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for
> TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the
> redundant bytes redacted as the draft is now [1].
Personally, I would
> Personally, I would rather see the nonce construction follow the form
> defined in the respective TLS version.
Yes, consistency. +1
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I'm not opposed to using a new content type in this way, if folks feel that
this makes things better.
Cheers,
Andrei
-Original Message-
From: Martin Thomson [mailto:martin.thom...@gmail.com]
Sent: Tuesday, August 4, 2015 9:13 AM
To: Andrei Popov
Cc: tls@ietf.org
Subject: Re: [TLS] Rev
On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich wrote:
> > Personally, I would rather see the nonce construction follow the form
> > defined in the respective TLS version. [DB: Adding back in for context:
> "That means including redundant bytes in TLS 1.2 and only getting the full
> advantage when we
On 4 August 2015 at 10:24, Wan-Teh Chang wrote:
> The consistency you want to see seems to be
> consistency with the AES GCM cipher suites, rather than with TLS 1.2.
Yes, this is correct.
RFC 5288:
struct {
opaque salt[4];
opaque nonce_explicit[8];
