Subject: [saag] AD sponsoring draft-iab-crypto-alg-agility

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 May 2015 22:59:33 +0100

Hiya,

Russ has been working this draft [1] for a while now,
has gotten good feedback along the road and has now
asked me if I'd AD sponsor it as a BCP that documents
some of what we want protocols to do in terms of
cryptographic algorithm agility and picking MTI
algorithms.

I think it'd be good to have such a BCP if we get IETF
consensus on the content, so all going well, I do plan
to start an IETF LC on this around the end of June (after
I do some vacating:-). That would mean we could take
some f2f time in Prague to discuss it if needed.

In the meantime, I'd appreciate it if folks on this
list could give some feedback on the draft. Of course
a detailed review is most welcome, but it'd also be
good to see expressions of support for it becoming a
BCP, or expressions of opposition to that, as the case
may be. (As always, saying why is much better than a
simple +1 or -1)

So please try to take the time to give this a read
in the next month and say what you think about it.
(Treat this as a kinda-sorta-WGLC-like thing I guess.)

Thanks,
Stephen.

[1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility

---

From: Martin Thomson <[email-masked]>
Date: Fri, 22 May 2015 16:02:55 -0700

> (Treat this as a kinda-sorta-WGLC-like thing I guess.)

A few comments.  I think that this needs a little more work.

   Cipher suites include Diffie-Hellman or RSA without specifying a
   particular public key length.

This is unnecessarily specific.  While we often choose primitives that
are coupled to a particular strength (e.g. AES-GCM with 128-bit keys
and authentication tags is common, but those aren't the only options),
some algorithms permit flexibility in their strength, including the
number of rounds, key sizes, authentication tags, prime group size,
etc...

The section (2.4) that this appears in addresses matching relative
strengths of primitives in a suite: not using 16384-bit DH to protect
a triple-DES symmetric key, for instance.

That suggests that this is two sections:
 1. pick sizes, or provide a way to negotiate sizes (and in
negotiating, be sure to avoid the downgrades of S2.3)
 2. pick sizes that are roughly comparable strength

And here we come to the "unless" part.  Protocols have very different
things riding on the different keys.  Authentication primitives
(signing, authentication tags, MAC) could require real-time attacks to
be exploited in some contexts, like the authentication tag in TLS.  Or
at least attackers are constrained in time (breaking a certificate key
after the certificate expired is of significantly less value to an
attacker).  On the other hand, breaks in symmetric crypto or key
exchange for something like TLS have significant value to an attacker
in recovering plaintext on recorded sessions.

I think that this level of nuance isn't necessary to capture, but
acknowledging that this is at least a little bit more complicated
would be good.

In S2.5, this is a bit of a non-sequitur without context: "While RSA
with a 2048-bit public key is quite a bit stronger than SHA-1".  The
point is that these are widely deployed and available, even if one is
not considered adequately strong.  The point that the RSA is "strong
enough" might not be so obvious to a future audience.

The note in Section 3.2 on Performance belongs elsewhere.  Likely in
the section on strength (or two sections if you take my suggestion).

Section 3.3 could be expanded to emphasize the social aspects of this.
This is largely a social problem, and a difficult one: for browsers,
we don't want to break sites because we lose users by doing so, that
creates incentives to stay busted, but interoperable. We've found in
browser-land that coordinating response can be highly effective at
reducing defection.

Section 4.1 neglects to mention the obvious benefit in selecting
something that lots of other people are using too.  That's a
non-trivial advantage over and above the reasons cited (though many of
them might be considered different ways of saying the same thing).

I find Section 4.6 baffling.  We have words that we can use for these
things.  They are MUST NOT, MUST and SHOULD.  None of these attempt to
presage the future.  But generating new conventions for what might or
might not happen in the future is much harder than waiting and just
making the change when the time comes.

For instance, if TLS 1.3 doesn't mandate use of 25519, we could use
SHOULD+.  OR, we can say SHOULD and then write a new document that
upgrades 25519 to MUST when we decide that's a good time.  It stands
as much chance of being ignored as a SHOULD+, of course, but it
doesn't have the problems with predicting the future that SHOULD+
invokes.

---

From: ianG <[email-masked]>
Date: Sat, 23 May 2015 18:34:43 +0100

> [1] https://tools.ietf.org/html/draft-iab-crypto-alg-agility

My thoughts on 4.3.

1. The content is not easy to endorse.  Clearly it is written from a 
stalwart position of "bad idea" without actually getting into the logic 
and accepting that there is a place and time for this approach.

Indeed if the entire document were written to accept that in some 
circumstances there is merit in 1TCS then consensus might be easier.  I 
for one don't approve of the document.

Perversely, I'm fine with the title :)  although I'd prefer the more 
canonical version of *One True Cipher Suite considered harmful* .  It is 
of course an irony and an honour!

2. 4.3/1 First para "It is much better..." just assumes that the only 
mistakes that occur are in the algorithm choice.  Statistically it is 
the other way around, most mistakes are in the protocol, in which case 
the protocol itself must be transitioned.  In which case we have only a 
nominal or occasional stress on needing to transition just an algorithm.

Section 2.3 / para 3 agrees, by saying "Sadly, this has happened..."

3.  second para, same criticism.  It would be very nice for someone to 
actually surface a list of when algorithms have been catastrophically 
broken, versus a list of similar breaks with protocols.  I know I say it 
doesn't happen very much, but it's not as if anyone has sat down and 
worked it out.  This might be a good masters thesis for someone?

4.  3th para.  WEP.  So, this is an example, as grumbled above.  But was 
RC4 broken?  Or was the protocol broken?  In practice it was due to the 
small key, small IV.

Would a choice of algorithms have saved anyone?  I reckon not, for two 
reasons.  Firstly, the product was designed to be weak, and the weakness 
would have just carried across.  Like, DES with 40 bit keys instead of 
RC4, etc.  Secondly, the market for these devices was never really set 
up for any sort of widescale upgrade of the parameters, so regardless of 
any claim that "RC4 broken, must switch" few would likely have done it.

In practice, the OODA loop for switching an algorithm would likely be 
the same as upgrading all the hardware by buying new kit.  So don't bother?

Indeed if we were to add algorithm agility to WiFi, imagine the chaos in 
user-land.  WiFi is already a big tricky because nobody out there knows 
what the choices mean, so they rely on defaults to get it right.

What I'm saying here is that the case for switching the algorithm in 
WiFi is particularly murky, and is no sense related to the science of 
protocols.

5.  4th para -- SHA-1 to SHA-256 over 5 years.  Probably true.  And in 
the interim it was far more important to upgrade through the TLS 
versions, so why later generations were still using SHA-1 remains a mystery.

The first failure remediation in TLS that I measured took about 3.5 
years, and that's when they were trying real hard.  It was a protocol 
breach of course, not an algorithm break.

Discussion also applies to algorithmic agility as well.

The whale that is missing from the whole document is how to implement a 
switch.  Without this, advice for algorithmic agility is negligent - 
IETF is encouraging people to use a protocol design pattern without any 
clear or plausible manual in how to enjoy the fruits of that method.

Section 2.3 hints at this but provides no meat.   this:

      "Protocols MUST facilitate the selection to
      the best algorithm or suite..."

is not as helpful because (a) the selection protocol itself is hard 
coded with this algorithm, so can't be switched without upgrade, and (b) 
it assumes a definition of "best" which either requires external 
instructions (a cipher negotiation list) or it just puts the point on 
the fact that the only experts of any credibility here are the original 
protocol designers.  A point which is made in sections 2.4, 4.1!

Section 3.2 ditto.  Section 4.2 agrees with

      "the manner by which system administrators
      are advised to switch algorithms or suites is
      at best ad hoc, and at worst entirely absent."

There is begrudging acceptance that upgrading the entire protocol 
version number is one way to upgrade the cipher suite.

4.6 might be the only new contribution as to how to move forward on 
algorithms.

iang

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 May 2015 07:01:02 +0000

ianG <[email-masked]> writes:

>4.  3th para.  WEP.  So, this is an example, as grumbled above.  But was RC4
>broken?  Or was the protocol broken?  In practice it was due to the small key,
>small IV.

Apart from an initial comment on the draft I've tried to avoid getting
involved in a debate over this since I think the issue is at least as much (if
not more) religious than technical.  For example I can use Russ' WEP example
to argue exactly the opposite of the point he's trying to make: The problem
with WEP wasn't a 1TCS one, it was that it was designed by non-cryptographers,
and was badly broken. If they'd gone with four cipher suites instead of one,
we'd just have four badly broken ones instead of one, or, worse, three badly
broken ones and one not-quite-as-broken one so they could tell everyone to use
the not-quite-as-bad one.

>switch.

Yup.  Or, better, the option "choose a good 1TCS and go with it".  Nearly 20
years ago when I did my SSL implementation, I chose as default RSA + 3DES +
SHA1 (RSA dictated by the fact that at that time servers were relatively
powerful and clients weren't, and RSA's asymmetry helped).  If I'd implemented
nothing else, I'd still be about as secure today as I would with any more
modern suite (various side-channel attacks, the EtM issue, and others are
separate issues since they affect all cipher suites, not just that one, so
you're in trouble no matter what suite you select).

As PHB has pointed out in a thread on the OpenPGP list, the problems we're
seeing, over and over again, last week's toy-crypto DH being only the most
recent example, is caused by too many cipher suites, not too few.  If there'd
been 1TCS from 20 years ago, and nothing else (and excluding as I've already
said general protocol attacks that affect any suite), a lot of the stuff
that's hit us in the last decade or so wouldn't have happened.  Again quoting
PHB, the problem isn't the strongest suite/algorithm that's available, it's
the weakest, and we've got plenty of those all over the place.  

So choose a strong 1TCS as a MUST and as a backup an equally strong one as a
SHOULD, not because the 1TCS will ever fail suddenly but because it's going to
be politically almost impossible to get just 1TCS through.  The whale can be
safely ignored because there'll never be any need to switch from the 1TCS,
it'll be there mostly to deal with strongly-held religious beliefs.

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 24 May 2015 08:12:41 -0400

> cryptographic algorithm agility and picking MTI

But this is not what we actually want to do. It's not a question of
getting good algorithms deployed, but removing bad ones, and not a
question of algorithm failures, but protocol failures. Protocol
failures are made worse by adding negotiation mechanisms. As Peter
notes downthread, 1TCS is a perfectly fine approach if you anticipate
potentially having to fix the protocol. I'd go further: versioning is
the best approach.

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

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 May 2015 12:50:34 -0400

> the not-quite-as-bad one.

I see the history a bit differently.  The original WEP had a 40-bit key, and no one looked at the protocol because the security was obviously weak.  When the key size was increased to 128-bits, then people looked at the protocol and saw all of the major mistakes.  It is hard to believe that so many mistakes can be made in one protocol.

The fact that the protocol was so tightly integrated with the 1TCS made it very difficult to insert a secure algorithm.  The vendors wanted a backward compatible solution, and that made it even harder.

> it'll be there mostly to deal with strongly-held religious beliefs.

I am not sure that there is a need in all situations.

In PGP and S/MIME, for example, small parts of the user based can migrate at different times.  There are many small groups with little overlap, so they can almost transition independently.

In DNSSEC and RPKI, algorithms are used globally.  RFC 6916 offers an approach to algorithm migration in the RPKI.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 May 2015 12:06:36 -0400

> number of rounds, key sizes, authentication tags, prime group size,

The point of this paragraph is about the pro and con of including key size in the identifier.  However, you are right that it could apply to other attributes as well.

I suggest:

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, cipher suites include Diffie-Hellman or RSA without specifying a particular public key length.  

> acknowledging that this is at least a little bit more complicated

Good observation.

I suggest:

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 in 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, it is not often available to system administrators that are deploying and configuring 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 and configuration.

> enough" might not be so obvious to a future audience.

You are right.

I suggest:

Despite the guidance in Section 2.4, opportunistic security [RFC7435] SHOULD also be considered, especially at the time a protocol implementation is deployed and configured.  Using algorithms that are weak against advanced attackers but sufficient against others is a way to make pervasive surveillance significantly more difficult.  As a result, algorithms that would not be acceptable in many negotiated situations are acceptable for opportunistic security.  Similarly, shorter key sizes are also acceptable for opportunistic security.  That said, the use of strong algorithms is always preferable.

> the section on strength (or two sections if you take my suggestion).

I'm not sure how to handle this one yet.  Eliot suggested some other reorganization, and I'll consider this as well.

> browser-land that coordinating response can be highly effective at

Thanks for this.

I suggest adding another paragraph:

In many ways preserving interoperability is a difficult social problem.  For example, consider web browsers.  Dropping support for an algorithm suite can break connectivity to some web sites because, and the browser will lose users by doing so.  This situation creates incentives to support algorithm suites that would otherwise be deprecated, but preserving interoperability.  Coordinating the demise of an algorithm suite is an important aspect of the answer to this social problem.

> them might be considered different ways of saying the same thing).

Yes, I think this point comes through in many ways in the document, but you are right, it should be explicit.

I suggest adding this sentence to the middle of the first paragraph:

There are significant benefits in selecting algorithms and suites that are widely deployed.

> making the change when the time comes.

This idea is not new.  It was first used with IKEv1 when Jeff Schiller was SEC AD.  The idea is to give product planners a heads up.

> doesn't have the problems with predicting the future that SHOULD+

I think you grasp the idea.

Russ

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2015 09:14:34 -0700

> I think you grasp the idea.

Likewise.  Thanks.

Your proposed changes look good.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 May 2015 18:15:14 +0000

> > involved in a debate over this since I think the issue is at least as
> > much (if not more) religious than technical.  For example I can use
> > Russ' WEP example to argue exactly the opposite of the point he's
> > trying to make: The problem with WEP wasn't a 1TCS one, it was that it
> > was designed by non-cryptographers, and was badly broken. If they'd
> > gone with four cipher suites instead of one, we'd just have four badly
> > broken ones instead of one, or, worse, three badly broken ones and one
> > not-quite-as-broken one so they could tell everyone to use the not-quite-as-
> bad one.
> 
> I see the history a bit differently.  The original WEP had a 40-bit key, and no one
> looked at the protocol because the security was obviously weak.  When the key
> size was increased to 128-bits, then people looked at the protocol and saw all of
> the major mistakes.  It is hard to believe that so many mistakes can be made in
> one protocol.

WEP is certainly one of the worse examples out there. The initial key length was ridiculous, the initialization vector was used incorrectly, the linear CRC did not protect the data integrity, etc. It seems like a textbook example against having just one cipher. But at the same time, WEP issues could not be fixed by just changing the underlying encryption algorithm. The fixes required changing the whole protocol, which is actually an example of versioning.

The other "bad example" of security design is of course the use of A5 in GSM. This one provides an interesting view on key and algorithm negotiation. The standard was deliberately compromised to enable mass surveillance. That was probably also the reason for choosing a 40 bit key in WEP. Which brings an interesting question. Consider the process used to set IETF standards. In that context, is the "single suite" design easier to sabotage than a "multiple choice" design? 

-- Christian Huitema

---

From: ianG <[email-masked]>
Date: Tue, 26 May 2015 21:07:01 +0100

> WEP is certainly one of the worse examples out there. The initial key length was ridiculous, the initialization vector was used incorrectly, the linear CRC did not protect the data integrity, etc.…

"But at the same time..." :)

> The other "bad example" of security design is of course the use of A5 in GSM. This one provides an interesting view on key and algorithm negotiation. The standard was deliberately compromised to enable mass surveillance.

It was deliberately compromised, yes.  The MiB were in the design room.

However, it is important to remember our security modelling.  GSM crypto 
was designed to protect against two things:  paparazzi and billing 
fraud.  It did those very well.  It was never designed to protect 
against national security agencies, and didn't need to, given that the 
GSM protocol was only secure on air.  Both the European agencies and 
every other agency could easily hack in and listen in the clear.

> That was probably also the reason for choosing a 40 bit key in WEP. Which brings an interesting question. Consider the process used to set IETF standards. In that context, is the "single suite" design easier to sabotage than a "multiple choice" design?

(This is what I call the "special interests" attack.)

iang

---

From: Russ Housley <[email-masked]>
Date: Tue, 26 May 2015 16:24:18 -0400

Ian:

> My thoughts on 4.3.
> 
> 1. The content is not easy to endorse.  Clearly it is written from a stalwart position of "bad idea" without actually getting into the logic and accepting that there is a place and time for this approach.
> 
> Indeed if the entire document were written to accept that in some circumstances there is merit in 1TCS then consensus might be easier.  I for one don't approve of the document.
> 
> Perversely, I'm fine with the title :)  although I'd prefer the more canonical version of *One True Cipher Suite considered harmful* .  It is of course an irony and an honour!

Even when 1TCS is chosen, the protocol design needs to accommodate a change.  As I said in my response to Peter, the designer needs to think about transition, and protocol details should not be too tightly bound to the details of the first selection of the iTCS.  To make this more clear, I have update the WEP discussion:

The first IEEE 802.11 [WiFi] specification included the Wired Equivalent Privacy (WEP) as the only encryption technique.  Many of the protocol details were driven by the selected algorithm.  WEP was found to be quite weak [WEP], and a very large effort was needed to specify, implement, and deploy the alternative encryption techniques.  This effort was made even harder by the protocol design choices that were tied to the initial algorithm selection and the desire for backward compatibility.

> 2. 4.3/1 First para "It is much better..." just assumes that the only mistakes that occur are in the algorithm choice.  Statistically it is the other way around, most mistakes are in the protocol, in which case the protocol itself must be transitioned.  In which case we have only a nominal or occasional stress on needing to transition just an algorithm.
> 

You are right that many problems come from the protocol itself.  That is not the point of this section.  I think that comes out in Section 2.3 and in the mac-then-encrypt discussion elsewhere in the document.

> 3.  second para, same criticism.  It would be very nice for someone to actually surface a list of when algorithms have been catastrophically broken, versus a list of similar breaks with protocols.  I know I say it doesn't happen very much, but it's not as if anyone has sat down and worked it out.  This might be a good masters thesis for someone?

I agree, but I'm nor sure how that helps me improve the document.

> 4.  3th para.  WEP.  So, this is an example, as grumbled above.  But was RC4 broken?  Or was the protocol broken?  In practice it was due to the small key, small IV.

It was a whole bunch of things, I already sent a message in response to Peter on this topic.
> 
> Would a choice of algorithms have saved anyone?  I reckon not, for two reasons.  Firstly, the product was designed to be weak, and the weakness would have just carried across.  Like, DES with 40 bit keys instead of RC4, etc.  Secondly, the market for these devices was never really set up for any sort of widescale upgrade of the parameters, so regardless of any claim that "RC4 broken, must switch" few would likely have done it.
> 
> In practice, the OODA loop for switching an algorithm would likely be the same as upgrading all the hardware by buying new kit.  So don't bother?
> 
> Indeed if we were to add algorithm agility to WiFi, imagine the chaos in user-land.  WiFi is already a big tricky because nobody out there knows what the choices mean, so they rely on defaults to get it right.
> 
> What I'm saying here is that the case for switching the algorithm in WiFi is particularly murky, and is no sense related to the science of protocols.

I hope you agree that the text suggested above is an improvement.  Can it be made even better?

> 5.  4th para -- SHA-1 to SHA-256 over 5 years.  Probably true.  And in the interim it was far more important to upgrade through the TLS versions, so why later generations were still using SHA-1 remains a mystery.
> 
> The first failure remediation in TLS that I measured took about 3.5 years, and that's when they were trying real hard.  It was a protocol breach of course, not an algorithm break.
> 

The platform needed to add support for SHA-256 before the applications could use it.  That made it even harder, and I think that situation will be repeated in the future.

> The whale that is missing from the whole document is how to implement a switch.  Without this, advice for algorithmic agility is negligent - IETF is encouraging people to use a protocol design pattern without any clear or plausible manual in how to enjoy the fruits of that method.

As I said in my reply to Peter:

> is not as helpful because (a) the selection protocol itself is hard coded with this algorithm, so can't be switched without upgrade, and (b) it assumes a definition of "best" which either requires external instructions (a cipher negotiation list) or it just puts the point on the fact that the only experts of any credibility here are the original protocol designers.  A point which is made in sections 2.4, 4.1!

Do you think this works better?

Algorithm transition is naturally facilitated as part of an algorithm selection or negotiation mechanism.  Protocols traditionally select the best algorithm or suite that is supported by all communicating peers and acceptable by their policies.  In addition, a mechanism is needed to determine whether the new algorithm has been deployed.  For example, SMIMECapabilities [RFC5751] allows S/MIME mail user agents to share the list of algorithms that they are willing to use in preference order.  For another example, the DNSSEC EDNS0 option [RFC6975] measures the acceptance and use of new digital signing algorithms.

> There is begrudging acceptance that upgrading the entire protocol version number is one way to upgrade the cipher suite.

I certainly do not agree with your conclusion.  We have seen a transition from DES to Triple-DES to AES in S/MIME without a need for version changes.

> 4.6 might be the only new contribution as to how to move forward on algorithms.

It is not new.  See RFC 4307.

Russ

---

From: ianG <[email-masked]>
Date: Fri, 29 May 2015 19:02:14 +0100

Section 3.3 said this:

    3.3.  Preserving Interoperability

    Cryptographic algorithm deprecation is very hard.  People do not like
    to introduce interoperability problems, even to preserve security.
    As a result, flawed algorithms are supported for far too long.  The
    impacts of legacy software an long support tails on security can be
    reduced by making it easy to develop, deploy, and configure new
    algorithms.

Suggest changing last two lines to this:

    ...
    reduced by making it easy to rollover old suites to new suites.

Elsewise, the text would be to suggest that "adding new algorithms" is 
the solution when actually it's part of the problem.

>> browser-land that coordinating response can be highly effective at

+1 reduction of the consequences of over-agility is what we are trying 
to achieve, and what this document can primarily help with.

> In many ways preserving interoperability is a difficult social problem.  For example, consider web browsers.  Dropping support for an algorithm suite can break connectivity to some web sites becaus…

Yep, that's good.

I don't like the "social problem" part.  While this may sound good to 
our ears, it gives the impression that the users are the problem, when 
in fact they are simply responding to the hand we dealt them.  I.e., we 
created the protocol, and we created it in a way that it isn't easy to 
deprecate old stuff.  Now we're blaming them for acting precisely how 
the protocol channels them.

How about this:

      Without clear mechanisms for rollover, preserving
      interoperability becomes a difficult social problem.
      For example, consider web browsers....but preserving
      interoperability.

      Institutions, being large or dominating users within
      a large user base, may find that coordinating the demise
      of an algorithm suite is an important method to minimise
      the trauma of rollover to the users.

Notes. 1. I'm using the term "institution" in its economic sense, which 
is natural for me, but may be weird to others.  I'm not sure what term 
would be comfortable here, but recall NIST is another institution (other 
than the browsers) that has coordinated demise in this fashion.

2.  Then, it would be grand if we could also expand on ways in which the 
designer / WG / IANA / IETF could help by coordinating.  But that's 
beyond my ken to write.

> There are significant benefits in selecting algorithms and suites that are widely deployed.

OK.  But I think the document would gain utility if it where to have a 
section like "x. Strategies to assist migration" with that comment, and 
above "social problem" solution in it.

Also this:

>> I find Section 4.6 baffling.

The para is disjoint.  It starts out with a discussion of what might 
happen, without clear point (to me).

Then switches dramatically to how to transition.  I suspect the 'bits' 
discussion belongs elsewhere.

Then, the meat:

    Where possible, authors SHOULD provide
    notice to implementers about expected algorithm transitions.  One
    approach is to use SHOULD+, SHOULD-, and MUST- in the specification
    of algorithms.

    ...

seems happy stand-alone, following on from the title.

>> We have words that we can use for these

So, could this be introduced with that explanation?  Something like:

    Where possible, authors SHOULD provide
    notice to implementers about expected algorithm transitions.

    IKEv1 introduced a mechanism to provide notice which this ID adopts
    [REF].  This approach uses additional hints SHOULD+, SHOULD-,
    and MUST- in the specification of algorithms.

         SHOULD+...
         SHOULD-...
         MUST-...

iang

---

From: ianG <[email-masked]>
Date: Sat, 30 May 2015 14:44:52 +0100

> In DNSSEC and RPKI, algorithms are used globally.  RFC 6916 offers an approach to algorithm migration in the RPKI.

If such is the case, then could this present draft borrow that approach 
and repeat it?  Just to repeat, this draft delivers better value to the 
extent that the full life cycle is made apparent to the engineer.

> Algorithm transition is naturally facilitated as part of an algorithm selection or negotiation mechanism.  Protocols traditionally select the best algorithm or suite that is supported by all communicating peers and acceptable by their policies.

Yes, that works better (within the context).

> It is not new.  See RFC 4307.

I'd suggest referencing it then, see other post.

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 31 May 2015 10:22:17 -0400

Comments

Section 2.2

" Note that this is not done for protocols that are embedded in
   other protocols, where the system-level protocol specification
   identifies the mandatory-to-implement algorithm or suite."

I would rather this is called out as a named exception, 'Specifications
that provide a platform' or some such.

The reason for this is that I have sat through many unproductive hours of
argument over what should be MTI in what is obviously a platform spec.
Having RSA-SHA1 be MTI in XML Signature only hurts.

As written, the language uses 'protocol' which is too narrow. Only some
IETF specs are protocols.

"To achieve this
   goal, the base protocol specification includes a reference to a
   companion algorithms document, allowing the update of one document
   without necessarily requiring an update to the other.  "

I would prefer it if the 'companion document' can be shared across specs.
As a practical matter, a mail client has to use TLS these days. Ergo the
intersection of the cipher suites supported by TLS, OpenPGP and S/MIME
should be non-zero and be MTI for the 'email' domain.