Adding new ciphers would still involve patching existing 1.2 code, so I would
expect the same answer: move to DTLS 1.3 when its ready
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
From: Jayaraghavendran Kuppannan [mailto:jayaraghavendr
> I do understand that the number of slots for ciphers in the above list is
> somewhat limited and additions should be considered carefully.
>
> However, seeing that there are over 60 TLS_DH_* ciphers in that list and well
> over 60 CAMMELIAs - to be clear, I am not arguing against the latter algo
L.S.,
Seeing how AES-192 seems to hold up well against related key attacks (at
least the (theoretical) one described in
http://eprint.iacr.org/2009/317) I am rather surprised no AES-192
ciphers have been defined for TLS
(http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-param
On Mon, Jan 16, 2017 at 7:01 AM, Jayaraghavendran Kuppannan <
jayaraghavendran.i...@gmail.com> wrote:
> Hi Eric,
>
> You had mentioned last time that if the scenario really warranted, we can
> define new cipher suites for this rather than defining a new extension. Do
> you still think it would be
Hi Andreas,
Thanks for the help in reviewing the draft as well as in providing your
usage scenario.
Regards,
Jay
On Mon, Jan 16, 2017 at 6:51 PM, Andreas Walz
wrote:
> Hi Jay,
>
> our scenario is the following: we are considering a legacy industrial
> communication system with a number of spat
Hi Eric,
You had mentioned last time that if the scenario really warranted, we can
define new cipher suites for this rather than defining a new extension. Do
you still think it would be a good idea for us to propose a draft on the
same?
Thanks!
Regards,
Jay
On Mon, Jan 16, 2017 at 7:05 PM, Eric
Hi Andreas,
We dropped that draft as there was not much interest in the community for
the same. We will be glad to revive it incase if there is enough interest
in the community.
Regards,
Jay
On Mon, Jan 16, 2017 at 7:05 PM, Eric Rescorla wrote:
> Andreas,
>
> DTLS 1.3 will behave this way by d
Andreas,
DTLS 1.3 will behave this way by default, so it would be better to just
move to 1.3 rather than patching 1.2.
-Ekr
On Mon, Jan 16, 2017 at 5:32 AM, Andreas Walz
wrote:
> Hi all,
>
> I stumbled upon an expired draft introducing a new (D)TLS extension to
> omit explicit nonces in (D)TL
On Mon, Jan 16, 2017 at 1:59 AM, Nikos Mavrogiannopoulos
wrote:
> On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote:
>
> > Original Text
> > -
> >If a compatible TLS server receives a Supported Groups extension
> > from
> >a client that includes any FFDHE group (i.e.,
Hi all,
I stumbled upon an expired draft introducing a new (D)TLS extension to omit
explicit nonces in (D)TLS AEAD cipher modes
(draft-jay-tls-omit-aead-explicit-nonce-extension). For a number of cipher
suites, this would allow to reduce the per-record overhead in (D)TLS by 8 bytes.
Is there a
Hi Jay,
our scenario is the following: we are considering a legacy industrial
communication system with a number of spatially distributed stations.
Inter-station communication is based on a simple proprietary protocol
over a very lean and lossy wireless channel. The channel features 2.4
kbits/s an
On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote:
> Original Text
> -
> If a compatible TLS server receives a Supported Groups extension
> from
> a client that includes any FFDHE group (i.e., any codepoint
> between
> 256 and 511, inclusive, even if unknown to the se
12 matches
Mail list logo
