Subject: [saag] Additions to RFC 3631?

From: Steven Bellovin <[email-masked]>
Date: Fri, 18 May 2012 22:31:39 -0400

Does anyone have any suggestions for additions or corrections to RFC 3631?
It looks to me like it's held up pretty well, save for newer versions of
some of the protocols.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Mouse <[email-masked]>
Date: Fri, 18 May 2012 23:31:58 -0400 (EDT)

> Does anyone have any suggestions for additions or corrections to RFC

Yes.  I, at least, do.

> 2.2.  A Word about Mandatory Mechanisms

>    We have evolved in the IETF the notion of "mandatory to implement"
>    mechanisms.  [...blather about interoperability...]

>    It is important to understand that mandatory mechanisms are mandatory
>    to *implement*.  [...]

>                                              Particularly with security
>    mechanisms, just because a mechanism is mandatory to implement does
>    not imply that it should be the default mechanism or that it may not
>    be disabled by configuration.  If a mandatory to implement algorithm
>    is old and weak, it is better to disable it when a stronger algorithm
>    is available.

If the point of a mandatory-to-implement mechanism is interoperability,
allowing it to be disabled is a bad idea; it has pretty much the same
effect on interoperability as not having it there in the first place:
peers cannot count on its availability when speaking with peers they
have no particular knowledge of.

> 3.1.  One-Time Passwords

>    One-time password schemes, such as that described in [RFC2289], are
>    very much stronger than conventional passwords.  The host need not
>    store a copy of the user's password,

This is true of only some OTP schemes (and those schemes are the weaker
for it; any algorithmic relation between the passwords at all is a
potential point of attack).  Other OTP schemes require the host to
store the user's password to exactly the same extent that reusable
password schemes require the host to store their passwords.

>    nor is it ever transmitted over the network.

Again, this depends on the OTP scheme; indeed, most OTP schemes I am
aware of do indeed transmit the passwords used for authentication.

If this discussion is really supposed to be restricted to RFC2289
designs, the punctuation in the introductory sentence is misleading; as
quoted above, it says it's talking about OTP schemes in general, with
RFC2289-style schemes cited as an illustrative example, not as a
restrictive narrowing of the set of schemes being described.

> 3.3.  IPsec

>    The key management for IPsec can use either certificates or shared
>    secrets.  For all the obvious reasons, certificates are preferred;
>    however, they may present more of a headache for the system manager.

The statement that certificates "are preferred" is either false or
incomplete, because certs are preferred only for certain classes of
uses.  For others, a shared secret is better - different uses,
different tradeoffs.

> 3.4.  TLS

>                                                     It's an unfortunate
>    reality that even server side authentication it not as secure in
>    practice as the cryptography would imply because most implementations
>    allow users to ignore authentication failures [...]

If you want to cite "unfortunate realit[ies]", how about the one that
it really is not all that difficult to get a cert for someone else's
domain?  I recall, for example, hearing about the number of certs for
microsoft.com that had been issued to entities having nothing to do
with Microsoft.

> 3.8.  Security/Multipart

>    Security/Multiparts [RFC1847] are the preferred mechanism for
>    protecting email.

Again, asserting that a particular alternative is preferred is either
false or incomplete.  I, for example, have various reasons for
preferring other tools for securing email in many cases.

>    The Digital Signature Standard [DSS] and RSA [RSA] are both good
>    choices; each has its advantages.  [...]
>        [...].  DSS has much better performance than RSA for generating
>    new private keys,

This runs counter to my experience with them within the context of ssh,
for what little that may be worth.

> 4.1.  Plaintext Passwords

>    Plaintext passwords are the most common security mechanism in use
>    today.  Unfortunately, they are also the weakest.  When not protected
>    by an encryption layer, they are completely unacceptable.

Again, this is either false or incomplete.  There is a system I have
been using since early 1992, and co-adminning since late 1992, that
routinely uses reusable plaintext passwords over unsecured TCP
connections over the open Internet (indeed, I don't think we have any
other authentication mechanism available).  For our purposes, that's
entirely suitable, and I don't think it is for the IETF to tell us
otherwise.

Perhaps 3631 is writing strictly from the perspective of security
mechanisms in new protocols being considered for IETF approval; my
comments on 3.3, 3.8, and 4.1 do not apply then, but in that case I
think the introductory text needs to be a good deal clearer.  It's
titled "Security Mechanisms for the Internet", not "Security Mechanisms
for New IETF Protocols", after all.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 May 2012 08:32:46 +0200

> It looks to me like it's held up pretty well, save for newer versions of

I think channel bindings ought to be discussed, as a simple way to bind
different layers together to avoid certain attacks.  It could be
discussed in the SASL or GSS-API section.  Further, I think EAP as a
protocol should be included in the list of standard security mechanisms.

/Simon

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 May 2012 10:20:04 +0300

And a short section on crypto-grade random number generation. I would be 
glad to contribute it.

	Yaron

On 05/21/2012 09:32 AM, Simon Josefsson wrote:
> Steven Bellovin<[email-masked]>  writes:
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 May 2012 10:26:52 +0200

Hi Mouse,

> have no particular knowledge of.

How would you propose to handle the situation where an MTI algorithm is
found to be vulnerable?  Isn't it the operator's choice between running
vulnerable code and turning off MTI (yes, there is middle ground but
it's wildly complex)?

Eliot

---

From: Mouse <[email-masked]>
Date: Mon, 21 May 2012 05:52:41 -0400 (EDT)

>> If the point of a mandatory-to-implement mechanism is
>> interoperability, allowing it to be disabled is a bad idea; it has
>> pretty much the same effect on interoperability as not having it
>> there in the first place: peers cannot count on its availability
>> when speaking with peers they have no particular knowledge of.
> How would you propose to handle the situation where an MTI algorithm
> is found to be vulnerable?

Disable it.

That is to say, I would scrap the mandatory-to-implement part, not the
allow-disabling part.  Besides, after technology has marched on for
five - or ten, or twenty - years, today's best is likely to look
utterly ludicrous.  Time was, crypt(1) - a one-rotor Enigma machine,
basically - actually provided a useful level of security.  Today, it's
what Schneier calls `kid sister' crypto, at best.  Mandatory-to-offer
algorithms lead to forcing people to choose between ignoring the spec
and running grossly insecure algorithms, while allowing disabling of
mandatory-to-implement algorithms breaks most of the point of
mandatory-to-implement.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 May 2012 12:07:04 +0200

Yaron Sheffer <[email-masked]> writes:

> And a short section on crypto-grade random number generation. I would
> be glad to contribute it.

I believe that is more for an update of RFC 1750 than RFC 3631.

RFC 1750 is in need for an update with modern recommendations.  It
should point to at least AES, Yarrow and the approved NIST RNGs.  The
references of weak ciphers (DES, MD4, etc) should be removed.  Given
that RFC 1750 is often cited by crypto protocol specifications, it would
be nice if RFC 1750 could be (more) useful to implementers.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 May 2012 11:15:54 +0100

> be nice if RFC 1750 could be (more) useful to implementers.

RFC 1750 was obsoleted by RFC 4086 in 2005. That's still a while
back so maybe improvements to that could be made,

Cheers,
S

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 May 2012 14:28:17 +0300

Whether or not RFC 4086 is in need of an update (and I agree it is), 
randomness is important enough as a security mechanism, and often enough 
forgotten, to be worth a section in 3631bis.

Thanks,
	Yaron

On 05/21/2012 01:15 PM, Stephen Farrell wrote:
>> Yaron Sheffer<[email-masked]>  writes:
>>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 May 2012 14:53:31 +0200

> mandatory-to-implement algorithms breaks most of the point of

Thanks for this explanation.  I wonder if there is a more nuanced way in
which this could be handled.  For instance, would it be possible for the
IETF to keep a simple list of algorithms in order of preference, and
deal with algorithm agility in that way?  This presupposes that there is
some uniformity in application requirements, or at least classes of
applications that can be grouped...

Eliot

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 21 May 2012 10:01:19 -0400

As noted by others, RFC 4086 covers that.  It may also need improving; I haven't reread it recently.  However, even a pointer to it is out of place in 3631bis.  3631 is about protocol mechanisms; 4086 is about implementations.  Mouse Mouse's suggestions are more in the domain of 3365, which is security design philosophy.  3631 says "if you want to put security into a protocol, here are the best choices we have today".  My question is whether or not that list should be changed.

On May 21, 2012, at 3:20 04AM, Yaron Sheffer wrote:

> And a short section on crypto-grade random number generation. I would be glad to contribute it.
> 
> 	Yaron
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 May 2012 12:42:39 -0400

+1 to adding EAP as a mechanism.

+/-0 to adding channel bindings, given how few people understand them.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Mon, 21 May 2012 12:06:49 -0500

> +/-0 to adding channel bindings, given how few people understand them.

EIther it's important/useful or not.  If it is then having some text
in this RFC would help those people who don't understand CB.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 May 2012 10:14:47 -0700

On 5/21/2012 10:06 AM, Nico Williams wrote:
> On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman<[email-masked]>  wrote:

I'd add it - in fact, I would add both BTNS and TCP-AO, since neither 
are covered and both serve different purposes than the mechanisms listed.

I also feel that Sec 2.4 should be expanded to explain in more detail 
how different levels of protection are used.

Joe

---

From: Nico Williams <[email-masked]>
Date: Mon, 21 May 2012 12:20:22 -0500

On Mon, May 21, 2012 at 12:14 PM, Joe Touch <[email-masked]> wrote:
> I'd add it - in fact, I would add both BTNS and TCP-AO, since neither are
> covered and both serve different purposes than the mechanisms listed.

And RFC5660.  The problem with that is that BTNS and RFC5660 have not
been implemented, to my knowledge.  Whereas at least CB have been
implemented in SASL and GSS.  Microsoft has implemented and deployed
CB.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 21 May 2012 12:23:08 -0500

> have no particular knowledge of.

Mileage varies.  You're happy with some passwords-in-the-clear use
cases but you're not fine with MTI algorithms in case they become too
weak -- not quite a contradiciton in terms, but still strange.

IMO we need several MTI algorithms, not just one and certainly not just zero.

Nico
--

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 21 May 2012 13:59:38 -0400

> in this RFC would help those people who don't understand CB.
I agree.

---

From: Nico Williams <[email-masked]>
Date: Mon, 21 May 2012 13:07:02 -0500

On Mon, May 21, 2012 at 12:59 PM, Steven Bellovin <[email-masked]> wrote:
>> On Mon, May 21, 2012 at 11:42 AM, Paul Hoffman <[email-masked]> wrote:>>> +1 to adding EAP as a mechanism.
>>>

But is it important/useful?

Given that MSFT has implemented and deployed it I think it's at least useful.

I do think CB is important -- certainly as a protocol design/analysis
tool.  I also think it should be used more often.  You'd think I would
think that, given that I'm the author of RFC5056, but I like to think
that I'm objective enough on this topic...  enough so that I can tell
you what the biggest problem with CB is: the fact that it's one more
thing that the application developer has to know about and do.  It'd
be nice if more of the protocol stack up to and including
application-layer authentication (where there is the option to do
that) were abstracted.  Still, CB is relatively simple: extract the CB
from the channel, feed it to authentication.

Nico
--

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 21 May 2012 14:09:33 -0400

> from the channel, feed it to authentication.

Thinking further, I'm not sure how much text should be in 3631bis, as opposed
to just having a pointer to 5056.  But that's a minor point.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 May 2012 21:23:28 +0300

Trying my best to be unpopular:

Much as I like the concept of BTNS, it hasn't caught on. I see this RFC 
as providing useful guidance to practitioners, and non-existent 
technology doesn't cut it.

On the other hand, SSH "leap of faith" is very close to BTNS, and should 
in fact be mentioned in the paragraph that discusses SSH. In the context 
of SSH, "leap of faith" is much more innovative than what the current 
text focuses on.

Email security takes up a significant part of the document (Sec. 3.10). 
We might wish otherwise (I do), but none of these mechanisms has been a 
real-world success. And very few people write new Email software anyway. 
So I would eliminate this section altogether or fold it into a paragraph 
or two in "Security/Multipart".

Thanks,
	Yaron

---

From: Nico Williams <[email-masked]>
Date: Mon, 21 May 2012 13:27:21 -0500

On Mon, May 21, 2012 at 1:23 PM, Yaron Sheffer <[email-masked]> wrote:
> Much as I like the concept of BTNS, it hasn't caught on. I see this RFC as
> providing useful guidance to practitioners, and non-existent technology
> doesn't cut it.

Hey, I said it too.

> On the other hand, SSH "leap of faith" is very close to BTNS, and should in
> fact be mentioned in the paragraph that discusses SSH. In the context of
> SSH, "leap of faith" is much more innovative than what the current text
> focuses on.

Right.  But note that for me BTNS was not about leap-of-faith, though
that was a key selling point for some.  For me BTNS was about
anon-anon channels that could be bound into app-layer authentication.

> Email security takes up a significant part of the document (Sec. 3.10). We
> might wish otherwise (I do), but none of these mechanisms has been a
> real-world success. And very few people write new Email software anyway. So
> I would eliminate this section altogether or fold it into a paragraph or two
> in "Security/Multipart".

I assume e-mail is not secure.  Secure e-mail that doesn't scale well
is easy enough to do (PGP, S/MIME), but it has lots of issues beyond
scalability.  If you want secure e-mail use IM w/ OTR.  (Hmmm,
shouldn't OTR be an Internet protocol?)

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 21 May 2012 14:31:02 -0400

> aware of do indeed transmit the passwords used for authentication.

In fact, IMHO this has always been one of the main advantages of OTP
schemes -- passwords can be disclosed during authentication, because
they cannot be reused.

> uses.  For others, a shared secret is better - different uses,

Agreed.  And in fact, the statement that certificates or preshared
secrets are the only available options is also false.  Last I checked,
it was also possible to use Kerberos (KINK, RFC4430) or any EAP method
(IKEv2, RFC5996).

-- Jeff

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 May 2012 09:59:35 -0700

On 5/21/2012 11:27 AM, Nico Williams wrote:
> On Mon, May 21, 2012 at 1:23 PM, Yaron Sheffer<[email-masked]>  wrote:

Or useful even without further authentication - by raising the effort of 
an attacker -- i.e., attacks need to do the work of a flash-crowd; 
merely tossing RSTs at TCP connections wouldn't work under BTNS, even 
without tying security at that connection to another layer. And that 
sort of protection is possible without *any* KMI.

Joe

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 23 May 2012 14:42:00 +0200

Hi Steve, 

to me it is not clear who the target audience of the document is and what purpose it serves. 

The early part of the document contains a threat model discussion. That's good but I believe that the writeup in BCP 72 is more useful. 

There is a laundry list of security mechanisms in Section 3. Do you expect that someone who does not know these mechanisms already to go through this list and pick one for their new protocol design?

Then, Section 4 talks about things one shouldn't do. Those are great suggestions but we actively do them today in the IETF. For example, I have been complaining about the work in the INTAREA were folks are define new ways to do IP address-based authentication in light of the widespread NAT deployments (see my comments to the list last year http://permalink.gmane.org/gmane.ietf.int/3016). 

As you stated on the mailing list: 
> 3631 says "if you want to put security into a protocol, 
> here are the best choices we have today".

Is this really how we approach protocol design today? I don't think so.

There are two classes of protocol designs: 

1) Extensions to existing protocols (DNS, email, routing protocols, etc.)
There you have to work with what is available already and your choices are impacted by the deployment. The improvements tend to be minor and speed of deployment is slow. 

2) For new protocol designs, many focus on using HTTP/HTTPS as a starting point. Almost all protocols I have seen have the need for offering the classical communication security features and TLS is the main building block. Everything beyond that is typically tough and quite difficult to describe in a generic fashion. 

On top of that I am not even sure that the process we have for tackling security in the IETF is actually as successful as we would like it to be. We typically consider the security consideration section writeup as the crucial part but I am wondering whether others had looked at the broader picture on where things went well and where they didn't. In fact, I would be far more interested to hear where the problems really are rather than producing another hitchhiker's guide to IETF security protocols. 

In any case, I will not stop you from shipping an update (which I am not sure you can even do that given it is an IAB document) but I doubt that it will have the desired impact. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Fri, 18 May 2012 22:31:39 -0400
> Von: Steven Bellovin <[email-masked]>
> An: IETF Security Area Advisory Group <[email-masked]>
> Betreff: [saag] Additions to RFC 3631?

---

From: Nico Williams <[email-masked]>
Date: Wed, 23 May 2012 09:13:37 -0500

> to me it is not clear who the target audience of the document is and what purpose it serves.

One target audience would clearly be those who don't wallow in the
security area.  There's probably an unstated purpose of simple
advertising, and maybe to have a tool to beat others with (ISTR
someone trying to argue from absence of some definition in the
security glossary, that is, using the security glossary as an
authority).  Perhaps this document can serve as a summary
applicability statement, say.  There is a risk is that we'll all just
argue endlessly about various details, possibly leading to a bloated
document.  But it does seem like a nice idea: to have a guide to an
entire area's past output.

Nico
--

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 23 May 2012 10:34:08 -0400

Thanks for your comments.  I don't agree with all of them (more inline), but I should note that I have no plans to update 3631 myself.  I'm working on another project; it occurred to me that this laundry list of protocols -- it's a fine characterization -- was a good starting point for my recommendations.

> There is a laundry list of security mechanisms in Section 3. Do you expect that someone who does not know these mechanisms already to go through this list and pick one for their new protocol design?

Up to a point, yes.  It's not useful for people who know nothing of security, and it's redundant for folks who do security for a living.  It's useful, though, for people who know something of these mechanisms but are not sure which to use.
> Then, Section 4 talks about things one shouldn't do. Those are great suggestions but we actively do them today in the IETF. For example, I have been complaining about the work in the INTAREA were f…

The fact that folks are still doing them doesn't mean that we were wrong when we wrote 3631, merely that folks haven't paid enough attention to it.  In retrospect, I suspect we should have tried publishing it as BCP; were I still an AD or on the IAB, I'd suggest that for any updated version.
> There you have to work with what is available already and your choices are impacted by the deployment. The improvements tend to be minor and speed of deployment is slow. 

Retrofitting security to an existing system is one of the hardest tasks out there.  It's not even the deployment, it's the design choices already made that constrain things.  DNSSEC is a classic example.  No one loves it or even likes it, I suspect, but I don't know that it could have been better, given the basic structure and assumptions that date to the earl 1980s.
> 2) For new protocol designs, many focus on using HTTP/HTTPS as a starting point. Almost all protocols I have seen have the need for offering the classical communication security features and TLS is…

That HTTP[S] is a basic building block is a separate problem; it's the new waist of the hourglass...
> On top of that I am not even sure that the process we have for tackling security in the IETF is actually as successful as we would like it to be. We typically consider the security consideration se…

Is it perfect?  Of course not.  I do think it's significantly better than it was 10-15 years ago.

3631 and BCP 72 (which my email archives show was initiated no later than 1999) were part of a process to improve the security of IETF protocols.  Another part was retargeting the security directorate to review all documents, and get at least some involvement early on in protocol design.  That part didn't work as well as I had hoped, at least back when I was AD, but it was far better than we'd had before.  That effort, though, was a fair number of years ago.  I've been rather disconnected from the IETF since 2005; I don't know what the current real issues are.  I'll leave it to the current IESG to figure out what to do next.  A more systematic study would indeed be a good idea.  (I know from private conversations that the Security ADs have at least some thoughts on the subject.)

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 24 May 2012 10:07:48 +0300

Hi Nico, 

> entire area's past output.

I would like to have a more precise target audience and purpose. 

For example, I make a differentiation between someone who actively
participates in the IETF (but in groups outside the security area) and
wants to address security in his or her favorite protocol design vs.
someone who does not even participate in the IETF. For the former group
we have http://tools.ietf.org/html/rfc3552, also the Sunday IETF
education session, potentially the SAAG meeting, various other IETF
related publications about ongoing security activities (e.g., IPJ). Now,
we also have some privacy related guidance they can look at
http://tools.ietf.org/html/draft-iab-privacy-considerations-02. 
In general, the difficulty is to keep the list of protocols and
recommended best current practice up-to-date. 

If we are, however, talking about engineers outside the IETF who should
also be given guidance about security (since they are supposed to use
IETF protocols as well) then things get a bit more complicated.
Typically, that has not been the audience of our documents. There are,
however, exceptions. Consider for example
http://tools.ietf.org/html/rfc6272 where Fred tried to provide guidance
for those working on smart grids/smart meters and it also includes a
list of protocols that he thought would be relevant for that specific
domain. The writing style is obviously quite different and assumes far
less knowledge about the IETF process and procedures. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 24 May 2012 10:23:13 +0300

Hi Steve, 

Thanks for your quick response. A few remarks inline: 

> Thanks for your comments.  I don't agree with all of them (more
> inline), but I should note that I have no plans to update 3631 myself.
> I'm working on another project; it occurred to me that this laundry
> list of protocols -- it's a fine characterization -- was a good
> starting point for my recommendations.
> 
> > The early part of the document contains a threat model discussion.
> That's good but I believe that the writeup in BCP 72 is more useful.
> >
> > There is a laundry list of security mechanisms in Section 3. Do you
> expect that someone who does not know these mechanisms already to go
> through this list and pick one for their new protocol design?
> 
> Up to a point, yes.  It's not useful for people who know nothing of
> security, and it's redundant for folks who do security for a living.
> It's useful, though, for people who know something of these mechanisms
> but are not sure which to use.

To give someone a suggestion who does not know anything about security I
would actually point them to http://tools.ietf.org/html/rfc4101 instead
of letting them look at security protocols. 

> >
> > Then, Section 4 talks about things one shouldn't do. Those are great
> suggestions but we actively do them today in the IETF. For example, I
> have been complaining about the work in the INTAREA were folks are
> define new ways to do IP address-based authentication in light of the
> widespread NAT deployments (see my comments to the list last year
> http://permalink.gmane.org/gmane.ietf.int/3016).
> 
> The fact that folks are still doing them doesn't mean that we were
> wrong when we wrote 3631, merely that folks haven't paid enough
> attention to it.  In retrospect, I suspect we should have tried
> publishing it as BCP; were I still an AD or on the IAB, I'd suggest
> that for any updated version.

You definitely have not been wrong but it would be nice if the documents
lead to some changed behavior as well. 

> > There you have to work with what is available already and your
> choices are impacted by the deployment. The improvements tend to be
> minor and speed of deployment is slow.
> 
> Retrofitting security to an existing system is one of the hardest
tasks
> out there.  It's not even the deployment, it's the design choices
> already made that constrain things.  DNSSEC is a classic example.  No
> one loves it or even likes it, I suspect, but I don't know that it
> could have been better, given the basic structure and assumptions that
> date to the earl 1980s.

The problem is that you essentially have to "retrofit" various
components (not only security) into the system all the time since a
successful system evolves and there is no way to consider everything in
the first try. If you consider everything in the initial design then it
will not be successful since it is too complex for everyone to use.
Furthermore, in many cases we make assumptions about the main use cases
for our technology and it turns out that we are often wrong. Either the
development is not as exciting as we had planned or the work gets used
for something entirely different. I will comment on that issue more in
the mail to Stephen.  

> >
> > 2) For new protocol designs, many focus on using HTTP/HTTPS as a
> starting point. Almost all protocols I have seen have the need for
> offering the classical communication security features and TLS is the
> main building block. Everything beyond that is typically tough and
> quite difficult to describe in a generic fashion.
> 

Interesting that you mention that and it would probably warrant a
separate discussion. 
(see
http://tools.ietf.org/html/draft-tschofenig-post-standardization-02). 

> >
> > On top of that I am not even sure that the process we have for
> tackling security in the IETF is actually as successful as we would
> like it to be. We typically consider the security consideration
section
> writeup as the crucial part but I am wondering whether others had
> looked at the broader picture on where things went well and where they
> didn't. In fact, I would be far more interested to hear where the
> problems really are rather than producing another hitchhiker's guide
to
> IETF security protocols.

Definitely. 

> 3631 and BCP 72 (which my email archives show was initiated no later
> than 1999) were part of a process to improve the security of IETF
> protocols.  Another part was retargeting the security directorate to
> review all documents, and get at least some involvement early on in
> protocol design.  That part didn't work as well as I had hoped, at
> least back when I was AD, but it was far better than we'd had before.
> That effort, though, was a fair number of years ago.  I've been rather
> disconnected from the IETF since 2005; I don't know what the current
> real issues are.  I'll leave it to the current IESG to figure out what
> to do next.  A more systematic study would indeed be a good idea.  (I
> know from private conversations that the Security ADs have at least
> some thoughts on the subject.)

I certainly agree that the chosen path has lead to a significant
improvement and the combination of guidance combined with the process
and training has shown good results. 

We should probably open another discussion thread on this topic to hear
the feedback from others about their experience in various working
groups. 

Just one tiny remark: If you look at the HTTP authentication and TLS
security work in the IETF one could get the impression that everything
is great with Web authentication. A short write-up is here:
http://tools.ietf.org/id/draft-tschofenig-secure-the-web-01.txt

Ciao
Hannes

> >
> > In any case, I will not stop you from shipping an update (which I am
> not sure you can even do that given it is an IAB document) but I doubt
> that it will have the desired impact.
> >
> > Ciao
> > Hannes
> >
> >> Does anyone have any suggestions for additions or corrections to
RFC
> 3631?

---

From: Steve Crocker <[email-masked]>
Date: Mon, 21 May 2012 10:11:41 -0400

I've been lurking and only following loosely, so I apologize in advance if the following is off the mark.

I was pleased to see mention of RFC 4086 on proper implementation of random number generation -- I am proud to be one of the co-authors -- but I thought the issue at hand is transition of crypto algorithms when current algorithms become obsolete.  This is a problem that occurs in all protocols that use crypto algorithms, and in my opinion we have underplayed this in our designs.  Every protocol that uses crypto should be designed with transition mechanisms built in -- and tested! -- on the assumption the protocol will outlive the current set of crypto algorithms.

Whether we adopt a generic way of doing this across protocols or a specific way for each protocol is a matter of discussion.  If we can't come up with a way to do it in a uniform way, then it's ok with me to have a separate way for each protocol.  In any case, I think it's important -- no, that's not strong enough -- essential to have a way of transitioning from current algorithms to future algorithms without disrupting service.  These transitions will usually take a fairly long time, five to ten years I think, so the process can be somewhat relaxed.  Relaxed does not mean undefined or vacuous.

Steve

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 29 May 2012 19:59:56 +0300

The transition from one security solution to another one was already
mentioned at the Paris IAB technical plenary as a tough issue. (Looking
at IPv6 it seems that transition is in general a problem -- not only for
security.)

What surprised me with the presentations of the panel members was that
there are even new security problems introduced with the roll-out of new
solution solutions that interfere badly with existing deployments. Chris
Weber provided the example of CORS. 

Here is the pointer to the slides and the meeting minutes (in case
someone wasn't listening to the plenary):
http://www.ietf.org/proceedings/83/technical-plenary.html

In a nutshell, I agree with what you state below, Steve. I would just
extend it beyond cryptographic algorithms.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> ext Steve Crocker
> Sent: Monday, May 21, 2012 5:12 PM
> To: IETF Security Area Advisory Group
> Cc: Steve Crocker
> Subject: Re: [saag] Additions to RFC 3631?
> 
> I've been lurking and only following loosely, so I apologize in
advance
> if the following is off the mark.
> 
> I was pleased to see mention of RFC 4086 on proper implementation of
> random number generation -- I am proud to be one of the co-authors --
> but I thought the issue at hand is transition of crypto algorithms
when
> current algorithms become obsolete.  This is a problem that occurs in
> all protocols that use crypto algorithms, and in my opinion we have
> underplayed this in our designs.  Every protocol that uses crypto
should
> be designed with transition mechanisms built in -- and tested! -- on
the
> assumption the protocol will outlive the current set of crypto
> algorithms.
> 
> Whether we adopt a generic way of doing this across protocols or a
> specific way for each protocol is a matter of discussion.  If we can't
> come up with a way to do it in a uniform way, then it's ok with me to
> have a separate way for each protocol.  In any case, I think it's
> important -- no, that's not strong enough -- essential to have a way
of
> transitioning from current algorithms to future algorithms without
> disrupting service.  These transitions will usually take a fairly long
> time, five to ten years I think, so the process can be somewhat
relaxed.
> Relaxed does not mean undefined or vacuous.
> 
> Steve
> 
> > As noted by others, RFC 4086 covers that.  It may also need
improving;
> I haven't reread it recently.  However, even a pointer to it is out of
> place in 3631bis.  3631 is about protocol mechanisms; 4086 is about
> implementations.  Mouse Mouse's suggestions are more in the domain of
> 3365, which is security design philosophy.  3631 says "if you want to
> put security into a protocol, here are the best choices we have
today".
> My question is whether or not that list should be changed.
> >
> RFC 3631?