> Does the presence of the "Error" message open a denial-of-service
> attack?
> It is not protected by the hash image technique described in Section 9.
It does not really.
Yes, that's a weasely thing to say, but let's suppose that I want to DoS you. I
don't need error messages. If I can fling enough ICMP packets at you, you're
going down. I can pick a bunch of ways to do this, too. Ping, SYNs, ACKs, RSTs,
you name it. Heck, if I just start sending you ICMP host-not-reachable packets,
you have problems.
At a higher level, I can fling enough badly formed packets from the media
stream (either SRTP packets, out-of-sequence ZRTP state messages like hello
packets, and so on) that you're going to have problems. I don't needs to send
an error message.
But let's also look at the error message itself. Let's suppose that it is
integrity-checked. What do you do with an error message that fails its
integrity check? Some of these cases are amusingly absurd. Suppose you have a
badly formed error message of type 0x10 (malformed packet). Is an erroneously
formed malformed packet error therefore a success? Yes, I'm smiling as I say
that.
Even worse, though, some of the errors indicate crypto/data errors. Let me
assume an evil router that flips some single bit (selected for maximum lulz) on
many ZRTP messages. You try to talk to me and I get a bad packet because it's
been damaged. I'll respond back to you (e.g.) that you have a bad HMAC, which
gets itself damaged, because that maximizes the router's amusement. How do you
handle a bad HMAC error that itself has a bad HMAC? The most entertaining thing
is to conclude that because the HMAC was bad, that the error is wrong and in
fact the packet you sent me had a good HMAC. It's also the most wrong. It is
less wrong and less entertaining for you to send me an error message telling me
that my HMAC is wrong in the packet I sent you telling you that you had an HMAC
error. It's still wrong, and still entertaining.
Unfortunately, the least entertaining way to handle this is to just accept it,
and that's also the least wrong. Yes, it could be forged, but it could also be
ignored; the only place in the document where we even suggest how to handle
errors says that an implementation MAY drop the connection. An implementation
is free to ignore errors, as undesirable as that it. The bottom line, though,
is that authenticated error messages brings in its own baggage that is
difficult, if not impossible to solve.
>
> Section 4.5.2:
> ExportedKey = KDF(s0, "Exported key", KDF_Context, negotiated hash
> length)
> Do we need to include an additional string parameter giving the name
> of the application that will use the exported key? That would provide
> cryptographic separation when different applications each need their
> own key. Perhaps you would give ExportedKey to the operating system
> and provide a new KDF that could be used by applications that have been
> authenticated by name by the OS and which then include the application
> name in the key derivation. Maybe add some text here?
I don't think we *need* to, and while I can understand why we might *want* to,
I don't know what to say that doesn't presuppose an implementation. The name
that the application has is purely local to the implementation. I am at a loss
to think of something that would apply both to some stripped-down RTOS and so a
full-blown OS with its own secure database. Obviously, the implementer has to
treat the exported key with care because it's a key, but this is in fact the
point in the document where we're telling the implementer that there's a
separation between the protocol and something they have to do.
Do you have text you can suggest? If not, I'd say leave it as it is.
>
> Nits/editorial comments:
>
> Section 4.1.1:
> expected be
> SHOULD BE:
> expected to be
>
> Section 4.4.2.3:
> would then proceeds
> SHOULD BE:
> would then proceed
>
> Section 5.7:
> keyed hash over encrypted part
> SHOULD BE:
> keyed hash over the encrypted part
>
> Section 10:
> consider a audio
> SHOULD BE:
> consider an audio
>
>
>
>
> Good stuff!
Thank you. These are all great.
Jon
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
