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

[mcgrew <[e-mail]>]

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