"Against Rekeying"

Perry E. Metzger perry at piermont.com
Fri Mar 26 10:23:57 EDT 2010

Also manually forwarded on behalf of  Peter Gutmann. As  before, if you
reply, don't credit me with the text, it is his.

>From pgut001 Fri Mar 26 14:44:54 2010
To: ben at links.org, Nicolas.Williams at sun.com
Subject: Re: "Against Rekeying"
Cc: cryptography at metzdowd.com, perry at piermont.com, simon at josefsson.org
In-Reply-To: <20100325160755.GF21244 at Sun.COM>

Nicolas Williams <Nicolas.Williams at sun.com> writes:

>I suspect that what happened, ultimately, is that TLS re-negotiation was an
>afterthought, barely mentioned in the TLS 1.2 RFC and barely used, therefore
>many experts were simply not conscious enough of its existence to care.

I think that was a significant problem with noticing this, that many
implementors may have looked at it, decided it was a nightmare to implement,
served no really obvious purpose once 40-bit keys had gone the way of the
dodo, and was a significant source of future problems (see my previous
message), and so never bothered with it.  As a result it never got much
attention, as do significant chunks of other security protocols.  I think the
real skill in security protocol implementation isn't knowing what to
implement, but knowing what not to implement (I've had an attack-surface-
reduced SSH draft in preparation for awhile now, I really must get back to the
some time).

One nice thing about being the author of a crypto toolkit is that you can
experiment with this, either skipping features or turning existing features
off in new releases, to see if anyone notices.  If no-one does, you leave them
turned off.  You can turn off an awful lot of security-protocol "features"
before people start to notice, leading me to believe that a scary portion of
many protocols actually consist of attack surface and not features.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list