RE: SIV Ciphersuites for TLS
Dan Harkins <dharkins <at> lounge.org>
2008-01-08 07:22:30 GMT
Hi Pasi,
Thank you very much for your comments on my draft. A few comments on
your comments.
Deriving a fresh key is not the issue, it's whether one can
guarantee that a nonce will never be misused for a given (fresh) key.
The other thing I will take issue with is your statement that nonce
management is "the job of the TLS library". That very much depends
on the TLS library. The API to call AES in CBC mode in OpenSSL takes
an IV from the caller-- i.e. the application programmer. Now I can't say
what a call to AES in GCM mode will take since I don't have an OpenSSL
library that implements TLS1.2 but given the way the library is constructed
and used today it is entirely reasonable to assume that nonce management
will be in the hands of the application programmer and not inside the
cryptographic engine.
I will note that for those of you that are worried about FIPS you should
already know that anything that has cryptographic relevance is deemed to be
inside the cryptographic boundary. For GCM the nonce is _highly_ relevant.
That can automatically pull in large chunks of code which otherwise would
not have been inside the cryptographic boundary: CLI, web browser, etc. For
SIV the nonce is not relevant as security is maintained even when the nonce
is misused or reused. Using an SIV-based cipher suite would allow
applications that really aren't cryptographically relevant but may be
forced to manage nonce space to be outside of a FIPS 140 cryptographic
boundary. That can be very beneficial when one considers bug fixing in
things like a web browser: does it require another trip to the FIPS
validation laboratory (and several months) or a letter (and a few weeks)
before we can release the next version of FIPS-validated software.
When GCM becomes widely used in TLS there is a HUGE assumption being made.
The entire security of a scheme using GCM depends on one thing that we are
just blithely stating will not happen. It's not really coding errors per se,
it's an honest attempt to use a library by someone who is just not aware
of the nuances surrounding the creation and management of a variable under
his or her control. Type "man crypto"..."man aes"...note arguments...
create data that does not return an error...on to next coding task. Ship it!
Having a system that does not lose all security in the presence of
unintentional coding errors, unintentional misconfiguration, or intentional
stupidity or malfeasance would, in my opinion, be a big benefit. But you
said that benefit seems marginal to you and the silence of the rest of the
list has been noticed.
best regards,
Dan.
On Sun, January 6, 2008 11:18 pm, Pasi.Eronen <at> nokia.com wrote:
> Some general comments, mostly repeating things said at the
> Vancouver meeting:
>
> - Being resistant to nonce misuse is indeed a good idea in some
> environments (where spec writers and/or implementors may not fully
> understand the situation), it doesn't seem very important in TLS.
> TLS always derives fresh keys, so the opportunities for getting things
> wrong are rather limited.
>
> - Certainly an application writer doesn't have to understand the
> nuances of nonce management -- that's the job of the TLS library (and
> an application programmer who doesn't understand crypto shouldn't
> implement his/her own TLS library anyway -- there are many other
> things he/she will get wrong.)
>
> - If we're concerned with implementation errors in the TLS library
> itself (and think that SIV is harder to get wrong than GCM), we
> already have cipher suites which are pretty good in this regard (i.e.,
> possibly harder to get wrong than GCM): the CBC mode cipher suites,
> which have the advantage that everyone implements them already (i.e.,
> no new code needed, thus less opportunities for new bugs).
>
> - While the SIV mode has slightly smaller per-packet overhead than
> CBC mode, it's also slower to compute than GCM. So if CBC is good
> enough for almost everyone, and those requiring high performance
> use GCM, what's the environment where SIV would be good?
> (The obvious answer "those who want small per-packet overhead,
> don't care about computational costs, and don't trust implementors
> to get GCM right" IMHO seems rather marginal.)
>
> Best regards,
> Pasi
>
>> -----Original Message-----
>> From: ext Dan Harkins [mailto:dharkins <at> lounge.org]
>> Sent: 21 December, 2007 20:48
>> To: tls <at> ietf.org
>> Subject: [TLS] SIV Ciphersuites for TLS
>>
>>
>> Greetings,
>>
>> I presented the document RSA AES-SIV Ciphersuites for TLS at the
>> last meeting in Vancouver. It is my hope that this document would be
>> accepted as a WG document and solicit more review and comments from
>> everyone here. The document can be found at:
>>
>> http://www.ietf.org/internet-drafts/draft-harkins-tls-rsa-aes-
>> siv-00.txt
>>
>
>> Since this email is arriving in the midst of a discussion to drop
>> support for another cipher-suite I would like to explain why this
>> one should be added: SIV is an AEAD mode that is resistant to nonce
>> misuse (unlike other counter-mode constructs like GCM) and is
>> therefore well-suited for cases where an application writer, who may
>> not understand the cryptographic nuances of nonce management for
>> other cipher-suites, obtains TLS services for his application by
>> linking to an external library.
>>
>> Please take a look and send comments.
>>
>> regards,
>>
>> Dan.
>
RSS Feed