Subject: [saag] draft-iab-crypto-alg-agility-01.txt

From: Russ Housley <[email-masked]>
Date: Fri, 27 Jun 2014 14:47:41 -0400

Thanks for the lively discussion of the -00 version of this document.  Please review and comment on the updated version.

Russ

> A new version of I-D, draft-iab-crypto-alg-agility-01.txt
> has been successfully submitted by Russell Housley and posted to the
> IETF repository.
> 
> Name:		draft-iab-crypto-alg-agility
> Revision:	01
> Title:		Guidelines for Cryptographic Algorithm Agility
> Document date:	2014-06-27
> Group:		iab
> Pages:		8
> URL:            http://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/
> Htmlized:       http://tools.ietf.org/html/draft-iab-crypto-alg-agility-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-iab-crypto-alg-agility-01
> 
> Abstract:
>   Many IETF protocols may use of cryptographic algorithms to provide
>   confidentiality, integrity, or non-repudiation.  Communicating peers
>   must support the same cryptographic algorithm or algorithms for these
>   mechanisms to work properly.  This memo provides guidelines for
>   ensuring that such a protocol has the ability to migrate from one
>   algorithm to another over time.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 27 Jun 2014 19:25:33 +0000

Am I the only one who believes that the draft would be stronger if it also discussed the "pitfalls of agility?" The poster child for that is probably TLS. The protocol includes a negotiation capability, so that the parties can chose from a list of enumerated options. In theory, that's very nice. As time passes, better options become available and can be negotiated, providing for better security. But in practice, there are issues: downgrading attacks, code bloat, unclear rules for how to choose the "best" option, difficulty to remove obsolete options... As a design rule, it seems that "few good options" is better than "unfettered negotiation."

There are counter arguments, e.g. national governments insisting that their communications be secured via homemade crypto. These type of deployments use the negotiation capability to choose a nonstandard algorithm, which would go against the "few good options" guideline. So there is clearly room for debate. I think it would be nice if the draft reflected that debate.

-- Christian Huitema

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Jun 2014 13:43:10 -0700

Christian said: 
"Am I the only one who believes that the draft would be stronger if it also discussed the "pitfalls of agility?" 

[BA] Not just pitfalls - but also advice on how to properly design for crypto-agility. 
One of the reasons to have crypto-agility is to make it possible to transition from weak algorithms to stronger ones. 
Yet while such a transition is in progress, by definition it is necessary to still be willing to negotiate a known weak algorithm.  
However, tolerance for weak algorithms cannot go on forever - or else crypto-agility just becomes a mechanism for enabling downgrade attacks. 
At some point, you have got to remove support for the weak algorithms entirely, or at least refuse to negotiate them. 
Even trickier is when the mechanism protecting the cryptographic negotiation is itself weak - and not negotiable. 
The IETF has presumably gone through these kind of design problems multiple times, so some "best practices" could be culled from all the (painful) experience.

---

From: Paul Lambert <[email-masked]>
Date: Fri, 27 Jun 2014 14:15:26 -0700

]-----Original Message-----
]From: saag [mailto:[email-masked]] On Behalf Of Christian Huitema
]Sent: Friday, June 27, 2014 12:26 PM
]To: Russ Housley
]Cc: IETF SAAG
]Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt
]
]Am I the only one who believes that the draft would be stronger if it
]also discussed the "pitfalls of agility?" 
+1
I am very much in favor of "diversity", but share your concerns
of the dangers of "agility"

]The poster child for that is
]probably TLS. 
While not an IETF protocol, the problems of IEEE 802.11 
security algorithm diversity is another example:
 - interoperability problems are common because of the
   ability to mix different key management and 
   traffic algorithms
   (this is a good reason to have 'cipher suites'
   versus a 'Chinese Menu' approach)
 - not all of the diversity of options make sense to users
 - polices for multiple algorithms are not combined in a way that supports
   upward support to better algorithms
   (e.g.  giving user choice of TKIP or AES versus
    AES or TKIP)
 - implementations are continually pulled down to the lowest 
   common denominator
 - WEP has been very difficult if not impossible to remove from 
   products since service providers want the broad3st 
   interoperability 

]The protocol includes a negotiation capability, so that
]the parties can chose from a list of enumerated options. In theory,
]that's very nice. 
Not always.  How do we control the usage policies to ensure that
the "good" algorithm is used for important traffic and the "bad"
algorithm might be used for other less important traffic.

]As time passes, better options become available and
]can be negotiated, providing for better security. But in practice, there
]are issues: downgrading attacks, code bloat, unclear rules for how to
]choose the "best" option, difficulty to remove obsolete options... 
Exactly

]As a
]design rule, it seems that "few good options" is better than "unfettered
]negotiation."
Yes. 

Paul

]
]There are counter arguments, e.g. national governments insisting that
]their communications be secured via homemade crypto. These type of
]deployments use the negotiation capability to choose a nonstandard
]algorithm, which would go against the "few good options" guideline. So
]there is clearly room for debate. I think it would be nice if the draft
]reflected that debate.
]
]-- Christian Huitema
]
]
]_______________________________________________
]saag mailing list
][email-masked]
]https://www.ietf.org/mailman/listinfo/saag