Hi Eric, Jim,
There're a couple of cases here where Eric is more-or-less
saying "not convinced" or that the document needs to also
mention something not currently covered. Eric - if you and
Jim could work out new text for those cases offline during
the week, that'd really help us finish this document. So
can you guys try to get together sometime to do that during
the week? We can do it on the list, but that'll take longer
and is more likely to generate a flood of messages (will
the flood metaphor be common this week I wonder:-)
Just on a couple of these:
Jim Fenton wrote:
Eric Rescorla wrote:
S 4.1.
It's not clear to me where the likelihoods for these attacks come
from. They seem quite speculative (and in my opinion wrong in
many cases). Rather argue about the details, I would simply
remove them.
The likelihoods are speculative but actually have prompted less
disagreement than I expected. Stephen Farrell suggested that taxonomy
and I think it's useful as a broad categorization of the threats.
Yep - I take the blame for suggesting these and agree that they
can only be subjective/speculative at this stage. However, I would
maintain that they are useful - some of the threats are niggly
corner-cases whereas others are fairly fatal.
S 4.1.3.
An MTA probably has are enough variables (system load, clock
resolution, queuing delays, co-location with other equipment, etc.)
to prevent useful observable factors from being measured accurately
enough to be useful for a side-channel attack. Furthermore, while
some domains, e.g., consumer ISPs, would allow an attacker to submit
messages for signature, with many other domains this is difficult.
Other mechanisms, such as mailing lists hosted by the domain, might
be paths by which an attacker might submit messages for signature,
and should also be considered as possible vectors for side-channel
I'm not convinced by this argument. The appropriate reference here is
"Remote Timing Attacks are Practical" from USENIX Security 04. One of
the key things to remember about side channel attacks is that enough
samples let you factor out the noise. I'm not sure why you raise the
issue this way, because there are known countermeasures to timing
attack on RSA. Rather than claim that the attack doesn't apply,
why not simply recommend using them.
> Probably because I don't know what the countermeasures are. Are they
> also described in the USENIX paper you cite?
I think that, or some similar, reference is a really good suggestion.
However, if we also had a paragraph describing this nicely (hint: Eric
could write one:-) that'd help since I believe there may be a good few
potential implementers that aren't aware of the side-channel attacks
that've been demonstrated.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html