Re: [rtcweb] Retransmit: Summary of Alternatives for media keying

Matthew Kaufman <matthew.kaufman@skype.net> Thu, 28 July 2011 17:32 UTC

Return-Path: <matthew.kaufman@skype.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00421F8C17 for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 10:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level:
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTN+F++JK-qa for <rtcweb@ietfa.amsl.com>; Thu, 28 Jul 2011 10:32:21 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id BFACD21F8C13 for <rtcweb@ietf.org>; Thu, 28 Jul 2011 10:32:21 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 138D216E2; Thu, 28 Jul 2011 19:32:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=JW p4vrnyTazwqzY8qzEljB1czDI=; b=YKZtudvKrq858EYtIQY+oae0GiEe6AcQjs 8P//taZVFekFeGwVlRHxfmLxNsa+vs5KPL52h9o6khL7VIBXbiqNL6ZQIYwRMp8V mWV4frBaCZ7k7/DR6yDNXA5KPJrDUUhnmJgv7CFOq+RGMTtk+7VGrhXOmNJ4b4sI T2ig9+l3g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=XwmN+1LUgrz6//wz+axb5n uZUKPE4rewTChQz8sho5tICEBwMB+gWm5sKEsaZvzTFwHE/hBOxE6lfH8F9Daqm8 IGzkoVVBleIWbxMZgdO9ot2sXakXOIeFyNCvPrnUc9goGuSi8lZhEGLddIV31DAr LYkXFzUTOgwWl5B8c/yJg=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 122D87F8; Thu, 28 Jul 2011 19:32:21 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E2E7735080C3; Thu, 28 Jul 2011 19:32:20 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS3Mld2NZcFt; Thu, 28 Jul 2011 19:32:20 +0200 (CEST)
Received: from dhcp-103b.meeting.ietf.org (dhcp-103b.meeting.ietf.org [130.129.16.59]) by zimbra.skype.net (Postfix) with ESMTPSA id C2EE63507F82; Thu, 28 Jul 2011 19:32:19 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Matthew Kaufman <matthew.kaufman@skype.net>
In-Reply-To: <4E319ABD.9070604@alvestrand.no>
Date: Thu, 28 Jul 2011 13:32:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <15AFE3C5-8F77-435B-B6DB-E0D081BA9ED2@skype.net>
References: <12BF9E55-662F-4762-9E47-2BBD3FA5FD93@acmepacket.com> <4E319ABD.9070604@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1082)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 17:32:22 -0000

On Jul 28, 2011, at 1:22 PM, Harald Alvestrand wrote:

> Question that I could probably answer if I understood the DH key exchange thing:
> 
> Is it possible for anyone with packet-replacement access to the media path to perform a MITM attack against DH?

Yes.

> 
> If so: Is it possible to deliver some token by the "high path" (where the SDES keys would go) that ensures that the DH key exchange is with someone possessing that token?

You can do that, or you can check the fingerprints via the high path to authenticate each end and prove that there's no MITM on the media path.

> 
> That would limit MITM attacks to attackers who had access to both the "high path" and the media path.
> 

Correct. And the high path can be protected with HTTPS and the associated PKI.

Matthew Kaufman