Subject: [TLS] SIV as WG item?

From: <[email-masked]>
Date: Thu, 10 Jan 2008 14:44:39 +0200

<wg chair hat on>

Dan Harkins already asked people to comment draft-harkins-tls-rsa-
aes-siv, but I'd like to repeat the request officially, as the
document is being proposed for WG item.

In particular, please provide comments not only the technical details,
but whether you think this is useful; should it be done as WG item or
individual document; and whether you're willing to work on this
document.

Best regards,
Pasi

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jan 2008 15:41:09 +0100

> individual document; and whether you're willing to work on this

Generally speaking, I believe the crypto community will produce several
AEAD cipher modes with rather different properties (speed, IV-use,
provable security, patent status, and so on).

Having all those ciphers defined for TLS is an advantage, to allow
interoperable testing.  What is less clear at this point is which of the
alternatives to prefer.  I'm not sure a Standards Track status for any
of them (including GCM) is appropriate at this time.  There is nothing
proven wrong with our existing standard ciphers as far as I know.
Replacing working standards ciphers without a good technical reason
seems wrong to me.

Thus, right now, I think I would prefer to publish all AEAD ciphersuites
for TLS as informational or experimental documents, and wait until one
(or more) of them are implemented and used more widely.  I believe it is
better to develop all these ciphers as WG items, to make sure they are
defined in a correct and consistent way.

I may be missing some convincing reason why an AEAD cipher for TLS needs
to have standards track status, and if so, I would re-consider this
position.

/Simon

---

From: <[email-masked]>
Date: Mon, 14 Jan 2008 10:26:41 +0200

Simon Josefsson wrote:

> Generally speaking, I believe the crypto community will produce
> several AEAD cipher modes with rather different properties (speed,
> IV-use, provable security, patent status, and so on).
> 
> interoperable testing.  What is less clear at this point is which of
> the alternatives to prefer.

Many of the arguments made in the recent discussion about IDEA
(e.g., more code means more complexity and less security in
practise, especially if some of that code is rarely used and thus
largely untested; and having too many "vanity" options just causes
problems) would suggest that having *all* those ciphers defined in
TLS would not be a such good idea.

This doesn't mean that we have to decide on a single AEAD mode, but
IMHO for any specs we write, we should have an expectation that it
will see non-insignificant real-world deployment (i.e., ends up
being used, as opposed to just being implemented by some library).

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jan 2008 10:42:06 +0100

> TLS would not be a such good idea.

I think there is a significant difference between the IDEA situation and
the AEAD situation: the IDEA ciphersuites are mentioned in the core TLS
specification.  We should (rightly) be more conservative about any
complexity complications in the core document.

As far as I have understood, no single AEAD ciphersuite will be
recommended or specified in the TLS 1.2 specification.

If so, having multiple informational documents on different AEAD
ciphersuites leads to simpler real-world-like comparisons between them.
When we have had some time to evaluate these, and have let the crypto
community scrutinize the various different AEAD modes for some time, we
can chose a small set of them (possibly a single one) to promote to
standards track status.

However, I don't feel strongly about this, and this is just my gut
reaction on how I would prefer to do it.  There may be some compelling
arguments for doing it in some other way that I haven't considered.

Thanks,
/Simon

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Jan 2008 12:03:40 +0200

> arguments for doing it in some other way that I haven't considered.

That gives the writers of OpenSSL/GnuTLS/Windows CAPI no guidance. I  
think if we do that, the result would be not what the cyrpto community  
scrutinizes, but what Microsoft did and OpenSSL copied.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 14 Jan 2008 11:23:15 +0100

Yoav Nir <[email-masked]> writes:

> That gives the writers of OpenSSL/GnuTLS/Windows CAPI no guidance.

I think part of my point is that at this time there is not enough
guidance to give: or do we actually know which properties of the various
AEAD proposals are critical for Internet-wide use?

I don't feel comfortable claiming that the nonce-reuse problem in GCM is
never going to lead to serious security problems.  Nor would I feel
comfortable to claim that GCM is inherently flawed because of it.

If there are specification for several AEAD ciphersuite to chose from,
they would each contain discussions of their applicability.  If we only
specify AES-GCM and kill other proposals, I suspect that will make it
more difficult to re-consider the situation later on.

I guess I have argued my point of view now, so I'll try to shut up and
let others talk.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Jan 2008 12:37:08 +0200

Supporting only GCM has the advantage that it works well with the "In  
NIST we trust" model of cryptographic reasoning.

I'm also missing some performance measurements of AES-GCM vs AES-SIV  
vs AES-CBC+HMAC-SHA1. We have the original papers from the authors,  
who made the measurements on a 1 GHz PPC processor. I'm not sure how  
much of an advantage we'd get with more common processors and with  
optimized code. Right now, I don't know what, if anything, any of the  
AEAD ciphersuites would give me.

I don't think GCM is seriously flawed at least in its use in TLS or  
IPsec. But like you, I'm not comfortable claiming it.  In this it may  
be wise to defer to NIST, unless some cryptographer has a different  
view and would like to weigh in.

On Jan 14, 2008, at 12:23 PM, Simon Josefsson wrote:

> Scanned by Check Point Total Security Gateway.
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 15 Jan 2008 19:25:14 -0800 (PST)

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.

---

From: <[email-masked]>
Date: Wed, 16 Jan 2008 11:26:27 +0200

> power is restored. For example, these elements could be stored in

This storage requirement applies only to implementations that
also store (or are in some way able to recover or reuse) the key
itself. 

(Section 9.1, "If the generation unit cannot recover from a loss of
power, then the authenticated encryption function shall enter a
failure state until a fresh key can be established.")

>   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.

As far as I can tell, all (or almost all) of these considerations
are about ensuring proper IV generation and other "cryptographic
hygiene" to ensure one given key doesn't end up being used in
different contexts (e.g. across power loss, with different GCM
mode options, etc.). With complications such as system backups,
this will ultimately depend on the IT administration procedures
as well.

Those concerns don't really seem to apply to protocols that
always establish fresh keys, and during that key establishment,
agree on how the key will be used.

Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Jan 2008 11:38:18 +0200

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.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 16 Jan 2008 09:42:58 -0800 (PST)

Yes, they are all about "cryptographic hygiene". Notice how the
fact that the key is "fresh" is only one of the considerations in
SP 800-38D? The fact that TLS produces "fresh" keys does not, by
itself, mean that it is secure or complies with requirements listed
in SP 800-38D. That is necessary but in no way is it sufficient.

  You may think that there is some other aspect to TLS that makes it
unique so that it can only be implemented in a way that precludes any
of the problems that the SP 800-38D addresses. Only I don't agree.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 16 Jan 2008 09:57:36 -0800 (PST)

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.

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 16 Jan 2008 13:38:32 -0500

IMHO the assumption is that there aren't going to be many TLS implementations - just like there weren't many IPsec implementations.

Those who do find the need (and financial resources :-) to re-implement TLS (as opposed to application writers that usually - always? - take existing reference implementations) are likely to know enough to implement GCM the right way (which isn't so hard after all).

I don't expect "IT professionals" going off re-implementing TLS, not any more than re-implementing Linux or Windows.

Regarding SIV - let it live like other AEAD modes, with GCM having the advantage among them of being already recognized and deployed.

On 1/16/08 12:57 PM, "Dan Harkins" <[email-masked]> wrote:

  Dan.

--
Regards,
Uri

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Jan 2008 04:35:30 -0800

At Wed, 16 Jan 2008 09:57:36 -0800 (PST),
> makes SP 800-38D not apply?

Dan,

As I said in the WG meeting, I think this only meets half the burden for
SIV being a good idea. TLS has a block cipher mode which is extremely
resistant to IV reuse: CBC. The reason that GCM is attractive is that
it has good performance and ciphertext size properties as compared to
CBC. Given that SIV doesn't have particularly good performance propoerties,
in what settings would it be significant improvement over CBC?

-Ekr

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 17 Jan 2008 10:12:40 -0800

In the AES-GCM ciphersuite in TLS the nonce is managed by the TLS
implementations.  The segment of "IT professionals" that need to deal
with nonces is not those that deploy systems, rather it is those that
implement the TLS module.  It is possible that an implementer may
incorrectly implement a cryptosystem.   This is true regardless which
mode is used (GCM,SIV,CBC, etc.)

In addition, as Eric mentioned, while GCM and SIV are both AEAD
ciphersuites, they have different performance characteristics.  It is
likely that a user choosing GCM would be unhappy replacing it with SIV.

Cheers,

Joe  

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2008 9:58 AM
> To: Yoav Nir
> Cc: Simon Josefsson; [email-masked]
> Subject: Re: [TLS] Re: SIV as WG item?
> 
> 
> 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.
> 
> >> 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 
> >> 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.
> >>
> >> 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.
> >
> >
> 
> 
> 
>