Hi Michael, On 11/4/12 10:46 AM, "Michael Richardson" <[email protected]> wrote:
> >What in practice, for an implementer and/or his marketing manager, is >the difference between "MAY" for algorithm and not listing it at all? > >I would understand if we had "MAY+", but really, that is what "SHOULD" >means. > >Could there implications on UIs, such that things listed SHOULD/MUST >are listed in the first page, things listed MAY are on the "Advanced >options" page, and whatever country-specific vanity ciphers that might >get included are under some even more obscure button. > >Or is the intent of MAY to give a clue to cryptoanalysis people as to what >things to focus on? Or for people GREP'ing the RFC archives as a result >of an attack will come up with IPsec as a user/ For what it's worth, RFC 4835 has two MAYs, NULL authentication and HMAC-MD5-96. My thinking was that it makes sense for the document to mention the algorithm options that had been defined at the time of writing, so the reader isn't left wondering. There are other ways that this could be dealt with other ways, though. For instance, we could remove the MAYs from the tables in Sections 2.2 and 2.3, and then add a new section that says something like "The following algorithms were considered and it was determined that there was no need for recommendation to implement, or not to implement." Someone mentioned in the WG meeting that algorithms that were previously SHOULDs, but have been deprecated to MAYs, should be included in the tables going forward, so that the reader doesn't wonder where it went. This seems like a good point to me. AES-CTR is the one algorithm in that category in the draft so far. Thanks, David > >-- >Michael Richardson >-on the road- > > >_______________________________________________ >IPsec mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
