Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06

From: Russ Housley <[email-masked]>
Date: Wed, 2 Sep 2015 16:48:38 -0400

Viktor:

Apologies.  I seem to have missed this message when I did the updates for -07.  Thankfully, Stephen noticed.  The document will be improved by tackling these comments.

> Intro paragraph 2:
> 
>       Advances in computing power available to the attacker will eventually
>       make any algorithm obsolete.
> 
>    I think this overstates the plausible advances in computing power.
>    Many of the symmetric algorithms in use today are far outside the
>    realm of any physically realizable brute force attack, unless also
>    weakened through analytic techniques.

Pulling some thoughts from the things Kenny said earlier this week, I suggest:

   Cryptographic algorithms age; they become weaker with time.  As new
   cryptanalysis techniques are developed and computing capabilities
   improve, the work required to break a particular cryptographic
   algorithm will reduce, making an attack on the algorithm more
   feasible for more attackers.  While it is unknown how cryptoanalytic
   attacks will evolve, it is certain that they will get better.  It is
   unknown how much better they will become, or when the advances will
   happen.  Protocol designers need to assume that advances in computing
   power or advances cryptoanalytic techniques will eventually make any
   algorithm obsolete.  For this reason, protocols need mechanisms to
   migrate from one algorithm suite to another over time.

> Section 2.1 second para top of page 4:
> 
>       Regardless of the approach used, protocols historically negotiate the
>       symmetric cipher and cipher mode together to ensure that they are
>       completely compatible.
> 
>   I would drop the word "completely".  And ditto in the next paragraph.

Done.

> Section 2.2 first para:
> 
>       For this reason, the protocol MUST specify one or more strong
>       mandatory-to-implement algorithm or suite.
> 
>   One or more is I believe more typically plural, so that would
>   be "algorithms or suites".

Done.

> Section 2.2.1:
> 
>       This approach allows other protocols can make use of CMS
>       and make different mandatory-to-implement algorithm choices.
> 
>   s/can/to/

Done.

> Section 2.4:
> 
>       Without integrity protection of algorithm or suite selection,
>       the attempt to transition to a new algorithm or suite may
>       introduce new opportunities for downgrade attack.
> 
>   Perhaps "for a downgrade attack" or "for downgrade attacks".

Done.

> I find section 2.5 too vague, not sure what point it is really
> trying to make.

I'm not sure how to handle this comment.  I guess the point that I am trying to make is that there can be too many levels of indirection and still preserve the integrity of the first part of the negotiation.

> Section 2.6:
> 
>       The impacts of legacy software an long support tails on security
>       can be reduced by making it easy to rollover from old algorithms
>       and suites to new ones.
> 
>    s/impacts/impact/
>    s/an long/and long/
>    s/rollover/transition/

Done.

>       Without clear mechanisms for algorithm and suite rollover,
>       preserving interoperability becomes a difficult social
>       problem.  For example, consider web browsers.  Dropping
>       support for an algorithm suite can break connectivity to
>       some web sites, and the browser vendor will lose users by
>       doing so.  This situation creates incentives to support
>       algorithm suites that would otherwise be deprecated, but
>       preserving interoperability.
> 
>    s/rollover/transitions/
>    s/but preserving/in order to preserve/

Merging with comments from others, the current text is:

   Without clear mechanisms for algorithm and suite transition,
   preserving interoperability becomes a difficult social problem.  For
   example, consider web browsers.  Dropping support for an algorithm
   suite can break connectivity to some web sites, and the browser
   vendor will lose users by doing so.  This situation creates
   incentives to support algorithm suites that would otherwise be
   deprecated in order to preserve interoperability.

> 	The digital signature on a trust anchor certificate [RFC5280]
> 	is often expected to last decades, which hinders the
> 	transition away from a weak signature algorithm or short
> 	key length.
> 
>    This example is somewhat flawed, browsers and CAs are well
>    along the process of deprecating SHA-1, while ignoring its
>    presence in trust-anchor certificates, because their self-signatures
>    are typically not checked (check not needed).

I have updated the example:

   Transition in Internet infrastructure is particularly difficult.  The
   digital signature on the certificate for an intermediate
   certification authority (CA) [RFC5280] is often expected to last
   decades, which hinders the transition away from a weak signature
   algorithm or short key length.  Once a long-lived certificate is
   issued with a particular signature algorithm, that algorithm will be
   used by many relying parties, and none of them can stop supporting it
   without invalidating all of the subordinate certificates.  In a
   hierarchical system, many subordinate certificates could be impacted
   by the decision to drop support for a weak signature algorithm or an
   associated hash function.

> 	   Institutions, being large or dominate users within a large
> 	   user base, can assist by coordinating the demise of an
> 	   algorithm suite, making the rollover easier for their own
> 	   users as well as others.
> 
>    Somehow the meaning of the above eludes me.  It needs a rewrite.

The point is that big customers can help with the social part of the transition by putting pressure on their suppliers.  I'm not sure what part to change to make that more clear for you.

> Section 2,7:
> 
>       When selecting or negotiating a suite of cryptographic algorithms,
>       the strength of each algorithm SHOULD be considered.  The algorithms
>       in a suite SHOULD be roughly equal;
> 
>    s/roughly equal/comparably strong/ or (to really spell it out):
>                   /have comparable best known attack work-factors/
> 
>    However if a particular element of a suite is believed stronger
>    than the rest, we don't need to get too pedantic about that.
>    Slightly lop-sided choices are OK if the stronger outlier is
>    adequately fast, and weaker variants are not widely used.

That was the point of "roughly".  Also, the second paragraph bring in the point about performance being a factor.

How about this:

   When selecting or negotiating a suite of cryptographic algorithms,
   the strength of each algorithm SHOULD be considered.  The algorithms
   in a suite SHOULD be roughly equal; however, the security service
   provided by each algorithm in a particular context needs to be
   considered when making the selection.  Algorithm strength needs to be
   considered at the time a protocol is designed.  It also needs to be
   considered at the time a protocol implementation is deployed and
   configured.  Advice from from experts is useful, but in reality, such
   advice is often unavailable to system administrators that are
   deploying a protocol implementation.  For this reason, protocol
   designers SHOULD provide clear guidance to implementors, leading to
   balanced options being available at the time of deployment.

>       For example, cipher suites include Diffie-Hellman or RSA without
>       specifying a particular public key length.  If the algorithm
>       identifier or suite identifier named a particular public key
>       length, migration to longer ones would be more difficult.  On
>       the other hand, inclusion of a public key length would make it
>       easier to migrate away from short ones when computational
>       resources available to attacker dictate the need to do so.
>       Therefore, flexibility on asymmetric key length is both desirable
>       and undesirable at the same time.
> 
>       s/cipher suites include/TLS cipher suites include/

Done.

>   Overall I think this text is wrong to weasel out.  Failure to
>   negotiate the DH parameter size has proved rather problematic
>   in TLS, with servers needing to guess at universally inteoperable
>   prime bit length.  This is being addressed, with the DH groups
>   extension now supporting standard prime groups as well as standard
>   EC curves.  Underspecified algorithms MUST NOT be used.  Either
>   fix the parameters, or negotiate them.

You raise an important point.  I suggest:

   Performance is always a factor is selecting cryptographic algorithms.
   Performance and security need to be balanced.  Some algorithms offer
   flexibility in their strength by adjusting the key size, number of
   rounds, authentication tag size, prime group size, and so on.  For
   example, TLS cipher suites include Diffie-Hellman or RSA without
   specifying a particular public key length.  If the algorithm
   identifier or suite identifier named a particular public key length,
   migration to longer ones would be more difficult.  On the other hand,
   inclusion of a public key length would make it easier to migrate away
   from short ones when computational resources available to attacker
   dictate the need to do so.  The flexibility on asymmetric key length
   has lead to interoperability problems, and to avoid these problems in
   the future any aspect of the algorithm not specified by the algorithm
   identifier MUST be negotiated, including key size and parameters.

> Section 2.8:
> 
>       Protocol designers MUST be prepared for the supported cryptographic
>       algorithm set to change over time.  There is a spectrum of ways
>       to enable the transition, and Section 3 discusses dome of the
>       related issues.
> 
>    s/is a spectrum/are a number/
>    "spectrum" implies some sort of continuum, which does not apply here.

Done.

> Section 2.9:
> 
>    Opportunistic security is no excuse for designing in weaker
>    algorithms into new protocols.  The text in RFC7435 relating
>    to tolerating weaker algorithms in the name of interoperability
>    is intended only for legacy systems.  When we're grafting crypto
>    onto existing systems that run over cleartext, even weak crypto
>    is better than none, but only if is already in use and required
>    for interop.  For de-novo designs, the crypto should be just as
>    strong.  Let's not lose from the get-go.
> 
>    Opportunistic security emphases adapting to peer capabilities,
>    and incrementatl deployment, and should be considered where it
>    would lead to greater use of security than all-or-nothing
>    approaches.  The agility angle here, is that when deprecating
>    algorithms that are still in wide use, opportunistic protocols
>    might take longer to phase them out, because interoperability
>    is a higher priority than in protocols with mandatory security.

Kathleen proposed a major rewrite of this section earlier this week, and you have already provided comments on that.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Sep 2015 17:18:10 -0400

Viktor:

You comments were provided in two message, so I am responding to them separately as well.

> Section 3.1 first paragraph:
> 
>    The sentence:
> 
>       It seems like the ability to use an algorithm of one's own
>       choosing is very desirable; however, the selection is often
>       better left to experts.
> 
>    is rather imprecise.  I would suggest something more concrete:
> 
> 	Explicit selection of concrete cryptographic algorithms
> 	should generally not be left to end-users.  Rather, end-users
> 	might select between configuration profiles defined by
> 	experts.

Your proposed rewording misses a point I am trying to make.  At first blush, people may think that their ability to pick any algorithm is a good thing.  This is rarely the case.

How aboutL

   It may seem as if the ability to use an algorithm of one's own
   choosing is very desirable; however, the selection is often better
   left to experts.  When there are choices, end-users might select
   between configuration profiles that have been defined by experts.

>    The next sentence is too confusing to suggest improvements:
> 
> 	  Further, any and all cryptographic algorithm choices
> 	  ought not be available in every implementation.

I have tried to make the point more clearly:

   Further, experts need not specify each and every cryptographic
   algorithm alternative.  Specifying all possible choices will not lead
   to them being available in every implementation.

>    The rest of the first paragraph:
> 
> 	s/that it has/that has/
> 	s/has alway had/has always had/

Done.

>    The last sentence of the same paragraph:
> 
> 	In addition, inclusion of too many alternatives may add
> 	complexity to algorithm selection or negotiation.
> 
>    might be better as:
> 
> 	Finally, standardization of too many alternatives will
> 	likely hamper security and interoperability.  When
> 	standardizing new algorithms it is prudent to consider what
> 	existing algorithms need to deprecated to make room for
> 	the new.
> 
>    [ For example, I'd like to see deprecation of many legacy DNSSEC
>      algorithm code points, once new code points appear based on
>      CRFG's new curves. (Of the existing algorithms, I'd keep only
>      RSASHA256(8) and ECDSAP256SHA256(13)). ]

I like what you are saying, but I do not want to loose the point about added complexity.

I suggest:

   In addition, inclusion of too many alternatives may
   add complexity to algorithm selection or negotiation.  Specification
   of  too many alternatives will likely hamper interoperability and may
   hamper security as well.  When specifying new algorithms or suites,
   protocol designers would be prudent to consider whether existing
   ones can be deprecated.

> Last paragraph of 3.1:
> 
> 	s/Sometime/Sometimes/
> 	s/depending of/depending on/

Done.

> Last paragraph of 3.4:
> 	
> 	s/roll out/roll-out/  (the first is the verb, the second the noun).

This is in section 3.3.  Corrected.

> Section 3.4:
> 
>    Amen for disabled by default "national" algorithms.  It would
>    be nice to explicitly see this recommendation for GOST in DNSSEC,
>    SEED in TLS, ...

That belongs in other documents.  Of course, the people that write those document want to see their national algorithm added to every implementation.

> Section 4:
> 
>       Sometimes application layer protocols can make use of transport layer
>       security protocols, such as TLS [RFC5246] or DTLS [RFC6347].  This
>       insulates the application layer protocol from the details of
>       cryptography, but it is likely to still be necessary to handle the
>       transition from unprotected traffic to protected traffic in the
>       application layer protocol.  In addition, the application layer
>       protocol may need to handle the downgrade from encrypted
>       communication to plaintext communication.
> 
>    What's the relevance of a possible transition from cleartext
>    to encryption (and perhaps back again???).

It is the security considerations, and this seems like a possible attack vector.

> Overall:
> 
>    I found the document to be too "hand-wavy".  I think that it
>    could be shorter by leaving out more text where no specific
>    recommendations are or can be made.
> 
>    The wording could use a lot more polish, my list of nits is
>    far from comprehensive.

Again, thanks for you thoughtful review.  You have made the document better.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Sep 2015 21:28:58 +0000

>    migrate from one algorithm suite to another over time.

Works for me.

> I'm not sure how to handle this comment.  I guess the point that I am
> trying to make is that there can be too many levels of indirection and
> still preserve the integrity of the first part of the negotiation.

    2.5.  Cryptographic Key Management

       Traditionally, protocol designers have avoided more than one approach
       to key management because it makes the security analysis of the
       overall protocol more difficult.  When frameworks such as EAP and
       GSSAPI are employed, the key management is very flexible, often
       hiding many of the details from the application.  This results in
       protocols that support multiple key management approaches.  In fact,
       the key management approach itself may be negotiable, which creates a
       design challenge to protect the negotiation of the key management
       approach before it is used to produce cryptographic keys.

       Protocols can negotiate a key management approach, derive an initial
       cryptographic key, and then authenticate the negotiation.  However,
       if the authentication fails, the only recourse is to start the
       negotiation over from the beginning.

       Some environments will restrict the key management approaches by
       policy.  Such policies tend to improve interoperability within a
       particular environment, but they cause problems for individuals that
       need to work in multiple incompatible environments.

Reading section 2.5 again, and being well versed in both TLS and
GSSAPI (I commit code to both OpenSSL and Heimdal), I still have
no idea what it is saying.  In what sense is "key management" (which
for me means how keys are deployed and rotated) "negotiated" in
the protocol.

Is this talking about "Key Exchange" rather than "Key Management"?
Is the problem you have in mind that when, for example, negotiating
"GSSAPI" in SASL one might not know what that entails before deciding
to use GSSAPI over some other SASL mechanism?

Whatever this section is trying to say, I'm just not smart enough
to figure it out, even with the hint in this response.

>    deprecated in order to preserve interoperability.

Works for me.

> The point is that big customers can help with the social part of the
> transition by putting pressure on their suppliers.  I'm not sure what part
> to change to make that more clear for you.

    s/rollover/transition/ and change the introductory clause:

    Dominant, or otherwise sufficiently large, market players can ...

>    balanced options being available at the time of deployment.

I do not think the greater length makes it clearer, perhaps the
original shorter version will do.

>    identifier MUST be negotiated, including key size and parameters.

Better, but of course negotiating the strength of long-term public
keys is generally not possible, the server can't choose these on
the fly.  So the MUST is perhaps too strong.  Rather, protocol
designs SHOULD try to avoid unilateral choices of cryptographic
parameters to the extent possible.  Thus we should encourage
specification of a small set of explicit sizes or set of explicit
groups, ... and then negotiate their use.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Sep 2015 21:34:51 +0000

On Wed, Sep 02, 2015 at 05:18:10PM -0400, Russ Housley wrote:

> How about:

Super.

>    to them being available in every implementation.

That's fine.

>    protocol designers would be prudent to consider whether existing

Fine.

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 3 Sep 2015 13:56:04 +0200

Hi Russ,

Just one comment:

>    deprecated in order to preserve interoperability.

Honestly this paragraph is confusing.  It's opaque because it's not
clear whether you're aiming at a strawman of where TLS doesn't support
agility or the case of long lived root or intermediate certificates.  If
it's the former, can you find a more current example?  And the last
sentence is just flat out ambiguous, although in an amusing sort of way
(who deprecates in order to preserve interoperability?).

I can't propose replacement text here because of the ambiguities...

Eliot

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Sep 2015 16:30:44 -0400

Eliot:

We are talking about section 2.6...

> (who deprecates in order to preserve interoperability?).

Kathleen also had a comment on this part of the document in her IESG ballot.

I'm trying to address both comments with this proposal:

2.6.  Preserving Interoperability

   Cryptographic algorithm deprecation is very difficult.  People do not
   like to introduce interoperability problems, even to preserve
   security.  As a result, flawed algorithms are supported for far too
   long.  The impact of legacy software and long support tails on
   security can be reduced by making it easy to transition from old
   algorithms and suites to new ones.  Social pressure is often needed
   to cause the transition to happen.

   Implementers have been reluctant to remove deprecated algorithms or
   suites from server software, and server administrators have been
   reluctant to diable them over concerns that some party will no longer
   have the ability to connect to their server.  Implementers and
   administrators want to improve security by using the best supported
   algorithms, but their actions are tempered by the desire to preserve
   connectivity.  Recently, some browser vendors have started to provide
   visual warnings when a deprecated algorithm or suite is used.  These
   visual warnings provide a new incentive to transition away from
   deprecated algorithms and suites.

   Institutions, being large or dominant users within a large user base,
   can assist by coordinating the demise of an algorithm suite, making
   the transition easier for their own users as well as others.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Thu, 3 Sep 2015 23:01:59 +0200

Much better.

Eliot

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Sep 2015 21:12:36 +0000

>    the transition easier for their own users as well as others.

Nit: I still find the "Institutions, being large ..." phrasing a
bit clumsy.  How about:

    Organizations that are dominant in the market or support a
    large fraction of the user base, can help to overcome inertia
    and hasten the deprecation of a weakened algorithm suite,
    thereby making the transition easier for their own users as
    well as others.

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Sep 2015 17:16:14 -0400

Viktor:

{ Dropping things where we have reached agreement. }

> to figure it out, even with the hint in this response.

Perhaps the section heading has been the problem all along.

Yes, the use of GSSAPI by SASL is another example.  In fact RFC 4422 makes the point:

   Note that the mechanism negotiation is not protected by the
   subsequent authentication exchange and hence is subject to downgrade
   attacks if not protected by other means.

Does "Cryptographic Key Establishment Techniques" work better for you?

How about this:

   Dominant players in a market, or others with a sufficiently large
   user base, can assist by coordinating the demise of an algorithm
   suite, making the transition easier for their own users as well as
   others.

> original shorter version will do.

This is the text that went to the IESG yesterday, so if this is working, let's keep it.

> groups, ... and then negotiate their use.

Stephen did not think the MUST was appropriate for a BCP.

The current wording is:

   has led to interoperability problems, and to avoid these problems in
   identifiers need to be negotiated, including key size and parameters.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Sep 2015 17:18:33 -0400

>    thereby making the transition easier for their own users as

I proposed a change to that in a subsequent message...

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Sep 2015 21:22:20 +0000

>    suite, making the transition easier for their own users as well as

How about "Organizations that have a large influence, can ..."

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Sep 2015 21:27:12 +0000

> How about "Organizations that have a large influence, can ..."

Perhaps, but the original above is I think good enough, the gains,
if any from the proposed replacement are marginal.  The new version
is much less clumsy than the original.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Sep 2015 21:30:26 +0000

> Perhaps, but the original above is I think good enough, the gains, if any from

I dislike the phrase "dominant players" given the history of anti-trust in this industry.

---

From: Nico Williams <[email-masked]>
Date: Thu, 3 Sep 2015 16:48:10 -0500

> for me means how keys are deployed and rotated) "negotiated" in

I think what this is referring to is that *applications* may not get a
great deal of visibility into what happens at negotiation time.

Of course, local policy can still be applied ex-application, so that's
not fatal.

Any time you have a lot of options and layered frameworks we get this
problem.  Even plain TLS has quite a few things to represent to an
application that wishes to impose some policy.

The simplest approach, IMO, is to have local policy ex-application, with
applications at most naming a local policy to apply.

> to figure it out, even with the hint in this response.

Because I've dealt (struggled) with this before, it's quite clear to me
what Russ intended to convey.  I agree that it's not necessarily clear
to others because the word "application" appears only once, in the first
paragraph.  So it can be made clearer.

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Thu, 3 Sep 2015 21:54:40 +0000

On  Thursday, September 3, 2015 2:30 PM, Rich Salz wrote:
> To: [email-masked]
> Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
> 

+1

You can use words like "large market share" or "large user base", which are factual. "Dominant" is an opinion with legal implications... And you probably don't want to advice big companies to "use your dominant position to bully smaller competitors!"

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Sep 2015 21:56:26 +0000

On Thu, Sep 03, 2015 at 05:16:14PM -0400, Russ Housley wrote:

> >       [...]

OK, so perhaps we're talking about negotiating "Key Establishment"
methods.  Or perhaps in fact "layered" security protocols where
the outer security protocol negotiates one of many inner security
protocols (opaque to the outer protocol) and the inner protocols
do the actual crypto.

In the SASL case when choosing between PLAIN, GSSAPI, EXTERNAL,
...  there may in fact be no integrity protection of the outer
negotiation and lack of transparency about the compative strengths
of the available alternatives.

Beyond repairing the heading (which is important), the content of
that section still needs work, because it should have been clear
what it means even with a misleading heading.

>    suite, making the transition easier for their own users as well as

[ Duplicate, yes good. ]

>    identifiers need to be negotiated, including key size and parameters.

Close enough I guess.  I hope protocol designers will make sensible
choices.  Thus, for example, in TLS I would not suggest different
suites for each of a small set of supported RSA modulus bit lengths.

On the other hand, in DNSSEC, I would in fact have been tempted to
nail down the modulus sizes as part of the algorithm id.  The good
news is that we get that with the EC algorithms for DNSSEC (one
algorithm id per-curve) and I expect that eventually the RSA
algorithms for DNSSEC will be deprecated (though it may take a
decade or more).

So the "right thing to do" here varies a bit by context.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 3 Sep 2015 17:18:56 -0500

Viktor asks me what the take-away from section 2.5 should be.  IMO it is
as follows.

Applications (app devs) and users are not in a good position to evaluate
cryptographic strength (and acceptability) of outcomes of protocol
negotiations, therefore this should be moved to local policy.  Local
policy includes defaults provided by implementors of security mechanisms
(TLS, Kerberos, etcetera).

This I-D, aiming to be a BCP, needs to outline a best practice as to
policy.  That best practice, IMO, is to give application developers and
users a very small control knob: a choice between named policies with
simple semantics.  "Strong", "normal", "opportunistic", "maximally
interoperable", "weak" -- these are both, good names and descriptions of
possible policies to apply; they are also good descriptors of outcomes.

Local policy should be expressible in some way, but it's OK if it's
hardcoded in implementations, as long as there are choices like the ones
I listed above, as those are the ones that applications and their users
need to apply.

It's OK -expected!- that the content of such policies will vary over
time because the relative strengths of cryptographic algorithms and
protocols vary over time as cryptanalysis improves.

Another take-away here is that implementors of security mechanisms and
frameworks really must provide interfaces by which to request a policy
to apply.  I.e., SASL, GSS, and others need a way for the application to
request a policy or check whether an outcome meets a given policy.  It's
not really enough to tell users to edit N configuration files,
especially if that makes it difficult to have more than one policy.

Now, local policy is NOT really part of a protocol.  So, this guidance
can't be for protocol designers.  It can be for framework API designers
(e.g., for us in KITTEN WG).  It can be for implementors of protocols
and frameworks.  That's OK, we can do that in a BCP.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Sep 2015 22:27:20 +0000

> Viktor asks me what the take-away from section 2.5 should be.  IMO it is

Furthermore, Viktor, continuing to "play dumb" in the third person,
still does not see how mere mortals might reach conclusions similar
to Nico's from the current text.  So much so, that he can well
imagine that the text might be trying to say something entirely
different.

So, whether Nico's reading is right, or wrong, please make the text
more clearly carry its intended meaning, along with some tangible
best-practice for protocol, library or application designers.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Sep 2015 19:34:44 -0400

> (TLS, Kerberos, etcetera).

I don't understand what this means. Should the curl developers let
sysadmins or distributions configure ciphersuites, or use the default
in OpenSSL? Should OpenSSL express the flexibility it now does with
regards to configuration? If we want to say something about these
questions, it should be clear.

> possible policies to apply; they are also good descriptors of outcomes.

Why should we deploy weak crypto knowingly? We know that transitions
away take years, and tend to start late.

> and frameworks.  That's OK, we can do that in a BCP.

Let's say I write protocol X. Protocol X uses TLS. I know a lot about
the domain that X deals with, but not the domain that TLS deals with.
Shouldn't this be enough to ensure security? And if it isn't, isn't
that a sign that we need a replacement that will be sufficient.

>
> Nico
> --
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 04 Sep 2015 09:41:27 -0400

One spelling nit:

>    reluctant to diable them over concerns that some party will no longer
--------------------^

This should be "disable", not "diable".

>    the transition easier for their own users as well as others.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Sep 2015 17:05:49 -0400

Fixed.  Thanks.

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Sep 2015 17:22:12 -0400

Nico and Viktor:

Late last week, you each made comments on Section 2.5.  I have tried to address them.  The text in my edit buffer is:

2.5.  Cryptographic Key Establishment

   Traditionally, protocol designers have avoided more than one approach
   to exchanges that establish cryptographic keys because it makes the
   security analysis of the overall protocol more difficult.  When
   frameworks such as EAP [RFC3748] and SASL [RFC4422] are employed, key
   establishment is very flexible, often hiding many of the details from
   the application.  This results in protocols that support multiple key
   establishment approaches.  In fact, the key establishment approach
   itself is negotiable, which creates a design challenge to protect the
   negotiation of the key establishment approach before it is used to
   produce cryptographic keys.

   Protocols can negotiate a key establishment approach, derive an
   initial cryptographic key, and then authenticate the negotiation.
   However, if the authentication fails, the only recourse is to start
   the negotiation over from the beginning.

   Some environments will restrict the key establishment approaches by
   policy.  Such policies tend to improve interoperability within a
   particular environment, but they cause problems for individuals that
   need to work in multiple incompatible environments.

I hope the change in terminology helps.  Let me know.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Sep 2015 21:41:28 +0000

> I hope the change in terminology helps.  Let me know.

The subject under discussion is now much more clear, this is I
think progress, thanks!  

The text might still use a bit more polish.  More importantly
though, is there an intended best-practice recommendation here?
Or if not, what is the intended purpose of this section?

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Sep 2015 17:49:17 -0400

> Or if not, what is the intended purpose of this section?

My intent is to give a heads up.  If there are too many layers, the application may not be able to do anything other than start the negotiation again.

Russ