Re: [TLS] Re: SIV as WG item?

["Dan Harkins" <[e-mail]>]

  Hi David,

  I'm not saying GCM is deficient, only more easy to get wrong (with
catastrophic results). Given the choice between the two-- pick one and
only one-- I would pick GCM, for the reasons mentioned by Eric and Uri.
But I believe SIV has a place. Sadly it looks like very few share that
belief.

  regards,

  Dan.

On Thu, January 17, 2008 10:39 am, mcgrew wrote:
> Hi Dan,
>
> You seem to be arguing that SIV should be added to TLS because GCM is
> deficient.   This line of thinking would sell both of those algorithms
> short.
>
> GCM is efficient at high data rates and high connection densities, and has
> become the preferred algorithm for such uses.  It should be added to TLS
> so
> that protocol gets those benefits.   It requires distinct nonces, but the
> protocol can easily provide these.  You may be right in pointing out that
> in
> some implementation environments, it is burdensome to provide distinct
> nonces, but the efficiencies provided by GCM make it a good tradeoff in
> many
> other environments.
>
> It would be wrong to argue that SIV should be adopted because nonce
> management for GCM and CTR are tricky.  This line of reasoning ignores
> other
> ciphersuites, such as those using CBC mode, which have no nonce management
> requirements, and it misses the fact that SIV does not have the efficiency
> advantages of GCM and CTR.
>
> You've pointed out the performance difference yourself in
> draft-dharkins-siv-aes, where you say that "SIV can not perform at the
> same
> high throughput rates that other authenticated encryption schemes can
> (e.g.
> [GCM] or [OCB]), due to the requirement for two passes of the data but for
> situations where performance is not a limiting factor-- e.g. control plane
> applications-- it can provide a robust alternative, especially when
> considering its resistance to nonce re-use."   In
> draft-harkins-tls-rsa-aes-siv-00, you mention the CAPWAP as an example of
> a
> control plane application where performance is not a limiting factor.  So
> maybe we're not in disagreement here, though since TLS is mostly not
> limited
> to control-plane applications, I think something got lost in the
> discussion
> below.
>
> Now, returning to the comparison between SIV and the use of CBC in TLS,
> SIV
> does well in this competition.  It has the advantage that it does not
> require any initialization vector.  It avoids the vulnerabilities that CBC
> has to chosen-plaintext attacks whenever the IV is predictable (as it
> unfortunately can be in TLS), while not requiring a random IV and not
> requiring any nonce management.  Not requiring any random source is a nice
> property.  It would be interesting to see if we can put together a
> ciphersuite that completely avoids the need for a random source.  Such a
> thing could be useful in some constrained environments.  (However, a
> random
> source is fundamental to DHE and to DSA signatures, and is used in RSA
> encryption, so this idea needs more research.)   SIV is less appealing
> than
> CBC for hardware implementations, but perhaps this doesn't matter so much
> since there are other methods better than both CBC and SIV in that
> application.  (Though it is worth noting out that we know that there are
> algorithms that are more performance-friendly than SIV mode, such as the
> one
> that uses a polynomial hash, as we'd discussed on the CFRG list.)
>
> I suppose that, for completeness, one should compare SIV based TLS
> ciphersuites to ones that use RC4.  I expect that people would agree that
> it
> is desirable to have alternatives to RC4, so the fact that RC4 does not
> require a random IV nor a distinct nonce should not really matter in the
> discussion of SIV.
>
> On a more positive note, I think that it is useful work to define how to
> add
> a different AEAD to TLS.  It will test out the generality of the AEAD
> interface that we've defined for TLS-GCM, and no doubt will improve our
> "algorithm agility" story.
>
> Best regards,
>
> David
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:[e-mail]]
>> Sent: Wednesday, January 16, 2008 9:58 AM
>> To: Yoav Nir
>> Cc: Simon Josefsson; [e-mail]
>> Subject: Re: [TLS] Re: SIV as WG item?
>>
>>
>>   The GCM ciphersuites for TLS use the deterministic nonce construction.
>> You can ignore the other one in SP 800-38D. Just pay attention to the
>> sections I listed.
>>
>>   Like I said, if you think that GCM cannot be implemented in TLS in
>> such a way that it could fall under any of the topics SP 800-38D
>> addresses then SIV is not for you.
>>
>>   I, on the other hand, doubt that "IT professionals" on whom the
>> security of GCM depends (according to SP 800-38D) will understand the
>> nuance around IV management. In fact, experience shows that "IT
>> professionals" will routinely cut corners with security to make things
>> be more scalable-- group pre-shared keys anyone? If all you care about
>> when deploying a security system is to merely get your boss off your
>> back then the special circumstances surrounding the particular module in
>> the system you deploy is not of paramount concern.
>>
>>   But it's fine. If you think that it is impossible to misuse your GCM
>> implementation then bully for you. Do you also think that it is
>> impossible to misuse _ANY_ TLS implementation of GCM? Is there something
>> in TLS that makes SP 800-38D not apply?
>>
>>   Dan.
>>
>> On Wed, January 16, 2008 1:38 am, Yoav Nir wrote:
>>> I've re-read the section in SP 800-38D and all it says is that the
>>> same combination of key and IV should never be re-used.
>>>
>>> Section 8.2.1 suggests two methods for IV construction: a counter and
>>> a LFSR. Both should be easy enough to implement in the cryptographic
>>> library so that the IT professional doesn't need to worry about
>>> anything. As for keys, that would depend on the IT professional, or at
>>
>>> least on getting good entropy for the TLS library, but that is no
>>> different for CBC or SIV.
>>>
>>> So I'm not sure I understand what problem SIV solves. We could have
>>> standards for GCM require either the counter or LFSR, but this can
>>> also be just recommended.
>>>
>>> On Jan 16, 2008, at 5:25 AM, Dan Harkins wrote:
>>>
>>>>
>>>>  Hi Yoav,
>>>>
>>>>  Actually NIST has commented on this, it's SP 800-38D. GCM is not
>>>> flawed provided you abide by the recommendations in that document.
>>>> Specifically section 8.2.1 for the deterministic construction of the
>>>> IV (which is used by the GCM ciphersuites for TLS). Since the nonce
>>>> construction in draft-ietf-tls-rsa-aes-gcm-01.txt is partially
>>>> implicit the recommendations in section 8.3 should be interpreted
>>>> appropriately.
>>>>
>>>>  It is also important to look at section 9.1 regarding design
>>>> consideration. For instance the module responsible for construction
>>>> of the nonce must be inside the FIPS140 cryptographic boundary.
>>>> And in the case of power loss of an entity implementing GCM, "for
>>>> [the TLS GCM ciphersuite] all of the deterministic elements that are
>>>> necessary to construct the IV would have to be available when the
>>>> power is restored. For example, these elements could be stored in
>>>> non-volatile memory."
>>>>
>>>>  There are also operational considerations in section 9.2 that lists
>>>> questions that must be answered when deploying a GCM implementation.
>>>> It states, "Compliance with the uniqueness requirement on IVs, and
>>>> hence THE SECURITY OF GCM, ultimately DEPENDS ON THE IT PROFESSIONAL
>>>> WHO CONFIGURES, DEPLOYS, AND MAINTAINS THE GCM MODULESS within a
>>>> particular system." (emphasis mine and I apologize for screaming).
>>>>
>>>>  So yes, defer to NIST. If you read SP 800-38D and are satisfied that
>>
>>>> all of the relevant requirements are adhered to then GCM is secure.
>>>> If you don't feel it's possible to guarantee that all of those
>>>> requirements can be met or if you don't feel comfortable placing the
>>>> security of the system in the hands of "the IT professional" who
>>>> configures it then maybe it's not for you.
>>>>
>>>>  Now, back to my screaming above for a second. It is this notice in
>>>> SP 800-38D that really makes the SIV ciphersuites attractive. All of
>>>> the text in SP 800-38D (approx 8 pages of it) do not apply to SIV
>>>> because it is secure even in the presence of IV misuse. That is, if
>>>> the IT professional intentionally or unintentionally misconfigures,
>>>> misdeploys or improperly maintains a GCM module security is voided
>>>> but if that module had been a SIV module security would not be voided
>>
>>>> (assuming, of course, that the misuse by the IT professional results
>>>> in IV misuse which is the a valid assumption since that's the topic
>>>> of the quote above).
>>>>
>>>>  The need for a SIV-based ciphersuites depends on whether you have
>>>> any discomfort with any of the numerous requirements placed on proper
>>
>>>> use of GCM. If you think that the design considerations of SP 800-38D
>>
>>>> are met due to the nature of the TLS protocol and that the deployment
>>
>>>> considerations either don't apply ("it's your problem if you
>>>> misconfigure it so tough luck") or are similarly met due to the
>>>> nature of the TLS protocol then SIV-based ciphersuites are probably
>>>> not important enough to bring to the WG. If, on the other hand, these
>>
>>>> design and deployment considerations make you uncomfortable and that
>>>> a TLS module implementing GCM might be too fragile then a
>>>> misuse-resistant alternative like SIV becomes important and
>>>> attractive.
>>>>
>>>>  regards,
>>>>
>>>>  Dan.
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/tls
>
>




_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls